Authentification de l'utilisateur LDAP dans les domaines de confiance

Question

Mon application définit les utilisateurs autorisés via LDAP (généralement Active Directory):

1. Le client définit un serveur LDAP (TREEA) et un groupe (groupa). Tous les utilisateurs de Groupa peuvent utiliser l'application.
2. Au moment de la connexion, un utilisateur envoie son nom d'utilisateur et son mot de passe - si une liaison au LDAP TREEA avec ses informations d'identification fonctionne, et que son compte d'utilisateur est dans une groupa, il est bon à aller

Je suis tombé sur une situation où deux répertoires actifs se font confiance, et la groupa spécifiée dans TREEA contient des utilisateurs de TreeB. L'étape # 2 échoue donc parce que j'essaie d'authentifier l'utilisateurB (de TreeB) contre Treea.

L'application a accès à Treea, donc je suppose qu'elle pourrait sembler en groupa et y voir UserB. Mais comment saurait-il qu'il doit envoyer des demandes de liaison à TreeB pour authentifier le nom d'utilisateur et le mot de passe?

Existe-t-il une meilleure façon d'approcher cela?
De telles demandes de liaison devraient-elles être automatiquement transmises à TreeB car il existe une relation de confiance ??

Answer 1

Il se peut que vous ayez juste un problème de configuration sur le serveur LDAP (TREEA). Vous avez écrit qu'il y a une confiance entre Treea et TreeB, afin que vous puissiez ajouter UserB (de TreeB) en tant que membre de la groupa dans TREEA. Si vous pouvez le faire, vous avez réussi à établir la confiance dans la bonne direction entre Treea et Treeb. Vous devez comprendre que la confiance signifie uniquement qu'Active Directory B vérifiez le mot de passe utilisateur uniquement, mais l'utilisateur par défaut n'aura pas accès aux ressources de l'Active Directory A. L'utilisateur peut n'aurez aucune autorisation de permettre à LDAP de se lier au serveur A. Dans le cas, le problème sera résolu en accordant à l'utilisateurb l'autorisation de connexion à distance sur le serveur A et l'accès à la lecture à Groupa et probablement à lire l'autorisation à l'ou où le groupe existe. Tu peux essayer Aperçu pour Active Directory pour surveiller l'accès à la publicité pour localiser les problèmes d'autorisation.

Une autre raison possible de votre problème pourrait être l'utilisation de l'API que vous utilisez pour l'accès LDAP. Dans votre question, vous n'avez écrit aucune information sur l'API. Utilisez-vous une API Win32 comme LDAP_BIND_S Ou utiliser Répertoire dans .net? Dans les deux cas, il pourrait être important que vous utilisiez le nom de domaine explicite avec le nom de compte (pour l'utilisateur) pendant la liaison ou l'utilisation null Pour le nom et le mot de passe aux informations d'identification de l'utilisateur actuelles de l'utilisateur.

L'utilisation du compte fixe de TREEA pour tous les accès à TREEA (également pour les tests sur l'utilisateurb) pourrait également résoudre le problème, mais il pourrait être possible qu'une sorte d'utilisation des applications.

En quelque sorte, plus d'informations dans votre question pourraient réduire le problème et les moyens de résoudre le problème.

Answer 2

Peut-être devriez-vous utiliser la réplication LDAP de sorte que les objets sont toujours présents dans les deux serveurs?

Answer 3

L'application a accès à Treea, donc je suppose qu'elle pourrait sembler en groupa et y voir UserB. Mais comment saurait-il qu'il doit envoyer des demandes de liaison à TreeB pour authentifier le nom d'utilisateur et le mot de passe?

La member L'attribut dans Groupa donnera le nom distingué complet (DN) de chaque membre, qui pourrait ressembler à quelque chose comme:

member: CN=User1,OU=People,DC=TreeA,DC=foobar,DC=com
member: CN=User2,OU=People,DC=TreeB,DC=foobar,DC=com

Ainsi, lorsque «User2» tente de s'authentifier, vous pouvez faire correspondre le CN et savoir que vous devriez vous authentifier contre «TreeB» au lieu de «Treea». (Vraisemblablement, vous auriez une sorte de table mappant le DN au nom d'hôte du serveur d'annonces.) Ou, vous le forcez brutal et essayez «TreeB» si vous obtenez un «non utilisateur» de «Treea».

Vous auriez besoin de prendre une décision sur la façon de gérer le cas des noms d'utilisateurs en double dans les deux arbres - l'une prend-elle la priorité sur l'autre?

Une autre approche consisterait à exiger que les utilisateurs spécifient à quel arborescence ils s'authentifient, par exemple en se connectant avec un nom de connexion comme «user1@treea.foobar.com».

Answer 4

Disons que vous avez le domaine A et le domaine B qui se faisaient confiance, et si vous souhaitez authentifier l'utilisateur B du domaine B contre le domaine A sur un serveur de domaine A, ce que vous devez faire est:

1. Usurper l'utilisateur B sur le domaine A en utilisant les API Win32.

2. Authentifiez l'utilisateur B contre le domaine A Utilisation de DirectoryEntry, vous pouvez ensuite accéder à l'annonce du domaine A pour d'autres informations d'utilisateur telles que les groupes affectés.

Je l'ai implémenté dans une application ASP.NET qui utilise l'authentification Windows.

J'espère que cela aide,