In LDAP, cos'è esattamente un DN vincolante?


19

Ho scritto vari pezzi di codice che si collegano ai server LDAP ed eseguono query, ma per me è sempre stato un voodoo. Una cosa che non capisco davvero è il concetto di DN vincolante. Ecco un esempio usando lo ldapsearchstrumento da riga di comando disponibile da openldap. (Ignora la mancanza di autenticazione.)

ldapsearch -h 1.2.3.4 -D dc=example,dc=com [query]

Qual è lo scopo e la funzione di questa -D dc=example,dc=comparte? Perché è necessario associarsi a una posizione specifica nella gerarchia di directory? È per stabilire a quale parte della directory le mie domande dovrebbero essere applicate? Ad esempio, se il nodo radice della directory è dc=com, e ha due figli ( dc=fooe dc=bar), forse voglio che le mie query siano contro la dc=foo,dc=comsottostruttura e non sulla dc=bar,dc=comsottostruttura?

Risposte:


18

Un DN di bind è un oggetto a cui ti colleghi all'interno di LDAP per permetterti di fare tutto ciò che stai cercando di fare. Alcune (molte?) Istanze LDAP non consentono associazioni anonime o non consentono l'esecuzione di determinate operazioni con associazioni anonime, pertanto è necessario specificare un nome utente bindDN per ottenere un'identità per eseguire tale operazione.

In un modo non tecnico simile - e sì, questo è un tratto - una banca ti permetterà di entrare e guardare i loro tassi di interesse senza dare loro alcun tipo di ID, ma per aprire un conto o prelevare denaro, hai per avere un'identità di cui sono a conoscenza - quell'identità è il bindDN.


BindDN corrisponde sempre a un nodo nella directory? O può essere una stringa arbitraria?
Dirtside,

Sì. Deve corrispondere a un nodo che ha la capacità di trasportare un attributo password o di essere autenticato in altro modo.
Giovanni

Tomayto, tomahto. 🍅 Nome utente, associare DN. 🤷🏻‍♂️
emallove,

31

Non confondersi tra baseDN e bindDN .

Il baseDN di una ricerca è il punto di partenza. Dove inizierà la ricerca. Abbastanza autoesplicativo.

Il DN bindDN è fondamentalmente la credenziale che stai usando per autenticarti con un LDAP. Quando si utilizza un bindDN, di solito viene fornito con una password associata.

In altre parole, quando si specifica un bindDN, si utilizza quell'accesso di sicurezza dell'oggetto per passare attraverso l'albero LDAP.

Ora, la stringa dc = esempio, dc = com non è l' esempio migliore per un bindDN in quanto è un "dominio" per un albero LDAP. dc sta per componente di dominio e ogni albero LDAP definisce la sua radice con una stringa sotto forma di dc = string, dc = string, ... Ma queste stringhe non sono un "percorso" come il resto dell'albero.

Esempi validi sono:

  • dc = example, dc = com
  • dc = miodominio
  • dc = Avery, dc = lungo, dc = lista, dc = del dc = domini

Ma questi elementi di radice sono indivisibili. Sembrano sono diversi elementi che rappresentano un percorso come il resto della struttura, ma sono non . Ad esempio, nell'ultimo esempio non esiste un oggetto dc = of, dc = domains .

Immagina di nominare il tuo disco C: come "D: \ my \ folder \". Ogni percorso sarà simile a "D: \ my \ folder \ my \ real \ path" che sarebbe confuso poiché il percorso del file reale sarebbe \ my \ real \ path giusto? Bene, è così che appare la base (radice) di un LDAP, con un insieme di elementi dc =.

Link pertinente: http://docs.oracle.com/cd/E19199-01/816-6400-10/lsearch.html


7
Sembra un disegno inutilmente confuso, ma la tua spiegazione ha un senso.
Dirtside,

1
Sì sono d'accordo. Anche nominare la tua radice sembra che un percorso non sia la scelta migliore, ma credo che debba avere le sue ragioni. Ora sai perché tutti i DN terminano con una serie di componenti dc =. =)
Marcelo,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.