Active Directory

Comprendre l'authentification de proxy dans AD LDS

Ken St. Cyr

À une vue d'ensemble :

• Définition de l'authentification du proxy
• Pourquoi l'authentification du proxy est utile
• Dans l'objet proxy
• Que se passe-t-il pendant authenticationItem

Contenu

Qu'est-ce que l'authentification proxy ?
Avantages d'authentification proxy
Dans l'objet proxy
Comment l'authentification est réellement effectuée
Configuration d'un laboratoire d'authentification proxy
Conclusion

Comme avec n'importe quel service d'annuaire LDAP-activé, Services de Microsoft Active Directory Lightweight Directory (AD LDS, autrefois appelé ADAM) demande à un utilisateur de lier avant d'exécuter les opérations LDAP sur l'annuaire. Cette liaison peut être effectuée via quelques méthodes différentes, notamment une liaison simple LDAP, une simple Authentication et liaison SASL (Security Layer) ou même la redirection de liaison. La liaison peut également être anonyme, auquel cas l'utilisateur présente un mot de passe null. Dans cet article, je vais aborder et analyser une méthode plus précisément, lier la redirection, sinon, appelée authentification proxy.

Qu'est-ce que l'authentification proxy ?

Authentification proxy permet à un utilisateur effectuer une liaison simple à une instance AD LDS, tout en conservant une association à un compte Active Directory. Deux comptes sont impliqués dans la transaction. Le premier est qu'un objet spécial dans AD LDS appelée un objet userProxy. Le second est le compte de l'utilisateur dans Active Directory.

L'objet userProxy AD LDS est une représentation du compte Active Directory. L'objet proxy est liée au compte Active Directory par identificateur de sécurité (SID) de ce compte. Il est sans mot de passe stocké sur l'objet proxy réel lui-même.

Lorsqu'un utilisateur effectue une liaison simple à une instance LDS avec un objet proxy, la liaison est redirigée vers Active Directory en transmettant le SID et le mot de passe à un contrôleur de domaine. Le serveur AD LDS effectue l'authentification et l'ensemble du processus est invisible pour l'utilisateur final. Cela est illustré à la figure 1 , où Lucy se connecte à une instance AD LDS appelée « CN = AppDir,DC = contoso, DC = com " avec son compte d'utilisateur AD LDS.

La figure 1 connexion avec AD LDS (cliquez sur l'image pour l'agrandir)

Pour l'authentification, Lucy utilise une liaison simple et il fournit les son nom unique (DN, Distinguished Name) et le mot de passe comme elle au cours d'une liaison LDAP standard. Bien qu'apparemment Lucy se connecte avec son compte d'utilisateur LDS typique, elle utilise en fait un objet proxy. L'authentification pour Active Directory se passe en coulisses et Lucy n'a aucune indication qu'elle est réellement utilise son compte Active Directory pour lier.

Avantages d'authentification proxy

La puissance de l'authentification du proxy réside dans donnant aux développeurs d'applications l'accès à un objet utilisateur sans toutefois leur permettre d'accès au compte Active Directory. Pensez à ce qu'il se produit lorsqu'une nouvelle application utilisant des annuaires est créée et l'application a besoin de stocker des données dans Active Directory. L'application peut utiliser un attribut existant ou créer un nouveau.

Le danger en utilisant un attribut inutilisé existant est que l'attribut est probablement il dans un autre but. Même s'il s'agit inutilisés à présent, il peut être utilisé à l'avenir ; si il est utilisé certains but différent, Active Directory les administrateurs doivent effectuer le suivi de comment il est utilisé. Et que se passe-t-il si le développeur d'application doit plusieurs attributs ?

Avec l'authentification de proxy, une représentation de l'objet utilisateur Active Directory existe dans le répertoire AD LDS. Un répertoire spécifique à l'application permet au développeur d'application modifier le schéma comme il pouvez souhaitez dans le contexte de AD LDS. Attributs peuvent être ajoutées, modifiées ou remplacés de manière que choisit le développeur et Active Directory administrateur n'avez à vous soucier plusieurs modifications schéma ou de suivi de la façon dont les attributs sont utilisés. Si une autre application est en ligne et souhaite utiliser le même attribut, il n'est pas un problème car il peut être une instance AD LDS distincte et que vous n'aurez pas de conflits d'attribut.

L'authentification du proxy peut également être utile dans les situations qui requièrent le format X.500. Active Directory n'utilise pas nomenclature X.500 typique de DN. Par exemple, un objet utilisateur dans Active Directory possède le nom de domaine " CN = Lucy d. Smith, CN = Users, DC = contoso, DC = com ". Toutefois, dans AD LDS, nom unique de l'utilisateur peut être « CN = Lucy d. Smith, CN = Users, O = Contoso, C = fr », qui est compatible avec X.500.

Ceci est utile lorsque vous utilisez un client LDAP tiers ou que vous tentez d'intégrer un répertoire tiers qui nécessite le format X.500. Dans cette façon, LDS peut être un répertoire intermédiaire entre un répertoire tiers et Active Directory. L'authentification du proxy, le compte de service que le répertoire tiers doit utiliser pour lier à l'instance LDS peut être conservé dans Active Directory au lieu de LDS lui-même.

Dans l'objet proxy

Jusqu'ici j'ai donné un bref aperçu de la façon dont l'objet proxy LDS est lié le compte d'utilisateur Active Directory. Je vais maintenant examiner cela plus en détail et examinez ce qui se fait passe en coulisses, commençant par la classe d'objet.

Dans Windows Server 2008, le répertoire %SYSTEMROOT%\ADAM contient deux fichiers LDF qui représentent un objet proxy :

• MS-UserProxy.LDF
• MS-UserProxyFull.LDF

MS-UserProxy.LDF contient la définition de la classe userProxy simple, qui dispose des attributs de base et qui contient la classe auxiliaire msDS-BindProxy. MS-UserProxyFull.LDF contient la msDS-BindProxy classe auxiliaire ainsi, mais il pre-populates également attributs utilisateur supplémentaires dans l'attribut mayContain de la classe. De ce fait, les classes d'attributs devoir existe au préalable. Donc lorsque importer la classe userProxyFull, l'utilisateur ou inetOrgPerson classe doit être importé tout d'abord. Utilisateur et inetOrgPerson contiennent l'attribut définitions de classe pour les attributs qui userProxyFull utilise. la figure 2 présente les différences entre la classe userProxy et la classe userProxyFull.

La figure 2, les classes userProxy et userProxyFull (cliquez sur l'image pour l'agrandir)

Le fait que les deux classes contiennent msDS-BindProxy comme une classe auxiliaire est important. Une classe auxiliaire est un type de classe que peut fournir des données supplémentaires à une classe structurelle. Dans LDS, par exemple, la classe d'utilisateurs est une classe structurelle héritée de la classe organisationnelle-personne, ce qui signifie que la classe d'utilisateurs tout ce que la classe Personne organisationnelle a. Mais la classe d'utilisateurs a également une classe auxiliaire appelée msDS-BindableObject, ce qui signifie qu'utilisateur contient tous les attributs obligatoires et facultatives de msDS-BindableObject avec les attributs de la classe-Personne organisationnelle. Dans ce cas, l'utilisation de msDS-Bindable­Object comme une classe auxiliaire permet la classe d'utilisateurs pouvant être liés.

Puisque la classe userProxy possède msDS-BindProxy comme une classe auxiliaire (voir figure 3 ), il maintenant également contient l'attribut obligatoire et facultatif ensemble ensemble des msDS-BindProxy. La classe auxiliaire msDS-BindProxy est ce qui transforme un objet en un objet proxy. Ainsi, même si vous disposez d'une classe personnalisée, vous pouvez ajouter la classe auxiliaire msDS-BindProxy et utiliser vos propres objets pour l'authentification proxy.

La figure 3 Création d'un proxyobject (cliquez sur l'image pour l'agrandir)

Si vous examinez la classe msDS-BindProxy, vous devez Notez que seul attribut obligatoire défini, objectSID. Ceci est l'attribut qui est placé dans le SID du compte d'utilisateur Active Directory pour créer l'association entre l'objet proxy dans LDS et l'objet utilisateur dans Active Directory. Cet attribut peut uniquement être rempli lorsque l'objet est créé. Il ne peut pas être modifié sans suppression de l'objet et de recréer.

Comment l'authentification est réellement effectuée

Pour comprendre véritablement ce qui se passe en coulisses, nous devrez aller un peu plus loin dans la façon dont l'authentification est effectuée. Je vous parcourez les deux traces réseau qui permettront d'afficher le fonctionne de l'authentification du proxy. La première trace est une capture réseau de liaison simple l'utilisateur proxy à partir une station de travail Windows XP à une instance de Windows Server 2008 LDS. Dans cette capture Lucy lie avec son objet utilisateur proxy à l'aide LDP.EXE à partir de sa station de travail.

figure 4 illustre les trois paquets dans la copie, nous devons examiner. Paquet 1 est la demande et la lier à partir la station de travail (10.0.0.107) au serveur Active Directory LDS (10.0.0.201). La demande de liaison contient nom unique de Lucy, " cn = lucy, cn = personnes, cn = appdir, dc = contoso, dc = com ". Paquet 2 est la réponse du serveur Active Directory LDS à la station de travail, indiquant une liaison réussie. Et paquet 3 est l'accusé de réception de la station de travail sur le serveur Active Directory LDS, indiquant l'accusé de réception de la réponse de liaison.

La figure 4 lier la demande et réponse (cliquez sur l'image pour l'agrandir)

Si vous aller dans les détails du paquet 1 (voir figure 5 ), vous remarquez quelque chose shocking. Le mot de passe que Lucy fourni (P@ssw0rd) s'affiche dans le texte clair dans la copie. Il est, en fait, un des downfalls d'utiliser une liaison simple LDAP pour l'authentification. À moins que la liaison est encapsulée dans le chiffrement SSL, le mot de passe de l'utilisateur est publié pour les personnes à l'écoute sur le réseau.

La figure 5 liaison simple avec SSL désactivé (cliquez sur l'image pour l'agrandir)

Active Directory LDS activer SSL toutefois par défaut. Vous devez aller hors de votre façon pour le désactiver, qui est exactement ce qu'a J'AI fait pour cet exercice afin de rendre la trace réseau lisible. Et je n'a pas besoin d'attribuer un certificat sur le serveur Active Directory LDS, mais dans une implémentation réelle, vous voulez absolument vous assurer que le serveur Active Directory LDS dispose d'un certificat valide qui peut être utilisé pour SSL.

La deuxième trace est une capture réseau à partir du serveur Active Directory LDS sur le contrôleur de domaine (DC). Cette trace est un peu plus importante que le premier élément, donc je vous décomposez il en segments. Les paquets tout d'abord 9 de cette trace figurent dans la figure 6 .

La figure 6 AD LDS connexion au contrôleur de domaine (cliquez sur l'image pour l'agrandir)

Le premier paquet doit sembleront familier pour vous. C'est dans la requête de liaison entrante à partir de la station de travail. Là encore, ce paquet contient nom de domaine et mot de passe en texte clair de Lucy. Paquets 2 à 9 affichent le serveur AD LDS (10.0.0.201) connectant sur le contrôleur de domaine (10.0.0.200). Ceci consiste certains messages de protocole ARP (résolution adresse suivis d'une connexion d'appel (RPC) de procédure distante vers le contrôleur de domaine.

Dans la figure 7 , paquets 10 et 11 appeler une méthode nommée LsarLookupSids3, un appel RPC qui indique le contrôleur de domaine pour prendre un lot de SID et renvoyer les noms correspondants. Le serveur AD LDS fait la demande dans le paquet 10 et reçoit la réponse du contrôleur de domaine dans le paquet 11.

La figure 7 tenter l'authentification Kerberos (cliquez sur l'image pour l'agrandir)

Après une négociation TCP brève pour démarrer la session Kerberos (12–14 paquets), dans le paquet 15 le serveur AD LDS tente ensuite d'obtenir le ticket de service d'authentification (Req AS) du centre de distribution clés (KDC). Dans le paquet 16, la demande de ticket de service d'authentification refusée le contrôleur de domaine attend une pré-authentification données que le serveur AD LDS n'a pas fournir. Dans ce cas, le contrôleur de domaine veut l'horodatage afin puissent être utilisée pour la vérification d'identité. La session Kerberos se termine et une réinitialisation est demandé (17–19 paquets).

la figure 8 illustre le reste de la capture. Paquets 20–22 établir une session Kerberos nouvelle et une nouvelle demande de service d'authentification est envoyée à partir du serveur AD LDS au contrôleur de domaine dans le paquet 23. Cette nouvelle demande contient des données authentification préalable nécessaires, indiquées par la réponse réussie à partir le contrôleur de domaine dans le paquet 25. Le serveur AD LDS maintenant a le ticket de service d'authentification et pouvez placer une demande du ticket de l'octroi de service pour authentifier les informations d'identification de Lucy.

La figure 8 Authentification réussie (cliquez sur l'image pour l'agrandir)

Le ticket de l'octroi de demande de service et de réponse sont capturés dans les paquets 33 et 34. La réception de la KRB_TGS_REP dans le paquet 34 indique que Lucy est authentifiée avec succès. Enfin, dans le paquet 38 le serveur AD LDS transmet la réponse de liaison revenir à la station de travail, laissant Lucy savoir qu'elle a correctement lié à l'instance AD LDS. Bien que ce processus implique plusieurs étapes, la durée totale pour cette transaction entière est uniquement environ 1/10 de seconde.

Que se passerait-il si Lucy entré un mot de passe erroné ? Dans notre exemple, la demande de service d'authentification Échec au paquet 25. L'échec de la demande de service d'authentification devez indiquer au serveur AD LDS qu'informations d'identification de Lucy étaient incorrectes. Au lieu d'émettre une demande le bon d'octroi de service, le serveur AD LDS serait émettre une réponse de liaison revenir à la station de travail, indiquant que les informations d'identification n'étaient pas valides.

Voici un récapitulatif de Qu'est-il arrivé à l'échange réussi :

1. La station de travail envoie une demande de liaison au serveur AD LDS.
2. Le serveur AD LDS établit une connexion avec le contrôleur de domaine.
3. Le serveur AD LDS demande contrôleur de domaine pour traduire de Lucy SID dans un identificateur qui il peut utiliser pour l'authentification.
4. Le contrôleur de domaine donne code. le Lucy de serveur AD LDS
5. Le serveur AD LDS obtient un ticket de l'octroi de ticket (TGT) à partir du contrôleur de domaine avec code. du Lucy
6. Le serveur AD LDS récupère un ticket de session à elle-même à l'aide de Lucy TGT.
7. Le serveur AD LDS envoie une réponse liaison réussi revenir à la station de travail.

Cette procédure montre que la connexion à partir de la station de travail au serveur AD LDS est une transaction de liaison LDAP standard. Puis à partir du serveur AD LDS sur le contrôleur de domaine, Kerberos est utilisé pour en toute sécurité authentifier l'utilisateur.

Configuration d'un laboratoire d'authentification proxy

Maintenant que vous savez comment fonctionne l'authentification du proxy, voyons comment vous pouvez configurer cela dans un environnement de laboratoire. Notez que pour cet exercice, je vous être désactiver la demande pour SSL de l'authentification du proxy. Comme je L'AI mentionné précédemment, cependant, n'oubliez Veuillez pas que vous devez désactiver cette condition dans une implémentation réelle.

Avant de commencer, vous devez un domaine entièrement fonctionnel avec un serveur membre Windows Server 2008 et une station de travail joint à elle. Le serveur membre Windows Server 2008 s'exécute AD LDS et la station de travail sera le point de terminaison client. L'avantage en séparant ces ordinateurs est que vous pouvez tirer les captures réseau de l'interaction entre les. Pour configurer le laboratoire, je vais vous guideront la procédure suivante : lors

• Installer AD LDS sur le serveur membre.
• Désactiver la demande de SSL pour l'authentification du proxy.
• Importer la classe userProxy dans le schéma AD LDS.
• Créer l'objet proxy et attribuer des autorisations lui.
• Lier à l'annuaire AD LDS avec l'objet proxy.

La première étape consiste à installer AD LDS sur le serveur membre Windows Server 2008. Dans le Gestionnaire de serveur, vous trouverez l'option d'installation LDS dans l'Assistant « rôles ajouter ». Après avoir installé le rôle, une nouvelle option apparaîtra dans le menu Outils d'administration appelé Assistant Active Directory Lightweight Directory Services Configuration. Cet Assistant permet de créer une nouvelle instance LDS.

Lors de l'invité à indiquer le nom de la partition d'application, saisir n'importe quel nom de domaine vous aimeriez. Mémoriser prend en que LDS charge X.500 nommer, de sorte que vous n'êtes pas limité à l'aide un « contrôleur de domaine = " nom du style. Dans mes exemples, J'AI utilisé « cn = appdir, dc = contoso, dc = com », mais J'AI peut également avez utilisé « cn = appdir, o = contoso, c = us ».

Une fois que l'instance AD LDS est installée, l'étape suivante consiste à désactiver la demande de SSL pour l'authentification du proxy. Enfichable l'outil ADSI Edit (adsiedit.msc), vous devez vous connecter à la partition de configuration de l'instance AD LDS utilisant le compte administrateur que vous avez spécifié pendant l'installation. Si vous ne connaissez pas le DN de la partition de configuration, vous pouvez choisir « configuration » dans la liste déroulante « Sélectionner un contexte de nommage bien connu » dans la boîte de dialogue Paramètres de connexion dans ADSI Edit.

Recherchez le conteneur " CN = Directory Service, CN = Windows NT, CN = Services, CN = Configuration, CN = {guid} » et afficher la boîte de dialogue Propriétés de la " CN = Directory Service » conteneur. Il existe un attribut de chaîne à valeurs multiples dans la liste attribut appelé msDS-autres-paramètres qui répertorie les différentes chaînes, chaque indiquant un paramètre différent pour l'instance AD LDS. Modifier cet attribut et changer la chaîne « RequireSecureProxyBind » à la valeur 0.

L'étape suivante consiste à l'importation de la définition de classe de schéma pour la classe userProxy. Vous pouvez avez déjà importé Si invité à le faire dans l'Assistant AD LDS. Si tel est le cas, vous pouvez ignorer cette étape. Si vous n'avez pas déjà importer, faire avec la commande LDIFDE.EXE suivante. Assurez-vous que vous indiquez le nom du serveur AD LDS et le port correct dans la commande :

C:\> ldifde –i -f c:\windows\adam\ms-userproxy.ldf –s
   server:port –k –j . –c 
   "cn=schema,cn=configuration,dc=X"
   #schemaNamingContext

Maintenant que la classe d'objet a été importée, l'objet proxy peut être créé. J'AI utiliserez LDP.EXE, mais vous pouvez utiliser un autre outil ou une méthode par programmation. Utilisation de LDP, se connecter à votre instance AD LDS et lier avec vos informations d'identification administrateur. Recherchez le DN de votre instance AD LDS et puis cliquez sur le conteneur dans lequel vous souhaitez créer l'objet proxy. Cliquez avec le bouton droit sur le conteneur et choisissez Ajouter un enfant dans la liste déroulante. Dans la boîte de dialogue Ajout, vous devrez entrer le DN de l'objet proxy nouveau dans le champ Nom de domaine. Par exemple, vous pouvez utiliser « cn = lucy, cn = appdir, o = contoso, c = us ».

Vous devrez également créer deux attributs avec cet objet. La première est objectClass, qui indique le type d'objet en cours de création. La valeur pour cet exemple doit être userProxy. Placer ces informations dans la section Modifier une entrée de la boîte de dialogue et cliquez sur le bouton Entrée.

L'attribut deuxième pour ajouter est objectSID, qui contient le SID du compte utilisateur Active Directory auquel cet objet proxy est associé. Vous pouvez obtenir ce SID avec un large éventail de méthodes, mais J'AI simplement connecté à Active Directory dans une instance séparée de LDP et copié l'attribut objectSID du contient le compte d'utilisateur. Après avoir entré ces informations, la boîte de dialogue Ajouter doit être similaire à la figure 9 . Enfin, cliquez sur le bouton Exécuter pour appliquer la modification.

La figure 9 Création d'un objet proxy

Pour pouvoir utiliser l'objet proxy que vous venez de créer, vous devrez lui attribuer des autorisations. Vous pouvez effectuer cette facilement en sélectionnant la " CN = lecteurs " objet sous la " CN = rôles » conteneur dans LDP. Cliquez avec le bouton droit et cliquez sur Modifier dans la liste déroulante. Ajouter un attribut appelé membre et de la valeur entre le DN de l'objet userProxy que vous avez créé. Pensez à cliquer sur le bouton entrée avant de cliquer sur Exécuter. Maintenant l'objet userProxy doit être un membre du groupe lecteurs dans l'instance LDS.

Tout ce que doit être paramétré afin de pouvoir tester maintenant l'authentification du proxy. Ouvrez une nouvelle instance de LDP et connectez-vous au serveur AD LDS. Cette fois, cependant, lorsque vous liez à votre instance, sélectionnez liaison simple et un type dans le DN de l'objet proxy dans le champ de nom d'utilisateur. Le mot de passe, entrez le mot de passe d'Active Directory objet compte liées de ce proxy. Cliquez sur OK et vous devez maintenant être lié à l'instance en mode lecture-seule.

Passer quelques temps prenant traces réseau et essayez de lier différentes méthodes. Un exercice peut être à activer SSL sur et prendre une capture du processus de liaison LDAP puis. Vous pouvez même volontairement fautes d'orthographe un nom d'utilisateur ou un mot de passe et observez le résultat du processus d'authentification.

Conclusion

Ne pas être panique sur la difficulté d'utiliser l'authentification du proxy. J'AI a pris l'approche d'illustrant ce processus avec LDP et l'outil de modification ADSI, car il vous donne un aspect mieux en arrière-plan. Raison de cela, l'exemple J'AI présenté vous ici illustre l'authentification du proxy du point de vue très pratique.

Dans la pratique, le processus de création d'objets userProxy et de manipuler les longue est généralement codified via un système de gestion des identités ou un frontal personnalisé développées pour la création de comptes. Je vous encourage à créer votre propre laboratoire LDS et constater par vous-même comment utiliser l'authentification du proxy pour l'intégration vos répertoires tiers et applications.

Ken St Cyr est un consultant pour Microsoft et a conçu et implémenté le répertoire de solutions basées sur Active Directory depuis l'origine. Il devenait récemment un des premiers pour obtenir la certification Microsoft Certified principal de services d'annuaire. Contacter au Ken.stcyr@Microsoft.com.