9 votes

Syntaxe LDAP/ActiveDirectory BindDN

Je suis en train de dépanner un pare-feu matériel basé sur Linux pour un client. Ce pare-feu matériel se connecte à ActiveDirectory pour l'authentification Single SignOn.

ActiveDirectory n'est en grande partie qu'une version pervertie de LDAP, à ma connaissance, et utilise la même syntaxe BindDN - corrigez-moi si je me trompe.

Le client a configuré ceci comme son BindDN -- les chaînes de caractères réelles ont été remplacées pour des raisons de confidentialité mais les caractères spéciaux et les espaces restent. "un lieu aléatoire \fubar fubaz"

Cela ne me semble pas être une syntaxe BindDN valide et j'ai déjà travaillé avec LDAP auparavant, mais lorsque nous appuyons sur le bouton Test pour tester ce BindDN, le test réussit. Lorsque je modifie un seul des caractères du BindDN et que je relance le test, celui-ci échoue.

J'essaie de comprendre quel est le problème ici :

A) Je ne comprends pas complètement les nuances de BindND et de la syntaxe associée.

ou

B) L'appareil ne vérifie pas correctement les entrées et identifie faussement le test comme un succès.

16voto

Ryan Bolger Points 16332

LDAP n'est qu'un protocole. Et comme l'a dit Greg, la mise en œuvre de ce protocole par Microsoft dans Active Directory est conforme aux diverses RFC qui le définissent. (+1 pour lui)

La réponse de Doug est partiellement correcte dans la mesure où il donne un exemple de Bind DN valide. Mais Active Directory autorise spécifiquement l'envoi de la valeur Bind DN sous d'autres formes. À mon avis, la meilleure forme à utiliser est la forme UserPrincipalName (UPN) qui se présente généralement sous la forme suivante, sauf si elle a été explicitement modifiée.

  • <sAMAccountName>@<domain FQDN> (par exemple user1@contoso.com)

L'avantage de cette méthode par rapport à une valeur DN normale est que le compte d'utilisateur peut être déplacé au sein d'AD et que l'application qui utilise les informations d'identification ne doit pas mettre à jour sa configuration.

Il peut également se présenter sous la forme de l'ancien NetBIOS, qui ressemble à ceci et semble être celui que votre client utilise.

  • <Nom de domaine NetBIOS>\<sAMAccountName> (par exemple, CONTOSO \user1 )

Cette valeur présente les mêmes avantages que la valeur UPN, mais elle est également considérée comme ancienne. Les noms NetBIOS auraient dû mourir il y a longtemps, mais c'est un sujet de discussion pour un autre fil.

2voto

Doug Points 371

Le DN de liaison serait CN=username,CN=Users,DC=yourdomain,DC=com pour un utilisateur situé dans le conteneur Users.

Cela pourrait fonctionner si vous n'indiquiez que le nom d'utilisateur, car il recherche probablement la propriété sAMAccountname s'il connaît Active Directory. Mais ne faites pas précéder le nom d'utilisateur du domaine.

1voto

Thecamelcoder Points 11

L'implémentation LDAP de Microsoft est conforme. Tout caractère est valable dans un DN. S'il y a des caractères spéciaux, ils doivent être échappés. Les espaces blancs n'ont pas besoin d'être échappés, à moins qu'ils ne soient en tête ou en queue. Un caractère peut être échappé à l'aide d'une barre oblique inversée ou de la balise \nn équivalent hexagonal.

Noms distingués
http://msdn.microsoft.com/en-us/library/Windows/desktop/aa366101%28v=vs.85%29.aspx

space or # character at the beginning of a string    0x20
space character at the end of a string    0x20
,    comma    0x2C
+    plus sign    0x2B
"    double quote    0x22
\    backslash    0x5C
<    left angle bracket    0x3C
>    right angle bracket    0x3E
;    semicolon    0x3B
LF   line feed    0x0A
CR   carriage return    0x0D
=    equals sign    0x3D
/    forwards slash    0x2F

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X