LDAP: protocollo, modello dati e gestione delle directory

LDAP è il linguaggio comune con cui le applicazioni accedono ai servizi di directory. Un client può usarlo per cercare entry denominate, leggere o modificare attributi e autenticarsi presso la directory. Il protocollo definisce messaggi, operazioni e codici di errore. Il modo in cui un server memorizza i dati, li replica o li protegge dai guasti resta invece compito della rispettiva implementazione. Active Directory Domain Services, OpenLDAP e 389 Directory Server parlano quindi LDAP senza essere internamente la stessa piattaforma (RFC 4510, sezioni 1 e 2, RFC 4511, sezione 3).

Questa separazione è decisiva nell’esercizio della messaggistica. Un gateway può verificare prima dell’accettazione SMTP se un destinatario esiste, risolvere gruppi per una policy o autenticare un amministratore. Se questa interrogazione fallisce o restituisce dati obsoleti, non è semplicemente «LDAP non funzionante»: a seconda dell’integrazione, i messaggi vengono rifiutati, le regole applicate in modo errato o gli accessi bloccati. L’amministratore deve quindi sapere in quale punto è interrotto il percorso dal nome DNS all’attributo letto.

La spiegazione segue questo percorso. Prima il client trova un server e stabilisce una sessione protetta. Quindi si autentica, esegue una ricerca e interpreta le risposte. Solo quando questo flusso normale è chiaro si possono inquadrare correttamente schema, particolarità di Active Directory, replica, scalabilità e ripristino.

Stack di protocollo e modello di sessione

Prima che un’applicazione possa cercare, necessita di una destinazione di servizio concreta. Negli ambienti Active Directory, i record DNS SRV forniscono possibili Domain Controller o Global Catalog; altri prodotti usano FQDN statici, service discovery proprietaria o un load balancer. Questa selezione determina non solo l’indirizzo IP, ma anche posizione, ruolo del server e nome rispetto al quale viene verificato il certificato. Un test di porta verso un server qualsiasi raggiungibile non risponde quindi ancora alla domanda se l’applicazione raggiunge la propria destinazione prevista.

Sulla destinazione scelta LDAP stabilisce una connessione TCP. La porta 389 inizia come LDAP e può passare a una sessione protetta con la StartTLS Extended Operation. La porta 636 è registrata presso IANA come ldaps e viene usata, tra l’altro, da Active Directory per TLS avviato immediatamente. In entrambi i casi il client deve verificare la catena del certificato e il nome del server; «cifrato» e «connesso al server corretto» sono due verifiche diverse (RFC 4511, sezioni 4.14 e 5, IANA Service Name Registry, MS-ADTS, Using SSL/TLS).

All’interno di questa connessione LDAP non trasmette righe di comando leggibili come SMTP. I messaggi sono descritti come strutture ASN.1 e codificati con Basic Encoding Rules, BER. Ogni LDAPMessage contiene un messageID, esattamente un’operazione e controlli opzionali. Tramite il Message-ID, una connessione di lunga durata può distinguere più operazioni in corso; le relative risposte non devono arrivare nell’ordine delle richieste. Un handshake TCP riuscito non dice quindi nulla sulla decodifica BER, sul Bind o su una ricerca completata integralmente (RFC 4511, sezioni 3.1, 4.1.1 e 5.1).

Per le modifiche vale un limite importante: una singola operazione LDAP è atomica nel proprio ambito, ma più entry non formano una transazione comune del protocollo di base. RFC 5805 descrive un’estensione sperimentale per transazioni, il cui supporto il client deve riconoscere nel Root DSE. Anche in questo caso occorre verificare come le repliche vedano la modifica. I processi di provisioning necessitano quindi di regole proprie per ripetizione, errori parziali e riconciliazione, anziché di una transazione di database tacitamente presunta (RFC 4511, sezione 3, RFC 5805, sezioni 1 e 3).

Modello dati: DIT, Entry, attributo e schema

Dopo l’instaurazione della sessione, il client deve poter indicare dove e cosa cerca. LDAP organizza a questo scopo i dati della directory come Directory Information Tree, in breve DIT. Ogni Entry dispone di un Distinguished Name univoco e di attributi. Lo schema descrive quali attributi esistono, come vengono confrontati i loro valori e quali Object Classes richiedono o consentono. Senza questo modello, base di ricerca, filtri e risultati restano semplici stringhe senza un significato affidabile (RFC 4512, sezioni 2 e 3, RFC 4511, sezione 4.1.7).

Il Distinguished Name forma il percorso di un’entry nell’albero. In cn=Mail Gateway,ou=Services,dc=example,dc=ch, cn=Mail Gateway indica il Relative Distinguished Name locale; gli RDN successivi conducono attraverso il container fino alla radice dei nomi. Poiché gli RDN possono avere più valori e caratteri come virgola, più e backslash devono essere escaped, il software non deve elaborare un DN dividendo semplicemente sulle virgole. Richiede un parser conforme a RFC 4514 (RFC 4512, sezione 2.3, RFC 4514, sezioni 2 e 3).

dn: cn=Mail Gateway,ou=Services,dc=example,dc=ch
objectClass: top
objectClass: person
objectClass: organizationalPerson
cn: Mail Gateway
sn: Gateway
mail: mail-gateway@example.ch

Per esportazioni e importazioni esiste LDIF, una rappresentazione testuale standardizzata. LDIF rappresenta Entries o record di modifica, ma non è il formato wire della sessione LDAP in corso. Il folding delle righe, i valori Base64 e i Change Records seguono regole proprie. Soprattutto, un’esportazione contiene soltanto ciò che il server e le autorizzazioni rendono visibile; possono mancare attributi operativi, ACL o stato del backend. Un dump LDIF è quindi un estratto di dati, ma non automaticamente un backup del server ripristinabile (RFC 2849, sezioni 2 e 4).

Il significato di un valore di attributo deriva soltanto dallo schema. Una Matching Rule come caseIgnoreMatch, integerMatch o un confronto DN decide se due valori sono uguali e quali filtri funzionano su di essi. Sul wire, i valori appaiono inizialmente come Octet Strings; sintassi e tipo di attributo forniscono la loro interpretazione. Gli elementi di schema personalizzati necessitano pertanto di OID univoci permanenti, sintassi e Matching Rules definite, nonché di un rollout che consideri congiuntamente server e tutti i client dipendenti (RFC 4512, sezione 4, RFC 4517, RFC 4520).

Operazioni e cambiamenti di stato

Con trasporto, nomi e schema è pronta la struttura di base; ora inizia il vero dialogo di protocollo. Il primo cambiamento di stato decisivo è di norma Bind. Esso stabilisce sotto quale identità e con quali diritti derivati vengono eseguite le operazioni successive. Un Bind rinnovato sostituisce questo stato. Finché il server elabora un Bind, il client non può avviare altre operazioni sulla stessa connessione (RFC 4511, sezioni 3.1 e 4.2).

Dopo un Bind riuscito, il client può leggere o scrivere. Una ricerca non restituisce un’unica risposta grande, bensì zero o più messaggi SearchResultEntry, eventualmente References e, al termine, esattamente un SearchResultDone. Solo questo risultato finale indica se la sequenza era completa. Modify, Add, Delete e ModifyDN modificano le entry; Compare verifica un valore di attributo secondo la sua Matching Rule, senza restituire un normale risultato di ricerca (RFC 4511, sezioni da 4.5 a 4.9).

Anche la fine della sessione ha una semantica chiara. Unbind è una richiesta unilaterale di chiusura e non possiede risposta. Abandon chiede al server di interrompere una specifica operazione, ma non ne garantisce l’interruzione. Se invece TCP si interrompe, tutte le operazioni in corso scompaiono. In caso di operazione di scrittura, il client non può allora sapere con certezza se la modifica è diventata effettiva prima o dopo la perdita della connessione; un retry necessita quindi prima di una riconciliazione dello stato anziché di una ripetizione cieca (RFC 4511, sezioni 4.3 e 4.11).

Controls ed Extended Operations completano questa sequenza senza introdurre una nuova versione LDAP. Ogni Control possiede un OID, una Criticality e opzionalmente un valore codificato BER. Se un client marca come critico un Control sconosciuto o non eseguibile, l’operazione deve fallire con unavailableCriticalExtension; altrimenti il server può ignorarlo. Prima di Paging, Sync o di una funzione del fornitore, un client corretto legge quindi nel Root DSE, tra l’altro, supportedControl, supportedExtension, supportedFeatures e supportedLDAPVersion e supportedSASLMechanisms (RFC 4511, sezione 4.1.11, RFC 4512, sezione 5.1).

Bind, SASL e confini di fiducia TLS

Il Bind decide a chi il server attribuisce la ricerca successiva. Nel Simple Bind occorre distinguere tre casi: DN vuoto e password vuota producono accesso anonimo. Un DN non vuoto con password vuota è un unauthenticated Bind e non conferma esplicitamente l’identità indicata, anche se il server può restituire success. Solo un DN non vuoto con password non vuota costituisce la normale autenticazione nome/password. I client dovrebbero quindi rifiutare password vuote già prima della richiesta; i server non dovrebbero abilitare inavvertitamente gli unauthenticated Binds (RFC 4513, sezioni da 5.1.1 a 5.1.3 e 6.3.1).

Con questa autenticazione a password, il server conosce il segreto presentato. Il trasporto deve quindi essere non solo cifrato, ma anche autenticato. Ciò include una catena di certificati valida e la verifica che il nome DNS configurato sia presente nel certificato. Chi accetta ogni certificato o usa un indirizzo IP può stabilire un canale cifrato verso la controparte sbagliata. La stessa verifica vale per StartTLS e LDAP con TLS immediato (RFC 4513, sezioni 3.1 e 5.1.3, RFC 9525, sezioni 2 e 4, TLS).

SASL consente meccanismi di autenticazione diversi da un semplice password Bind e può inoltre negoziare una protezione per i messaggi LDAP successivi. In Active Directory si incontrano in particolare Negotiate, Kerberos e NTLM. LDAP Signing protegge l’integrità di determinate sessioni SASL; Channel Binding collega l’autenticazione alla connessione TLS sottostante. TLS, Signing e Channel Binding risolvono dunque problemi affini, ma non identici. Un test deve riprodurre il reale tipo di Bind del prodotto (RFC 4513, sezione 5.2, Microsoft: LDAP signing, MS-ADTS, Channel Binding).

Per introdurre policy AD più rigide non basta quindi guardare la versione di Windows. Le nuove distribuzioni AD DS su Windows Server 2025 richiedono LDAP Signing per impostazione predefinita, mentre gli aggiornamenti mantengono le impostazioni esistenti. Microsoft indica gli eventi Directory Service dal 2886 al 2889 per Signing e dal 3039 al 3041 per Channel Binding. Questi dati di audit mostrano quali client, porte e metodi di Bind sarebbero effettivamente interessati; solo dopo è possibile pianificare l’applicazione sulla base di dati affidabili (Microsoft: LDAP signing, Default Security Behavior e Event Monitoring, Microsoft: LDAP session security after ADV190023).

Search: base, scope, filtro e proiezione degli attributi

Dopo un Bind sicuro segue l’operazione da cui dipendono la maggior parte delle integrazioni: Search. La richiesta indica un Base DN, lo Scope, la gestione degli alias, i propri limiti di dimensione e tempo, un filtro e gli attributi desiderati. baseObject legge solo l’entry base, singleLevel i suoi figli diretti e wholeSubtree l’intero sottoalbero inclusa la base. Il server può impostare limiti più rigidi. Zero risultati con success sono una risposta valida; noSuchObject significa invece che la base di ricerca manca o non è visibile per questa identità (RFC 4511, sezioni 4.5.1 e 4.5.2).

Il filtro non descrive una libera logica SQL, bensì un albero in notazione prefissa. (&(objectClass=person)(mail=*@example.ch)) combina ad esempio un’espressione Equality con una Substring. | indica OR, ! NOT, =* Presence e := un Extensible Match. La Matching Rule del rispettivo attributo determina se un confronto usa maiuscole/minuscole, ordinamento numerico o semantica DN (RFC 4511, sezione 4.5.1, RFC 4515, RFC 4517).

La generazione dei filtri diventa così un compito di sicurezza. I valori provenienti da input utente devono essere codificati secondo RFC 4515; in particolare *, parentesi, backslash, NUL e ottetti UTF-8 non validi non devono entrare in forma non elaborata nell’espressione. Una concatenazione di stringhe può altrimenti modificare la struttura del filtro e rendere possibile LDAP injection. L’escaping DN secondo RFC 4514 segue regole diverse e non sostituisce il filter encoding (RFC 4515, sezione 3, RFC 4514, sezione 3).

Oltre al filtro, l’elenco di attributi determina quanto restituisce il server. Un elenco vuoto richiede tutti i normali attributi utente, 1.1 nessun attributo, * tutti gli attributi utente e + tutti gli attributi operativi secondo RFC 3673. Le ACL possono comunque nascondere valori. I client in produzione dovrebbero richiedere solo gli attributi necessari: grandi valori multivalore gravano su rete, decoder e memoria e possono attivare limiti propri del server (RFC 4511, sezione 4.5.1.8, RFC 3673).

Paging, ordinamento e risultati variabili

Le quantità di risultati più grandi vengono normalmente trasmesse con il Simple Paged Results Control. Il server allega a ogni pagina un cookie opaco, che il client restituisce insieme alla stessa richiesta. Questo cookie non è un offset né un cursore permanente. Se il contenuto della directory cambia durante la sequenza, le entry possono mancare o comparire due volte. Il paging limita dunque il volume di dati per risposta, ma non genera uno snapshot coerente (RFC 2696, sezioni 2 e 3).

Active Directory rende questa distinzione visibile nella pratica quotidiana: la LDAP Policy MaxPageSize limita per impostazione predefinita i risultati non paginati a 1000 oggetti. Un’importazione che riceve esattamente 1000 entry non ha quindi dimostrato la propria completezza. Il client deve elaborare correttamente pagine e cookie e rilevare un’interruzione. Altre policy limitano durata della query, Receive Buffer e Result Sets mantenuti contemporaneamente. Per l’esercizio devono pertanto essere registrati dimensione della pagina, numero di pagine, ultimo avanzamento del cookie, timeout e riavvio (MS-ADTS, LDAP Policies, Microsoft: Paging Search Results).

Active Directory come profilo di server LDAP

Le regole precedenti valgono per LDAP in generale. Active Directory Domain Services è un’implementazione server concreta con ruoli e convenzioni aggiuntivi. I suoi dati sono distribuiti su Naming Contexts; un Domain Controller mantiene almeno Schema, Configuration e il Domain Naming Context proprio. Il Root DSE ha il DN vuoto e indica tra l’altro defaultNamingContext, configurationNamingContext, schemaNamingContext, tutti i namingContexts, il nome del server e i meccanismi supportati. Dopo TCP e TLS, questa entry è il primo test che dice effettivamente qualcosa sul servizio di directory raggiunto (RFC 4512, sezione 5.1, Microsoft RootDSE, MS-ADTS, rootDSE Attributes).

La scelta tra Domain Controller e Global Catalog modifica il risultato della ricerca. Un DC serve LDAP sulla porta 389 o 636 e conosce il Domain Naming Context completo del proprio dominio. Il Global Catalog usa inoltre 3268 o 3269 e conserva una replica parziale di tutti i domini della foresta. Può trovare oggetti nell’intera foresta, ma per i domini remoti fornisce soltanto attributi del Partial Attribute Set. Un risultato trovato con successo non prova quindi ancora che l’attributo richiesto dall’applicazione sia disponibile (MS-ADTS, Ports, Microsoft: Searching the Global Catalog, Microsoft: Attributes included in the Global Catalog).

Anche i filtri possono diventare specifici di AD. La Matching Rule 1.2.840.113556.1.4.1941, LDAP_MATCHING_RULE_TRANSITIVE_EVAL, ad esempio, segue attributi collegati e può valutare gruppi annidati. Il relativo supporto non compare semplicemente in supportedControl. Inoltre, memberOf non contiene il Primary Group. Una decisione di autorizzazione basata sulle appartenenze a gruppi deve quindi considerare esplicitamente annidamento dei gruppi, Primary Group, scope del gruppo, visibilità ACL e stato di replica (MS-ADTS, LDAP Matching Rules, Microsoft: Primary group membership).

Quale server risponde a queste interrogazioni è deciso nei client Windows dal DC Locator insieme ai record DNS-SRV. I record correlati a sito e ruolo forniscono candidati con priorità e peso. Un IP inserito staticamente aggira questa selezione e complica la verifica del certificato. Un semplice load balancer TCP distribuisce sì le connessioni, ma senza logica aggiuntiva non conosce né DC scrivibili né Global Catalogs, Naming Contexts o lo stato della replica (Microsoft: DC Locator, Microsoft: Verify LDAP SRV records).

Infine, la raggiungibilità LDAP non deve essere confusa con una replica sana. AD replica le modifiche alla directory mediante il Directory Replication Service Remote Protocol; syncrepl di OpenLDAP usa invece LDAP Content Synchronization con provider, consumer e cookie. Una ricerca di test può mostrare che un determinato server risponde. Se tutti i server possiedono le stesse modifiche e recuperano dopo un guasto deve essere verificato con gli strumenti della rispettiva piattaforma (MS-DRSR, Relationship to Other Protocols, RFC 4533, OpenLDAP Administrator’s Guide: Replication).

Modelli di integrazione e operativi

Per l’esercizio è ora meno importante che un prodotto «supporti LDAP», bensì come utilizza LDAP. Con una lookup in tempo reale, un messaggio o una sessione attende direttamente Search e la risposta del server. Con il Credential Check, un account tecnico cerca prima il DN dell’utente e quindi esegue un secondo Bind con la password inserita. Un import o cache, invece, legge molte entry e opera fino all’esecuzione successiva con una copia locale. Questi modelli hanno conseguenze diverse per latenza, gestione delle password, failover e aggiornamento dei dati; la documentazione del prodotto deve indicare il comportamento concreto (RFC 4511, sezioni 4.2 e 4.5, RFC 2696).

Indipendentemente dal modello, il client necessita di timeout separati per Connect, Bind, Operation e Idle. Un Connection Pool risparmia l’instaurazione di TCP, TLS e Bind, ma mantiene con sé lo stato di autenticazione della connessione. Le sessioni morte devono essere rilevate e una connessione non deve cambiare inavvertitamente tra utenti o tenant. Il failover richiede un ordine di destinazione comprensibile, ripetizioni limitate e un percorso di ritorno verso la destinazione preferita. Altrimenti i retry paralleli moltiplicano il carico proprio durante un guasto della directory (RFC 4511, sezioni 3.1, 4.2 e 5.3).

Sul lato server, Base DN, Scope, filtro e lista degli attributi determinano il lavoro. Una condizione di uguaglianza selettiva su un attributo indicizzato è diversa da una substring iniziale o da una grande espressione OR. LDAP non pubblica un piano di esecuzione né prescrive una tecnica di indicizzazione. L’amministratore deve pertanto correlare i filtri reali del prodotto con quantità di risultati, latenza p95/p99 e metriche del server. Una ricerca rapida di un singolo account di test non dimostra che una verifica del destinatario sia scalabile sotto carico di punta (OpenLDAP Administrator’s Guide: Performance Tuning, MS-ADTS: LDAP Policies).

Il monitoraggio dovrebbe scomporre il flusso nelle stesse fasi della ricerca guasti: selezione DNS, instaurazione TCP e TLS, Bind, latenza Search, Result Code, numero di risultati e avanzamento del paging. Si aggiungono occupazione del pool, tasso di retry e stato di importazione o sync. Un singolo Bind sintetico può confermare la raggiungibilità, ma non rileva né attributi mancanti né un’importazione incompleta o un partner di replica arretrato.

Anche per backup e recovery il contenuto visibile della directory non basta. Occorre salvaguardare schema, ACL, configurazione backend e server, chiavi e certificati, identità di replica nonché la procedura con cui un nodo ripristinato viene riammesso nella topologia. Active Directory usa a tale scopo System State e propri passaggi di forest recovery; OpenLDAP dipende dal proprio backend. Il manuale distingue ad esempio un backup LMDB da slapcat e avverte di stati LDIF semanticamente incoerenti in caso di modifiche multipart. LDAP stesso non definisce un meccanismo di backup (Microsoft: Back up the System State data, OpenLDAP Administrator’s Guide: Directory Backups).

Un test di ripristino è concluso soltanto quando un client trova il servizio ripristinato tramite il nome DNS previsto, TLS e Bind hanno successo, Root DSE e schema sono corretti, ricerche reali restituiscono attributi completi e la replica riprende in modo controllato. Il recovery riporta così all’inizio dell’articolo: conta l’intero percorso, non soltanto un database avviato.

Strumenti diagnostici

La diagnosi segue lo stesso percorso di una query in produzione. Inizia nella rete dell’applicazione interessata e usa il suo nome DNS, truststore, metodo di Bind, Base DN, filtro e lista degli attributi. Un test dal laptop dell’amministratore può altrimenti avere successo, mentre il gateway continua a usare un altro DC, un’altra CA o un altro scope. Gli esempi usano nomi riservati e leggono soltanto metadati; le password Bind non appartengono né alla shell history né agli argomenti di processo. ldapsearch -W le richiede in modo interattivo.

Determinare le destinazioni del servizio tramite DNS

Resolve-DnsName e dig mostrano target, porte, priorità e pesi. Successivamente vanno verificate risoluzione A/AAAA, riferimento al sito e raggiungibilità di ogni target effettivamente selezionabile. Un singolo DC raggiungibile non corregge un set SRV errato (Microsoft: DC Locator).

Verificare TCP e TLS implicito sulla porta 636

Test-NetConnection dimostra inizialmente soltanto la connessione TCP. Il successivo .NET SslStream o openssl s_client verifica TLS con il nome DNS configurato. s_client -showcerts mostra soltanto i certificati inviati dal server e, da solo, non costituisce una prova riuscita della chain o dell’hostname. StartTLS sulla porta 389 può essere verificato separatamente sotto Unix con openssl s_client -starttls ldap (OpenSSL s_client, RFC 4511, sezione 4.14).

Leggere Root DSE e capacità

Get-ADRootDSE usa qui il modulo ActiveDirectory e per impostazione predefinita l’identità Windows connessa. ldapsearch impone con -ZZ StartTLS riuscito e legge anonimamente soltanto gli attributi Root DSE rilasciati dal server. Un OID mancante dimostra che proprio questa destinazione non pubblica la funzione; non dice nulla sugli altri nodi del cluster.

Riprodurre una ricerca reale con scope, filtro e paging

Get-ADUser accetta con -LDAPFilter la sintassi del filtro vicina a RFC e gestisce il paging tramite -ResultPageSize. ldapsearch usa -E pr=500/noprompt per il Paged Results Control e -W per una richiesta di password interattiva. Oltre al risultato, il test deve documentare risultato finale, numero di pagine, attributi restituiti e durata.

Attribuire un errore a un confine

I Result Codes numerici appartengono al protocollo LDAP; diagnosticMessage e ulteriori subcodici AD sono invece contesto specifico dell’implementazione. L’automazione dovrebbe quindi valutare prima il Result Code e registrare il testo come integrazione. Per busy e unavailable ogni client necessita di un budget di retry limitato con backoff. Ripetizioni illimitate trasformano un singolo problema di directory in un picco di carico su tutti i sistemi dipendenti (RFC 4511, sezione 4.1.9 e appendice A).

Storia tecnica

LDAP non nacque come database di directory indipendente. Alla fine degli anni 1980, X.500 aveva definito un modello di directory completo e il Directory Access Protocol. RFC 1487 descrisse nel 1993 un accesso più leggero a questo modello; RFC 1777 seguì nel 1995 come LDAP Version 2. «Lightweight» si riferiva all’accesso al protocollo semplificato rispetto a DAP, non a directory piccole o a scarsa rilevanza operativa. Lo sviluppo iniziale è strettamente collegato a Tim Howes e all’University of Michigan (RFC 1487, RFC 1777).

LDAPv3 fu pubblicato nel 1997 con RFC 2251 e documenti di accompagnamento. Operazioni estendibili, Controls, SASL, internazionalizzazione e il modello dati rivisto lo resero la base delle implementazioni odierne. Il lavoro LDAPbis riorganizzò questo stato nel 2006: RFC 4510 funge da roadmap, RFC 4511 descrive il protocollo, RFC 4512 il modello informativo e RFC 4513 la sicurezza; RFC da 4514 a 4519 completano rappresentazioni, URL, sintassi e schema (RFC 2251, RFC 4510, sezione 3).

Parallelamente si svilupparono server molto diversi. OpenLDAP nacque nel 1998 dall’implementazione dell’University of Michigan e proseguì slapd, librerie e strumenti come progetto open source. Con Windows 2000, Active Directory portò nell’ampio uso aziendale un profilo LDAPv3 con schema proprio, Naming Contexts, Controls, Matching Rules e protocollo di replica separato (OpenLDAP Release Road Map, OpenLDAP Administrator’s Guide – Preface, MS-ADTS).

Questa storia spiega la regola operativa più importante: LDAP uniforma l’accesso, non l’architettura interna. Chi sposta un client da OpenLDAP a AD DS o tra due appliance deve quindi verificare più di host, porta e Bind DN. Schema, Controls, limiti, risoluzione dei gruppi, replica e recovery rimangono caratteristiche del prodotto.

Fonti

• RFC 4510, sezioni 1 e 2
• RFC 4511 – LDAP: The Protocol – livello dei messaggi, operazioni, BER, TCP, StartTLS e Result Codes.
• IANA – Service Name and Port Number Registry – ldap 389 e ldaps 636.
• MS-ADTS – Using SSL/TLS – TLS implicito e StartTLS in Active Directory.
• RFC 5805, sezioni 1 e 3
• RFC 4512 – LDAP Directory Information Models – DIT, Entries, attributi, schema, Root DSE e subschema.
• RFC 4514, sezioni 2 e 3
• RFC 2849, sezioni 2 e 4
• RFC 4517 – LDAP Syntaxes and Matching Rules – sintassi standard e regole di confronto.
• RFC 4520 – IANA Considerations for LDAP – registrazione di OID e parametri del protocollo.
• RFC 4513 – LDAP Authentication Methods and Security Mechanisms – metodi Bind, SASL, TLS e confini di sicurezza.
• RFC 9525, sezioni 2 e 4
• Microsoft – LDAP signing for AD DS – Signing, Channel Binding, impostazioni predefinite ed eventi.
• MS-ADTS – Channel Binding – LDAP Channel Binding in Active Directory.
• Microsoft – LDAP session security after ADV190023 – requisiti di sicurezza per modello Bind e TLS.
• RFC 4515 – String Representation of Search Filters – grammatica dei filtri e Value Encoding.
• RFC 3673 – All Operational Attributes – + come selettore di attributi per attributi operativi.
• RFC 2696 – Simple Paged Results Control – pagine, cookie e limiti di coerenza.
• MS-ADTS – LDAP Policies – limiti amministrativi di ricerca e risorse.
• Microsoft – Paging Search Results – Paged Search in Active Directory.
• Microsoft – RootDSE – Naming Contexts e capacità del server.
• MS-ADTS – rootDSE Attributes – attributi Root DSE specifici di AD.
• MS-ADTS – Ports – porte LDAP, LDAPS e Global Catalog.
• Microsoft – Searching the Global Catalog – ricerca nell’intera foresta e replica parziale.
• Microsoft – Attributes included in the Global Catalog – Partial Attribute Set del Global Catalog.
• MS-ADTS – LDAP Matching Rules – OID Extensible Match specifici di AD.
• Microsoft – Primary group membership – delimitazione tra memberOf e Primary Group.
• Microsoft – DC Locator – selezione DNS-SRV, LDAP Ping e riferimento al sito.
• Microsoft – Verify LDAP SRV records – registrazione SRV dei Domain Controller.
• MS-DRSR – Relationship to Other Protocols – delimitazione della replica AD da LDAP.
• RFC 4533 – LDAP Content Synchronization Operation – controlli LDAP Sync, cookie e modello di stato.
• OpenLDAP Administrator’s Guide – Replication – syncrepl, cookie e modello provider/consumer.
• OpenLDAP Administrator’s Guide – Performance Tuning – indicizzazione e costi di ricerca interni al server.
• Microsoft – Back up the System State data – backup System State per AD DS.
• OpenLDAP Administrator’s Guide – Directory Backups – backup LMDB, slapcat e limiti di coerenza.
• Microsoft Learn – Resolve-DnsName – query DNS e SRV in Windows.
• BIND 9 – dig manual – query DNS e SRV in sistemi Unix.
• Microsoft Learn – Test-NetConnection – diagnostica della connessione TCP in Windows.
• Microsoft Learn – SslStream – handshake TLS e verifica del certificato con .NET.
• OpenSSL – s_client – handshake TLS, verifica del nome e LDAP StartTLS.
• Microsoft Learn – Get-ADRootDSE – diagnostica Root DSE in Windows.
• OpenLDAP – ldapsearch(1) – opzioni Search, StartTLS, SASL e Control.
• Microsoft Learn – Get-ADUser – LDAPFilter, SearchBase, Scope e Paging.
• RFC 1487 – X.500 Lightweight Directory Access Protocol – prima specifica LDAP del 1993.
• RFC 1777 – Lightweight Directory Access Protocol – LDAPv2 e modello storico del protocollo.
• RFC 2251 – Lightweight Directory Access Protocol v3 – prima specifica centrale LDAPv3.
• OpenLDAP – Release Road Map – Release 1.0 nell’agosto 1998.
• OpenLDAP Administrator’s Guide – Preface – LDAP dell’University of Michigan come base del progetto.
• MS-ADTS – Active Directory Technical Specification – profilo di server LDAP di AD DS e AD LDS.