Quel champ utiliser lors de l'authentification contre Active Directory ?

Windows Server & IT Pro Active Directory & Entra ID
1

Les objets utilisateur Active Directory incluent un certain nombre de champs qui peuvent être considérés comme des identifiants. La liste suivante en présente quelques-uns avec leur libellé dans ADUC et leur nom d’attribut :

  • Full Name - cn

  • ? - name

  • User sAMAccountName logon - sAMAccountName

  • User UPN Logon: userPrincipalName

  • ? - distinguishedName

J’essaie d’amener nos développeurs à se standardiser sur l’utilisation d’un seul de ces champs lors de l’écriture de code personnalisé qui s’authentifie contre l’AD - le problème est que je ne suis pas sûr lequel est le « bon », ou si différents champs sont les bons dans différentes circonstances. Je ne suis même pas sûr qu’un des champs ci-dessus doive être utilisé !

Quelqu’un d’autre a-t-il choisi un champ à utiliser de manière cohérente, et qu’est-ce qui a influencé votre décision ? Existe-t-il de la documentation qui clarifie le sujet ?

Source : [Server Fault](Attributs de nommage d’utilisateur - Win32 apps | Microsoft Learn](Attributs de nommage d’utilisateur - Win32 apps | Microsoft Learn)

2

Un CN (nom commun) n’est pas adapté pour la connexion, car un CN seul n’identifie pas un utilisateur de manière unique. 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 aussi 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 faire en sorte que le SamAccountName du second soit quelque chose comme rries2.

Un DN (nom distinctif) n’est pas pratique 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, c’est pénible de devoir le saisir en entier. C’est le même genre de concept qu’entre les chemins relatifs et les chemins absolus dans un système de fichiers. Cela implique aussi que vous savez exactement où se trouve l’objet dans la structure de l’annuaire sans avoir à le rechercher. Ce qui n’est souvent pas le cas.

C’est ce qu’on appelle la résolution de noms ambigus (ANR) - la recherche dans l’annuaire d’un utilisateur lorsque vous ne disposez pas de son nom distinctif.

L’UPN (User Principal Name) est assez bon car les UPN ressemblent à des adresses e-mail, ils peuvent être identiques à l’adresse e-mail professionnelle de l’utilisateur, ils sont faciles à retenir, et ils sont préférés pour la connexion car le nom sera d’abord recherché dans le domaine local, avant d’être recherché dans la forêt.

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

Gardez à l’esprit cette mention « pas obligatoire » à la fin lorsque vous concevez vos applications.

Le SamAccountName est également bon car le SamAccountName doit être unique pour tout le monde dans le domaine (mais pas dans la forêt). De plus, les SamAccountName sont courts. La plupart des gens se connectent avec des SamAccountName, même si ceux-ci 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 d’excellente documentation sur le sujet pour approfondir :

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