De ce [email protected] și cn=user,dc=domain nu sunt echivalente? (Administrarea sistemului, Ldap, Serviciul De Directoare Aws)

Kit Sunde a intrebat.
a intrebat.

Am configurat un AD simplu pe AWS pe care mă pot autentifica în sfârșit cu LDAP. Nu înțeleg de ce nu am reușit să folosesc dc= care este sugerată pe scară largă peste tot, dar sunt capabil să folosesc @domain.

ldap_bind($ldapconn, "cn=Administrator,dc=ldap,dc=patontheback,dc=org", "<password>");
ldap_bind($ldapconn, "[email protected]", "<password>");

Nu ar trebui să fie echivalente? Va funcționa întotdeauna @domain sau este specific pentru Simple AD?

Comentarii

  • Vă rugăm să verificați locația corectă a utilizatorului administrator în LDAP. Este într-adevăr în secțiunea LDAP sau este într-o sub-secțiune? (utilizatori, sistem,….orice). Trebuie să potriviți întreaga cale a obiectului (utilizatorul administrator în cazul dvs.). –  > Por Zina.
  • @Zina Este în Users (am adăugat o captură de ecran). Cum aș putea să o selectez? Am încercat dc=, ou=, UsersAdministrator dar am impresia că mă bâjbâi în întuneric. –  > Por Kit Sunde.
  • este cn=Administrator,ou=Users,dc=ldap,dc=pathontheback,dc=org –  > Por Zina.
3 răspunsuri
Zina

OP a dat informații suplimentare despre locația utilizatorului administrator, deci trebuie să folosească cn=Administrator,ou=Users,dc=ldap,dc=pathontheback,dc=org

EDIT:A făcut o greșeală de scriere, trebuie să fie:cn=Administrator,cn=Users,dc=ldap,dc=pathontheback,dc=org

Users este un container, nu OU.

Comentarii

  • Am încercat, dar nu reușesc să mă conectez cu: cn=Administrator,ou=Users,dc=ldap,dc=patontheback,dc=org și am verificat că mă pot conecta în continuare cu versiunea UPN. –  > Por Kit Sunde.
  • Ciudat. Ați folosi un browser LDAP unde puteți copia dname-ul? de ex. ldp.exe (cred că este în RSAT) sau ldapadmin.org și să vedeți dacă nu cumva am făcut o greșeală de tipar? –  > Por Zina.
  • Ah ha! în loc de ou=Users se dorea cn=Users. Mulțumesc! –  > Por Kit Sunde.
  • @KitSunde Veți observa în dsa.msc obiectele container (cn=) sunt reprezentate de o pictogramă de dosar „goală” – vizibilă în captura de ecran din întrebarea dvs. organizationalUnit (ou=) este un dosar cu ceea ce pare a fi o carte de telefon pe ele. –  > Por jscott.
Ryan Bolger

A puțin de citit despre LDAP și DN-uri ar putea fi în ordine aici.

Un nume distins (de obicei prescurtat DN) identifică în mod unic o intrare și descrie poziția acesteia în DIT. Un DN se aseamănă foarte mult cu o cale absolută pe un sistem de fișiere, cu excepția faptului că, în timp ce căile din sistemul de fișiere încep de obicei cu rădăcina sistemului de fișiere și coboară de la stânga la dreapta, DN-urile LDAP urcă în arbore de la stânga la dreapta.

Prin urmare, dacă doriți să specificați DN-ul contului de administrator din domeniul dumneavoastră, trebuie să specificați calea completă (și corectă) către acesta. După cum arată captura dvs. de ecran (și faptul că este standard în AD), contul de administrator se află în containerul Users.

Rețineți că am folosit cuvântul container și nu OU. Nu toate containerele din AD sunt OU și majoritatea celor implicite care există nu sunt de fapt OU. Puteți să vă dați seama dintr-o privire comparând pictograma pentru Users cu pictograma pentru Domain Controllers. Dacă acest lucru este prea subtil, puteți verifica, de asemenea, pictograma reală objectClass pentru fiecare dintre ele. OU’s va conține organizationalUnit iar containerele normale vor avea container. Într-o valoare DN, OU-urile au „OU=” ca cheie RDN, iar containerele au „CN=” ca cheie RDN.

În orice caz, nu trebuie să vă dați seama de toate acestea manual atunci când căutați în fiecare zi DN-ul unui lucru. Pur și simplu deschideți (sau interogați) proprietățile obiectului pe care îl căutați și verificați distinguishedName atributul. Aceasta vă va oferi calea completă și corectă fără a încerca să înșirați manual o mulțime de RDN-uri și contexte.

TL;DRDN-ul pentru contul de administrator în domeniul dvs. de exemplu este CN=Administrator,CN=Users,DC=ldap,DC=patontheback,DC=org

Acestea fiind spuse, este o practică mai bună să continuați să faceți ceea ce faceți și să folosiți UPN-ul ([email protected]) pentru conturile bind față de AD, deoarece este mai puțin probabil ca acestea să se schimbe decât o valoare DN.

nelaaro

Răspunsul lui @Ryan Bolger are o explicație foarte bună. Am vrut să includ un exemplu mai complet pentru cei cărora le place să vadă ce se întâmplă cu diverse comenzi.

De exemplu, eu folosesc următoarele pentru binddn distinguishedName: CN=auser,OU=IT Dev,OU=localdomain Users,DC=localdomain,DC=lan

-D 'CN=auser,OU=IT Dev,OU=localdomain Users,DC=localdomain,DC=lan'

sau UPN userPrincipalName: [email protected]

-D '[email protected]'

Următoarele linii vor produce aceeași ieșire de mai jos

ldapsearch -x -h '192.168.0.10' -D 'CN=Auser,OU=IT Dev,OU=localdomain Users,DC=localdomain,DC=lan' -w password -b"cn=auser,OU=IT Dev,OU=localdomain Users,dc=localdomain,dc=lan" -s sub "objectclass=*"   

sau

ldapsearch -x -h '192.168.0.10' -D '[email protected]' -w password -b"cn=auser,OU=IT Dev,OU=localdomain Users,dc=localdomain,dc=lan" -s sub "objectclass=*"

Se va genera aceeași ieșire

# extended LDIF
#
# LDAPv3
# base <cn=auser,OU=IT Dev,OU=localdomain Users,dc=localdomain,dc=lan> with scope subtree
# filter: objectclass=*
# requesting: ALL
#

# auser, IT Dev, localdomain Users, localdomain.lan
dn: CN=GitLab,OU=IT Dev,OU=localdomain Users,DC=localdomain,DC=lan
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: auser
givenName: auser
distinguishedName: CN=auser,OU=IT Dev,OU=localdomain Users,DC=localdomain,DC=lan
instanceType: 4
whenCreated: 20190221073536.0Z
whenChanged: 20190221080923.0Z
displayName: auser
uSNCreated: 108114404
memberOf: CN=groupofusers,OU=localdomain Groups,DC=localdomain,DC=lan
uSNChanged: 108116177
name: auser
userAccountControl: 66048
codePage: 0
countryCode: 0
primaryGroupID: 513
accountExpires: 9223372036854775807
sAMAccountName: auser
sAMAccountType: 805306368
userPrincipalName: [email protected]
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=localdomain,DC=lan
dSCorePropagationData: 16010101000000.0Z
lastLogonTimestamp: 131952101637691018

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1