LDAP: protokoll, datamodell och katalogdrift

LDAP är det gemensamma språk som program använder för att komma åt katalogtjänster. Med det kan en klient söka efter namngivna poster, läsa eller ändra attribut och autentisera sig mot katalogen. Protokollet definierar meddelanden, operationer och felkoder. Hur en server lagrar sina data, replikerar dem eller skyddar mot avbrott är däremot upp till respektive implementering. Active Directory Domain Services, OpenLDAP och 389 Directory Server talar därför LDAP utan att internt vara samma plattform (RFC 4510, avsnitt 1 och 2, RFC 4511, avsnitt 3).

Denna åtskillnad är avgörande i meddelandedriften. En gateway kan före SMTP-mottagning kontrollera om en mottagare finns, slå upp grupper för en policy eller logga in en administratör. Om denna fråga misslyckas eller returnerar inaktuella data är det inte bara «LDAP-störning»: beroende på integration kan meddelanden avvisas, regler tillämpas fel eller inloggningar blockeras. Administratören måste därför veta var på vägen från DNS-namnet till det lästa attributet som avbrottet finns.

Förklaringen följer denna väg. Först hittar klienten en server och upprättar en skyddad session. Därefter autentiserar den sig, skickar en sökning och tolkar svaren. Först när detta normala flöde är tydligt går det att placera in schema, Active Directory-särdrag, replikering, skalning och återställning på ett meningsfullt sätt.

Protokollstack och sessionsmodell

Innan ett program kan söka behöver det ett konkret tjänstmål. I Active Directory-miljöer tillhandahåller DNS-SRV-poster möjliga Domain Controllers eller Global Catalogs; andra produkter använder statiska FQDN:er, egen tjänsteupptäckt eller en lastbalanserare. Detta val avgör inte bara IP-adressen utan även plats, serverroll och det namn mot vilket certifikatet kontrolleras. Ett porttest mot en godtycklig nåbar server besvarar därför ännu inte om programmet når sitt avsedda mål.

På det valda målet bygger LDAP en TCP-anslutning. Port 389 börjar som LDAP och kan växla till en skyddad session med StartTLS Extended Operation. Port 636 är registrerad hos IANA som ldaps och används bland annat av Active Directory för TLS som startar omedelbart. I båda fallen måste klienten kontrollera certifikatkedjan och servernamnet; «krypterad» och «ansluten till rätt server» är två olika bevis (RFC 4511, avsnitt 4.14 och 5, IANA Service Name Registry, MS-ADTS, Using SSL/TLS).

Inom denna anslutning överför LDAP inga läsbara kommandorader som SMTP. Meddelandena beskrivs som ASN.1-strukturer och kodas med Basic Encoding Rules, BER. Varje LDAPMessage innehåller ett messageID, exakt en operation och valfria kontroller. Med Message-ID kan en långlivad anslutning hålla isär flera pågående operationer; deras svar behöver inte komma i frågeordning. En lyckad TCP-handshake säger alltså inget om BER-avkodning, bindning eller en helt avslutad sökning (RFC 4511, avsnitt 3.1, 4.1.1 och 5.1).

För ändringar gäller en viktig gräns: en enskild LDAP-operation är atomär inom sitt omfång, men flera poster utgör ingen gemensam transaktion i kärnprotokollet. RFC 5805 beskriver en experimentell transaktionsutökning, vars stöd klienten måste identifiera vid Root DSE. Även där måste det kontrolleras hur repliker ser ändringen. Provisioneringsprocesser behöver därför egna regler för upprepning, delfel och avstämning i stället för en tyst förutsatt databastransaktion (RFC 4511, avsnitt 3, RFC 5805, avsnitt 1 och 3).

Datamodell: DIT, Entry, attribut och schema

Efter sessionsuppbyggnaden måste klienten kunna ange var och vad den söker. LDAP organiserar därför katalogdata som ett Directory Information Tree, förkortat DIT. Varje Entry har ett unikt Distinguished Name och attribut. Schemat beskriver vilka attribut som finns, hur deras värden jämförs och vilka Object Classes de kräver eller tillåter. Utan denna modell är sökbas, filter och resultat bara strängar utan tillförlitlig betydelse (RFC 4512, avsnitt 2 och 3, RFC 4511, avsnitt 4.1.7).

Distinguished Name utgör sökvägen till en post i trädet. I cn=Mail Gateway,ou=Services,dc=example,dc=ch betecknar cn=Mail Gateway det lokala Relative Distinguished Name; följande RDN:er leder via containern till namnroten. Eftersom RDN:er kan vara flervärda och tecken som komma, plus eller omvänt snedstreck måste escape-kodas får programvara inte bearbeta ett DN genom enkel uppdelning vid kommatecken. Den behöver en RFC-4514-kompatibel parser (RFC 4512, avsnitt 2.3, RFC 4514, avsnitt 2 och 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

För export och import finns LDIF, en standardiserad textrepresentation. LDIF avbildar Entries eller ändringsposter, men är inte wireformatet för den pågående LDAP-sessionen. Radbrytning, Base64-värden och Change Records följer egna regler. Framför allt innehåller en export bara det som servern och behörigheterna gör synligt; operativa attribut, ACL:er eller backendstatus kan saknas. En LDIF-dump är därför ett datautdrag, men inte automatiskt en återställningsbar serverbackup (RFC 2849, avsnitt 2 och 4).

Betydelsen hos ett attributvärde kommer först från schemat. En Matching Rule som caseIgnoreMatch, integerMatch eller en DN-jämförelse avgör om två värden är lika och vilka filter som fungerar för dem. På wire-nivå framträder värden först som Octet Strings; syntax och attributtyp ger dem deras tolkning. Egna schemaelement behöver därför varaktigt unika OID:er, definierade syntaxer och Matching Rules samt en utrullning som tar hänsyn till server och alla beroende klienter samtidigt (RFC 4512, avsnitt 4, RFC 4517, RFC 4520).

Operationer och tillståndsändringar

Med transport, namn och schema finns grundstrukturen; nu börjar den egentliga protokolldialogen. Den första avgörande tillståndsändringen är vanligen Bind. Den fastställer under vilken identitet och med vilka därav härledda rättigheter följande operationer körs. En ny bindning ersätter detta tillstånd. Medan servern bearbetar en bindning får klienten inte starta andra operationer på samma anslutning (RFC 4511, avsnitt 3.1 och 4.2).

Efter lyckad bindning kan klienten läsa eller skriva. En sökning ger inte ett enda stort svar utan noll eller flera SearchResultEntry-meddelanden, eventuellt References och till sist exakt ett SearchResultDone. Först detta slutresultat visar om sekvensen var fullständig. Modify, Add, Delete och ModifyDN ändrar poster; Compare kontrollerar ett attributvärde enligt dess Matching Rule utan att returnera en vanlig sökträff (RFC 4511, avsnitt 4.5 till 4.9).

Även sessionsslutet har tydlig semantik. Unbind är en ensidig begäran om stängning och har inget svar. Abandon ber servern att avbryta en viss operation, men garanterar inte avbrottet. Om TCP i stället bryts försvinner alla pågående operationer. Vid en skrivoperation kan klienten då inte säkert veta om ändringen hann träda i kraft före eller efter anslutningsförlusten; en retry kräver därför först en tillståndsavstämning i stället för blind upprepning (RFC 4511, avsnitt 4.3 och 4.11).

Controls och Extended Operations kompletterar detta flöde utan att införa en ny LDAP-version. Varje Control har en OID, en Criticality och valfritt ett BER-kodat värde. Om en klient markerar en okänd eller icke körbar Control som kritisk måste operationen misslyckas med unavailableCriticalExtension; annars får servern ignorera den. Före Paging, Sync eller en leverantörsfunktion läser en korrekt klient därför bland annat supportedControl, supportedExtension, supportedFeatures, supportedLDAPVersion och supportedSASLMechanisms från Root DSE (RFC 4511, avsnitt 4.1.11, RFC 4512, avsnitt 5.1).

Bind, SASL och TLS-förtroendegränser

Bindningen avgör vem servern tillskriver nästa sökning. Vid Simple Bind måste tre fall skiljas åt: tomt DN och tomt lösenord ger anonym åtkomst. Ett icke tomt DN med tomt lösenord är en unauthenticated Bind och bekräftar uttryckligen inte den angivna identiteten, även om servern kan returnera success. Först ett icke tomt DN med icke tomt lösenord utgör normal namn-/lösenordsautentisering. Klienter bör därför avvisa tomma lösenord redan före requestet; servrar bör inte av misstag tillåta unauthenticated Binds (RFC 4513, avsnitt 5.1.1 till 5.1.3 och 6.3.1).

Vid denna lösenordsautentisering känner servern till den presenterade hemligheten. Transporten måste därför inte bara vara krypterad utan även autentiserad. Detta omfattar en giltig certifikatkedja och kontroll av att det konfigurerade DNS-namnet finns i certifikatet. Den som accepterar alla certifikat eller använder en IP-adress kan upprätta en krypterad kanal till fel motpart. Samma kontroll gäller StartTLS och LDAP med omedelbar TLS (RFC 4513, avsnitt 3.1 och 5.1.3, RFC 9525, avsnitt 2 och 4, TLS).

SASL tillåter olika autentiseringsmekanismer i stället för enbart lösenordsbindning och kan dessutom förhandla fram skydd för efterföljande LDAP-meddelanden. I Active Directory förekommer särskilt Negotiate, Kerberos och NTLM. LDAP Signing skyddar där integriteten hos vissa SASL-sessioner; Channel Binding knyter autentiseringen till den underliggande TLS-anslutningen. TLS, Signing och Channel Binding löser således relaterade men inte identiska problem. Ett test måste avbilda produktens faktiska bindningstyp (RFC 4513, avsnitt 5.2, Microsoft: LDAP signing, MS-ADTS, Channel Binding).

Vid införande av striktare AD-principer räcker det därför inte att titta på Windows-versionen. Nya AD-DS-distributioner på Windows Server 2025 kräver LDAP Signing som standard, medan uppgraderingar övertar befintliga inställningar. Microsoft anger Directory Service-händelserna 2886 till 2889 för Signing samt 3039 till 3041 för Channel Binding. Dessa revisionsdata visar vilka klienter, portar och bindningsmetoder som faktiskt skulle påverkas; först därefter kan genomdrivandet planeras på ett hållbart dataunderlag (Microsoft: LDAP signing, Default Security Behavior och Event Monitoring, Microsoft: LDAP session security after ADV190023).

Search: bas, scope, filter och attributprojektion

Efter säker bindning följer operationen som de flesta integrationer är beroende av: Search. Requestet anger ett Base DN, scope, aliashantering, egna Size- och Time-Limits, ett filter och önskade attribut. baseObject läser endast basposten, singleLevel dess direkta barn och wholeSubtree hela underträdet inklusive basen. Servern får sätta striktare gränser. Noll träffar med success är ett giltigt svar; noSuchObject betyder däremot att sökbasen saknas eller inte är synlig för denna identitet (RFC 4511, avsnitt 4.5.1 och 4.5.2).

Filtret beskriver inte fri SQL-logik utan ett träd i prefixnotation. (&(objectClass=person)(mail=*@example.ch)) sammanfogar exempelvis ett Equality-uttryck med ett Substring-uttryck. | står för OR, ! för NOT, =* för Presence och := för ett Extensible Match. Huruvida en jämförelse använder versal-/gemen-känslighet, talordning eller DN-semantik avgörs av attributets Matching Rule (RFC 4511, avsnitt 4.5.1, RFC 4515, RFC 4517).

Därmed blir skapandet av filter en säkerhetsuppgift. Värden från användarinmatningar måste kodas enligt RFC 4515; särskilt *, parenteser, omvänt snedstreck, NUL och ogiltiga UTF-8-oktetar får inte hamna råa i uttrycket. Strängkonkatenering kan annars ändra filterstrukturen och möjliggöra LDAP-injektion. DN-escaping enligt RFC 4514 följer andra regler och ersätter inte filterkodning (RFC 4515, avsnitt 3, RFC 4514, avsnitt 3).

Utöver filtret bestämmer attributlistan hur mycket servern returnerar. En tom lista begär alla vanliga användarattribut, 1.1 inga attribut, * alla användarattribut och + enligt RFC 3673 alla operativa attribut. ACL:er kan fortfarande dölja värden. Produktionsklienter bör bara begära attribut som behövs: stora flervärden belastar nätverk, avkodare och minne och kan utlösa egna servergränser (RFC 4511, avsnitt 4.5.1.8, RFC 3673).

Paging, sortering och föränderliga resultat

Större resultatmängder överförs vanligen med Simple Paged Results Control. Servern skickar med en ogenomskinlig cookie för varje sida som klienten skickar tillbaka tillsammans med samma request. Denna cookie är varken en offset eller en permanent cursor. Om kataloginnehållet förändras under sekvensen kan poster saknas eller förekomma dubbelt. Paging begränsar alltså datamängden per svar men skapar ingen konsekvent snapshot (RFC 2696, avsnitt 2 och 3).

Active Directory gör denna skillnad synlig i vardagen: LDAP Policy MaxPageSize begränsar opaginerade resultat till 1000 objekt som standard. En import som får exakt 1000 poster har därför inte bevisat sin fullständighet. Klienten måste bearbeta sidor och cookies korrekt och upptäcka avbrott. Ytterligare policyer begränsar frågetid, Receive Buffer och samtidiga Result Sets. I drift bör därför Page Size, antal sidor, senaste cookieförlopp, timeout och återstart loggas (MS-ADTS, LDAP Policies, Microsoft: Paging Search Results).

Active Directory som LDAP-serverprofil

De tidigare reglerna gäller LDAP generellt. Active Directory Domain Services är en konkret serverimplementering med ytterligare roller och konventioner. Dess data är fördelade över Naming Contexts; en Domain Controller har minst Schema, Configuration och sin egen Domain-Naming-Context. Root DSE har det tomma DN:t och anger bland annat defaultNamingContext, configurationNamingContext, schemaNamingContext, alla namingContexts, servernamnet och stödda mekanismer. Efter TCP och TLS är denna post det första test som faktiskt säger något om den uppnådda katalogtjänsten (RFC 4512, avsnitt 5.1, Microsoft RootDSE, MS-ADTS, rootDSE Attributes).

Valet mellan Domain Controller och Global Catalog ändrar sökresultatet. En DC tillhandahåller LDAP på 389 respektive 636 och känner till hela Domain-Naming-Context för sin domän. Global Catalog använder dessutom 3268 eller 3269 och har en partiell replik från alla domäner i skogen. Den kan hitta objekt i hela skogen men returnerar för externa domäner bara attribut ur Partial Attribute Set. En lyckad träff bevisar därför ännu inte att attributet som programmet behöver finns tillgängligt (MS-ADTS, Ports, Microsoft: Searching the Global Catalog, Microsoft: Attributes included in the Global Catalog).

Även filter kan bli AD-specifika. Matching Rule 1.2.840.113556.1.4.1941, LDAP_MATCHING_RULE_TRANSITIVE_EVAL, följer exempelvis länkade attribut och kan utvärdera nästlade grupper. Dess stöd anges inte bara i supportedControl. Dessutom innehåller memberOf inte Primary Group. Ett auktoriseringsbeslut baserat på gruppmedlemskap måste därför uttryckligen ta hänsyn till gruppnästling, Primary Group, gruppscope, ACL-synlighet och replikeringsstatus (MS-ADTS, LDAP Matching Rules, Microsoft: Primary group membership).

Vilken server som besvarar dessa frågor avgörs för Windows-klienter av DC Locator tillsammans med DNS-SRV-poster. Plats- och rollrelaterade poster ger kandidater med prioritet och vikt. En statiskt angiven IP kringgår detta urval och försvårar certifikatkontrollen. En enkel TCP-lastbalanserare fördelar visserligen anslutningar, men känner utan ytterligare logik varken skrivbara DC:er eller Global Catalogs, Naming Contexts eller replikeringsstatus (Microsoft: DC Locator, Microsoft: Verify LDAP SRV records).

Slutligen får LDAP-nåbarhet inte förväxlas med frisk replikering. AD replikerar katalogändringar via Directory Replication Service Remote Protocol; OpenLDAPs syncrepl använder däremot LDAP Content Synchronization med Provider, Consumer och Cookies. En testsökning kan visa att en viss server svarar. Om alla servrar har samma ändringar och återhämtar sig efter ett avbrott måste kontrolleras med verktygen för respektive plattform (MS-DRSR, Relationship to Other Protocols, RFC 4533, OpenLDAP Administrator’s Guide: Replication).

Integrations- och driftsmodeller

För driften är det nu mindre viktigt att en produkt «stöder LDAP» än hur den använder LDAP. Vid en uppslagning vid körning väntar ett meddelande eller en session direkt på Search och serversvar. Vid Credential Check söker ett tekniskt konto först efter användarens DN och utför därefter en andra bindning med det angivna lösenordet. En import eller cache läser däremot många poster och arbetar med en lokal kopia fram till nästa körning. Dessa mönster får olika följder för latens, lösenordshantering, failover och dataålder; produktdokumentationen måste beskriva det konkreta beteendet (RFC 4511, avsnitt 4.2 och 4.5, RFC 2696).

Oavsett mönster behöver klienten separata timeouter för Connect, Bind, Operation och Idle. En Connection Pool sparar TCP-, TLS- och bindningsuppbyggnad men bär anslutningens autentiseringstillstånd med sig. Döda sessioner måste upptäckas, och en anslutning får inte av misstag växla mellan användare eller tenants. Failover behöver en spårbar målordning, begränsade upprepningar och en väg tillbaka till föredraget mål. Annars multiplicerar parallella retryer belastningen just under ett katalogavbrott (RFC 4511, avsnitt 3.1, 4.2 och 5.3).

På serversidan avgör Base DN, scope, filter och attributlista arbetet. Ett selektivt likhetsvillkor på ett indexerat attribut är något annat än en inledande substring eller ett stort OR-uttryck. LDAP publicerar ingen exekveringsplan och föreskriver ingen indexteknik. Administratören måste därför korrelera verkliga produktfilter med resultatmängd, p95-/p99-latens och servermått. En snabb sökning efter ett enskilt testkonto bevisar inte att en mottagarkontroll skalar under topplast (OpenLDAP Administrator’s Guide: Performance Tuning, MS-ADTS: LDAP Policies).

Övervakning bör dela upp flödet i samma steg som felsökningen: DNS-val, TCP- och TLS-uppbyggnad, Bind, Search-latens, Result Code, antal träffar och Paging-förlopp. Till detta kommer poolbeläggning, retryfrekvens och status för import eller sync. En enda syntetisk bindning kan bekräfta nåbarhet, men identifierar varken saknade attribut, en ofullständig import eller en replikeringspartner som ligger efter.

För backup och recovery räcker inte heller det synliga kataloginnehållet. Schema, ACL:er, backend- och serverkonfiguration, nycklar och certifikat, replikeringsidentiteter samt metoden för att återföra en återställd nod till topologin måste säkerhetskopieras. Active Directory använder för detta System State och egna Forest Recovery-steg; OpenLDAP beror på sin backend. Handboken skiljer till exempel en LMDB-säkerhetskopia från slapcat och varnar för semantiskt inkonsekventa LDIF-tillstånd vid ändringar i flera delar. LDAP definierar ingen backupmekanism (Microsoft: Back up the System State data, OpenLDAP Administrator’s Guide: Directory Backups).

Ett återställningstest är först slutfört när en klient hittar den återställda tjänsten via det avsedda DNS-namnet, TLS och Bind lyckas, Root DSE och schema stämmer, verkliga sökningar ger fullständiga attribut och replikeringen kontrollerat startar igen. Därmed återvänder recovery till artikelns början: hela vägen räknas, inte bara en startad databas.

Diagnostikverktyg

Diagnostiken följer samma väg som en produktiv fråga. Den börjar i den berörda applikationens nät och använder dess DNS-namn, Truststore, bindningsmetod, Base DN, filter och attributlista. Ett test från administratörens laptop kan annars lyckas medan gatewayen fortsätter att använda en annan DC, ett annat CA eller ett annat scope. Exemplen använder reserverade namn och läser bara metadata; bindningslösenord hör varken hemma i shellhistoriken eller i processargument. ldapsearch -W frågar efter dem interaktivt.

Identifiera tjänstmål via DNS

Resolve-DnsName och dig visar targets, portar, prioriteter och vikter. Därefter ska A-/AAAA-upplösning, platsanknytning och nåbarhet för varje faktiskt valbart target kontrolleras. En enskild nåbar DC åtgärdar inte en felaktig SRV-uppsättning (Microsoft: DC Locator).

Kontrollera TCP och implicit TLS på port 636

Test-NetConnection visar först bara TCP-connect. Den efterföljande .NET SslStream respektive openssl s_client kontrollerar TLS med det konfigurerade DNS-namnet. s_client -showcerts visar endast certifikaten som servern skickat och utgör i sig inget lyckat bevis för Chain eller Hostname. StartTLS på 389 kan under Unix kontrolleras separat med openssl s_client -starttls ldap (OpenSSL s_client, RFC 4511, avsnitt 4.14).

Läs Root DSE och funktioner

Get-ADRootDSE använder här ActiveDirectory-modulen och som standard den inloggade Windows-identiteten. ldapsearch tvingar med -ZZ fram lyckad StartTLS och läser anonymt bara Root-DSE-attribut som servern har frisläppt. En saknad OID bevisar att just detta mål inte publicerar funktionen; det säger inget om andra klusternoder.

Återskapa en verklig sökning med scope, filter och paging

Get-ADUser accepterar med -LDAPFilter den RFC-nära filtersyntaxen och utför paging via -ResultPageSize. ldapsearch använder -E pr=500/noprompt för Paged Results Control och -W för interaktiv lösenordsfråga. Testet måste utöver träffen även dokumentera slutresultat, antal sidor, returnerade attribut och körtid.

Tilldela fel till en gräns

Numeriska Result Codes hör till LDAP-protokollet; diagnosticMessage och ytterligare AD-subkoder är däremot implementationsspecifik kontext. Automatisering bör därför först utvärdera Result Code och logga texten som komplement. För busy och unavailable behöver varje klient en begränsad retrybudget med backoff. Obegränsade upprepningar gör ett enskilt katalogproblem till en belastningstopp i alla beroende system (RFC 4511, avsnitt 4.1.9 och bilaga A).

Teknisk historia

LDAP uppstod inte som en självständig katalogdatabas. X.500 hade i slutet av 1980-talet definierat en omfattande katalogmodell och Directory Access Protocol. RFC 1487 beskrev 1993 en lättare åtkomst till denna modell; RFC 1777 följde 1995 som LDAP Version 2. «Lightweight» avsåg den förenklade protokollåtkomsten jämfört med DAP, inte små kataloger eller låg driftsmässig betydelse. Den tidiga utvecklingen är nära förknippad med Tim Howes och University of Michigan (RFC 1487, RFC 1777).

LDAPv3 publicerades 1997 med RFC 2251 och följddokument. Utbyggbara operationer, Controls, SASL, internationalisering och den reviderade datamodellen gjorde det till grunden för dagens implementationer. LDAPbis-arbetet ordnade om denna status 2006: RFC 4510 fungerar som roadmap, RFC 4511 beskriver protokollet, RFC 4512 informationsmodellen och RFC 4513 säkerheten; RFC 4514 till 4519 kompletterar representationer, URL:er, syntaxer och schema (RFC 2251, RFC 4510, avsnitt 3).

Parallellt utvecklades mycket olika servrar. OpenLDAP uppstod 1998 ur University of Michigan-implementeringen och fortsatte slapd, bibliotek och verktyg som ett open-source-projekt. Active Directory tog med Windows 2000 LDAPv3-profilen med eget schema, Naming Contexts, Controls, Matching Rules och separat replikeringsprotokoll till bred företagsanvändning (OpenLDAP Release Road Map, OpenLDAP Administrator’s Guide – Preface, MS-ADTS).

Denna historia förklarar den viktigaste driftsregeln: LDAP förenhetligar åtkomsten, inte den interna arkitekturen. Den som flyttar en klient från OpenLDAP till AD DS eller mellan två appliances måste därför kontrollera mer än host, port och Bind-DN. Schema, Controls, gränser, gruppupplösning, replikering och recovery förblir produktegenskaper.

Källor

• RFC 4510, avsnitt 1 och 2
• RFC 4511 – LDAP: The Protocol – meddelandelager, operationer, BER, TCP, StartTLS och Result Codes.
• IANA – Service Name and Port Number Registry – ldap 389 och ldaps 636.
• MS-ADTS – Using SSL/TLS – implicit TLS och StartTLS i Active Directory.
• RFC 5805, avsnitt 1 och 3
• RFC 4512 – LDAP Directory Information Models – DIT, Entries, attribut, schema, Root DSE och subschema.
• RFC 4514, avsnitt 2 och 3
• RFC 2849, avsnitt 2 och 4
• RFC 4517 – LDAP Syntaxes and Matching Rules – standardsyntaxer och jämförelseregler.
• RFC 4520 – IANA Considerations for LDAP – registrering av OID:er och protokollparametrar.
• RFC 4513 – LDAP Authentication Methods and Security Mechanisms – bindningsmetoder, SASL, TLS och säkerhetsgränser.
• RFC 9525, avsnitt 2 och 4
• Microsoft – LDAP signing for AD DS – Signing, Channel Binding, standardvärden och händelser.
• MS-ADTS – Channel Binding – LDAP Channel Binding i Active Directory.
• Microsoft – LDAP session security after ADV190023 – säkerhetskrav per Bind- och TLS-modell.
• RFC 4515 – String Representation of Search Filters – filtergrammatik och Value Encoding.
• RFC 3673 – All Operational Attributes – + som attributväljare för operativa attribut.
• RFC 2696 – Simple Paged Results Control – sidor, cookies och konsistensgränser.
• MS-ADTS – LDAP Policies – administrativa sök- och resursgränser.
• Microsoft – Paging Search Results – Paged Search i Active Directory.
• Microsoft – RootDSE – Naming Contexts och serverfunktioner.
• MS-ADTS – rootDSE Attributes – AD-specifika Root-DSE-attribut.
• MS-ADTS – Ports – LDAP-, LDAPS- och Global-Catalog-portar.
• Microsoft – Searching the Global Catalog – sökning i hela skogen och partiell replik.
• Microsoft – Attributes included in the Global Catalog – Partial Attribute Set för Global Catalog.
• MS-ADTS – LDAP Matching Rules – AD-specifika Extensible-Match-OID:er.
• Microsoft – Primary group membership – avgränsning mellan memberOf och Primary Group.
• Microsoft – DC Locator – DNS-SRV-val, LDAP Ping och platsanknytning.
• Microsoft – Verify LDAP SRV records – SRV-registrering för Domain Controllers.
• MS-DRSR – Relationship to Other Protocols – avgränsning av AD-replikering från LDAP.
• RFC 4533 – LDAP Content Synchronization Operation – LDAP-Sync-Controls, cookies och tillståndsmodell.
• OpenLDAP Administrator’s Guide – Replication – syncrepl, cookies och Provider-/Consumer-modell.
• OpenLDAP Administrator’s Guide – Performance Tuning – indexering och interna sökkostnader i servern.
• Microsoft – Back up the System State data – System State-säkerhetskopiering för AD DS.
• OpenLDAP Administrator’s Guide – Directory Backups – LMDB-säkerhetskopia, slapcat och konsistensgränser.
• Microsoft Learn – Resolve-DnsName – DNS- och SRV-frågor i Windows.
• BIND 9 – dig manual – DNS- och SRV-frågor i Unix-system.
• Microsoft Learn – Test-NetConnection – TCP-anslutningsdiagnostik i Windows.
• Microsoft Learn – SslStream – TLS-handshake och certifikatkontroll med .NET.
• OpenSSL – s_client – TLS-handshake, namnkontroll och LDAP-StartTLS.
• Microsoft Learn – Get-ADRootDSE – Root-DSE-diagnostik i Windows.
• OpenLDAP – ldapsearch(1) – Search-, StartTLS-, SASL- och Control-alternativ.
• Microsoft Learn – Get-ADUser – LDAPFilter, SearchBase, scope och Paging.
• RFC 1487 – X.500 Lightweight Directory Access Protocol – första LDAP-specifikationen från 1993.
• RFC 1777 – Lightweight Directory Access Protocol – LDAPv2 och historisk protokollmodell.
• RFC 2251 – Lightweight Directory Access Protocol v3 – första LDAPv3-kärnspecifikationen.
• OpenLDAP – Release Road Map – Release 1.0 i augusti 1998.
• OpenLDAP Administrator’s Guide – Preface – University of Michigan-LDAP som grund för projektet.
• MS-ADTS – Active Directory Technical Specification – LDAP-serverprofil för AD DS och AD LDS.