base LDAP generico per la ricerca?

Question

Sto scrivendo un po 'di codice C ++ / Win32 per la ricerca di un utente in una directory LDAP (in realtà ho bisogno di validare un nome utente / password è corretta, e quindi verificare l'appartenenza al gruppo). Ho il nome utente, quindi spero qualcosa di simile a quanto segue funziona:

(&(objectCategory=person)(objectClass=user)(uid={username}))

Quando chiamo ldap_search con questa ricerca / filtro, devo fornire una base di partenza (nodo / OU / qualunque cosa) per cercare. Ma io non so da dove cominciare la ricerca - tutto quello che ho è il nome utente. Esiste un modo per specificare la radice dell'albero che funzionerà con OpenLDAP, Active Directory, LDAP Netscape, etc, etc?

Inoltre, chiunque in grado di rispondere a questa probabilmente potrebbe aiutare con questo: è l'attributo uid universalmente supportato, o ho bisogno per cercare un attributo diverso a seconda di quale marca di server LDAP sto parlando? (Ho visto i riferimenti a persone che hanno bisogno per cercare uid, CN e anche SAMAccountName).

Answer 1

Per quanto riguarda la prima domanda su genericamente il recupero di una base di ricerca:

Ogni server di directory LDAP (conforme al protocollo LDAP credo) espone alcune thingies operativi nell'ambito di un nodo denominato RootDSE . Una delle cose che si possono recuperare attraverso RootDSE sono namingContexts , che in sostanza si può dire ciò che i diversi alberi sono ospitati su questo server.

Così si può recuperare una base di ricerca di alto livello per il vostro nome utente-ricerca. Si prega di essere a conoscenza:. Alcuni LDAP (OpenLDAP per esempio) i server possono ospitare più alberi quindi bisogna trovare una soluzione quando si trovano molteplici contesti di denominazione

Il RootDSE possono essere recuperate interrogando il server per il DN "" (stringa vuota) e specifiyng che si desidera ottenere tutti gli attributi operativi pure. Solo qualche esempio per un server OpenLDAP:

ldapsearch -H ldap://ldap.mydomain.com -x -s base -b "" +
# note the + returns operational attributes

Ciò dovrebbe restituire qualcosa di simile a quello mostrato qui sotto (da OpenLDAP 2.4.8) - I valori tra parentesi sono spiegazioni aggiunti e non vengono restituiti dal server:

dn:
structuralObjectClass: OpenLDAProotDSE
configContext: cn=config
namingContexts: dc=example,dc=com
namingContexts: dc=example,dc=net
monitorContext: cn=Monitor
supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 (Contentsync RFC 4530)
[...]
supportedExtension: 1.3.6.1.4.1.4203.1.11.1 (ModifyPassword RFC3088)
[...]
supportedFeatures: 1.3.6.1.1.14 (Modify-Increment RFC4525)
[...]
supportedLDAPVersion: 3
supportedSASLMechanisms: NTLM
[...]
entryDN:
subschemaSubentry: cn=Subschema

( http://www.zytrax.com/books/ LDAP / CH3 / # operativa )

---

Per quanto riguarda la seconda domanda sulla disponibilità dell'attributo uid:

Non credo che si dovrebbe fare affidamento su questo dato che dipende fortemente lo schema utilizzato per la memorizzazione dei dati utente (anche se la maggior parte degli user-schema-classi avranno un attributo uid credo). Ma questo dipende la flessibilità che si desidera mettere nel vostro programma. Forse il modo migliore sarebbe quello di rendere l'utente-filtro-stringa configurabile da parte dell'utente finale (si potrebbe anche fare questo con la base di ricerca che avrebbe alcuni vantaggi di prestazioni (non c'è bisogno di cercare l'intero albero quando gli utenti si trovano solo in un piccolo sotto-albero e senza bisogno di interrogare il RootDSE)).

Answer 2

Non vorrei fare affidamento su uid essere l'attributo di ricerca adeguata per le voci utente in LDAP. Molte aziende garantirà solo l'employeeID come unico all'interno del DIT LDAP.

Answer 3

È necessario definire ciò che il contenitore per avviare la ricerca. Quindi questo sarebbe qualcosa di simile

"LDAP://" + _ADSPath + ":" + _ADSPort + "/" + _ADSRootContainer

dove _ADSPath è il server hostname / IP; _ADSPort è il numero di porta (solitamente 389 di default); e _ADSRootContainer è il resto del percorso del contenitore (come ou = Utenti. Il percorso dipenderà l'attuazione si sta cercando contro. È possibile avviare più alto del recipiente contenente gli utenti e impostare i parametri per l'oggetto di ricerca da utilizzare una ricerca multi-livello. Ma sarà molto più lento.