Quel champ utiliser lors de l'authentification par rapport à Active Directory?

Les objets utilisateur Active Directory incluent un certain nombre de champs qui peuvent être considérés comme un identifiant. Ce qui suit en répertorie certains avec leur étiquette dans ADUC et leur nom d'attribut:

• Nom complet - cn
• ? - Nom
• Connexion de l'utilisateur sAMAccountName - sAMAccountName
• Connexion UPN utilisateur: userPrincipalName
• ? - nom distingué

J'essaie d'amener nos développeurs à standardiser l'utilisation d'un seul d'entre eux lors de l'écriture de code personnalisé qui s'authentifie contre AD - le problème est que je ne suis pas sûr de savoir qui est le "bon", ou si différents sont les bons dans différents conditions. Je ne suis même pas sûr que l'un des champs ci-dessus devrait être utilisé!

Quelqu'un d'autre en a-t-il choisi un à utiliser de manière cohérente et qu'est-ce qui vous a influencé dans cette décision? Une documentation qui clarifie le problème?

Un CN (nom commun) n'est pas utile pour se connecter, car un CN seul n'identifie pas de manière unique un utilisateur. Je pourrais avoir un

CN=Ryan Ries,OU=Dallas,DC=Domain,DC=com

et je pourrais aussi avoir un

CN=Ryan Ries,OU=New York,DC=Domain,DC=com

Le CN d'un utilisateur est également un RDN (nom distinctif relatif). Ils ont le même CN, mais des DN différents. Vous remarquerez peut-être que vous rencontrez des problèmes si vous avez deux personnes dans votre organisation nommées Ryan Ries, et vous devrez créer le SamAccountName pour le second quelque chose comme rries2.

Un DN (nom unique) n'est pas bon pour se connecter, car qui veut se connecter à un système avec un nom d'utilisateur comme CN=ryan,OU=Texas,DC=brazzers,DC=com? Bien que l'utilisation d'un DN identifie de manière unique et définitive un utilisateur, il est ennuyeux de devoir taper. C'est le même genre de concept entre les chemins relatifs et les chemins absolus sur un système de fichiers. Cela implique également que vous savez exactement où se trouve l'objet dans la structure de répertoires sans avoir à le rechercher. Ce que vous n'avez souvent pas.

C'est ce qu'on appelle la résolution de nom ambiguë (ANR) - recherche dans le répertoire d'un utilisateur lorsque vous n'avez pas son nom distinctif.

UPN (nom d'utilisateur principal) est assez bon car ils ressemblent à des adresses e-mail, ils peuvent être les mêmes que l'adresse e-mail d'entreprise de l'utilisateur, ils sont faciles à mémoriser et ils sont préférables pour se connecter avec car le nom sera recherché dans le domaine local avant de le chercher dans la forêt.

Microsoft dit: Le but de l'UPN est de consolider les espaces de noms de messagerie et d'ouverture de session afin que l'utilisateur n'ait à mémoriser qu'un seul nom. L'UPN est le nom de connexion préféré pour les utilisateurs Windows. Les utilisateurs doivent utiliser leurs UPN pour se connecter au domaine. Au moment de la connexion, un UPN est d'abord validé en recherchant le domaine local, puis le catalogue global. Le fait de ne pas trouver l'UPN dans le domaine local ou le GC entraîne le rejet de l'UPN. L'UPN peut être attribué, mais n'est pas requis , lors de la création du compte d'utilisateur.

Gardez à l'esprit ce bit "non requis" à la fin lors de la conception de vos applications.

SamAccountName est également bon car SamAccountName doit être unique pour tout le monde dans le domaine (mais pas pour la forêt.) De plus, SamAccountNames sont courts. La plupart des gens se connectent avec SamAccountNames, même s'ils ne vous identifient pas de manière unique dans une forêt AD, c'est pourquoi vous devez spécifier un nom de domaine pour accompagner votre SamAccountName afin que le système sache à quel domaine vous essayez de vous connecter. .

Voici une excellente documentation sur le problème pour une lecture plus approfondie:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms677605(v=vs.85).aspx

http://msdn.microsoft.com/en-us/library/windows/desktop/ms680857(v=vs.85).aspx

Si vous faites référence au nom d'utilisateur comme quelque chose que quelqu'un taperait pour se connecter, je recommanderais soit sAMAccountName, qui serait unique en combinaison avec un nom de domaine, soit le userPrincipalName, qui serait unique dans une forêt.

En ce qui concerne le nom d'utilisateur comme identifiant unique, Windows utilise le SID pour toutes les entrées de contrôle d'accès et fournit un ensemble complet de méthodes de traduction en SID à partir des noms d'utilisateur. Les SID correspondent à la métaphore de l'utilisateur pour la durée de vie d'un compte, car les renommages et les déplacements au sein d'un domaine n'ont aucun effet, mais la suppression et la recréation entraînent un nouveau SID.

À cette fin, j'appellerais LookupAccountName, qui prend une chaîne représentant le nom d'utilisateur et renvoie le sAMAccountName, le SIDet le nom de domaine du domaine dans lequel l'utilisateur a été trouvé.

L'utilisateur peut ensuite utiliser n'importe quelle syntaxe prise en charge par Windows pour se connecter, et aucune formation supplémentaire n'est requise.

Je recommanderais de permettre à l'utilisateur de choisir le format du nom qu'il souhaite utiliser et de déterminer l'entrée de l'utilisateur du côté de l'application. par exemple: Si l'utilisateur tape: username@domain.com - considérez-le comme UPN et recherchez UPN dans AD. Si l'utilisateur tape: nom d'utilisateur - considérez-le comme samAccountName pour un domaine par défaut prédéfini et bien sûr si l'utilisateur tape domaine \ nom d'utilisateur - considérez-le comme samAccountName du domaine spécifié. Récupérez toujours le SID de l'utilisateur et attribuez toutes les autorisations au SID car les gens se marient et le nom d'utilisateur peut changer.