Vraag LDAP / ActiveDirectory BindDN-syntaxis


Ik probeer een linux-gebaseerde hardwarefirewall voor een client op te lossen. Deze hardwarefirewall maakt verbinding met ActiveDirectory voor Single SignOn-verificatie.

ActiveDirectory is in grote lijnen gewoon een perverse versie van LDAP naar mijn beste weten, en gebruikt dezelfde BindDN-syntaxis - corrigeer me als ik het mis heb.

De client heeft dit geconfigureerd als hun BindDN - de feitelijke strings zijn om privacyredenen vervangen, maar speciale tekens en witruimte blijven behouden. "somerandomplace \ fubar fubaz"

Dit lijkt geen geldige BindDN-syntaxis voor mij te zijn en ik heb eerder met LDAP gewerkt, maar als we op de knop Test klikken om dit BindDN te testen, slaagt de test. Wanneer ik slechts één van de tekens in het BindDN wijzig en de test opnieuw uitvoer, mislukt de test.

Ik probeer erachter te komen wat het probleem hier is:

A) Dat ik de nuances van BindND en de bijbehorende syntaxis niet volledig begrijp

of

B) Dat het apparaat er niet in slaagt de inputs goed te verifiëren en de test ten onrechte identificeert als een succes


6
2018-04-08 19:07


oorsprong




antwoorden:


LDAP is slechts een protocol. En zoals Greg zei, Microsoft's implementatie ervan in Active Directory voldoet aan de verschillende RFC's die het definiëren. (+1 voor hem)

Het antwoord van Doug is gedeeltelijk juist omdat hij een voorbeeld geeft van een geldige Bind-DN. Maar Active Directory biedt specifiek de mogelijkheid om de Bind-DN-waarde ook als andere vormen te verzenden. De beste vorm om te gebruiken naar mijn mening is de UserPrincipalName (UPN) meestal in de volgende vorm, tenzij deze expliciet is gewijzigd.

  • <sAMAccountName> @ <domein FQDN> (bijvoorbeeld user1@contoso.com)

Het voordeel hiervan ten opzichte van een normale DN-waarde is dat het gebruikersaccount binnen AD kan worden verplaatst en dat de applicatie die de inloggegevens gebruikt, de configuratie niet hoeft bij te werken.

Het kan ook in het oude NetBIOS-formulier voorkomen dat er zo uitziet en lijkt te zijn wat uw client gebruikt.

  • <Domain NetBIOS Name> \ <sAMAccountName> (bijvoorbeeld CONTOSO \ user1)

Dit heeft hetzelfde voordeel als de UPN-waarde, maar wordt opnieuw als verouderd beschouwd. NetBIOS-namen zouden al lang geleden moeten zijn overleden, maar dat is een tirade voor een andere thread.


10
2018-01-21 08:28



Dank je! Deze opmerking over de 3 vormen van DN is het puzzelstuk dat ik miste. - Mark E. Haase
Had geen idee dat u UPN als een LDAP-DN kon gebruiken. Zoet. - Jonathon Reinhart
Ik sta er versteld van hoeveel applicatieverkopers die alleen externe authenticatie ondersteunen tegen AD (via LDAP) dit ook niet weten. - Ryan Bolger


De bind-DN ​​is CN = gebruikersnaam, CN = Gebruikers, DC = uwdomein, DC = com voor een gebruiker in de container Gebruikers.

Het zou kunnen werken als u ook gewoon de gebruikersnaam invoert omdat het waarschijnlijk naar de eigenschap sAMAccountname zoekt als de Active Directory hiervan op de hoogte is. Gewoon de gebruikersnaam voor het domein niet invoeren.


2
2018-04-08 20:09





De LDAP-implementatie van Microsoft is conform. Elk teken is geldig in een DN. Als er speciale tekens zijn, moeten deze worden geëscaped. Whitespace hoeft niet te worden ontsnapt, tenzij het leidt of achterloopt. Een karakter kan worden geëscaped met een backslash of het hexadequivalent \ nn.

Distinguished Names
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 

1
2018-04-08 21:00