LDAP: protokoll, datamodell og katalogdrift

LDAP er det felles språket som applikasjoner bruker for å få tilgang til katalogtjenester. En klient kan bruke det til å søke etter navngitte oppføringer, lese eller endre attributter og autentisere seg mot katalogen. Protokollen definerer meldinger, operasjoner og feilkoder. Hvordan en server lagrer dataene sine, replikerer dem eller beskytter dem mot feil, er derimot opp til den enkelte implementasjonen. Active Directory Domain Services, OpenLDAP og 389 Directory Server snakker derfor LDAP uten å være den samme plattformen internt (RFC 4510, avsnitt 1 og 2, RFC 4511, avsnitt 3).

Dette skillet er avgjørende i meldingsdrift. En gateway kan kontrollere om en mottaker finnes før SMTP-aksept, løse opp grupper for en policy eller logge på en administrator. Hvis dette oppslaget svikter eller returnerer utdaterte data, er det ikke bare «LDAP-feil»: Avhengig av integrasjonen blir meldinger avvist, regler brukt feil eller pålogginger blokkert. Administratoren må derfor vite hvor på veien fra DNS-navnet til det leste attributtet forbindelsen brytes.

Forklaringen følger denne veien. Først finner klienten en server og etablerer en beskyttet økt. Deretter autentiserer den seg, utfører et søk og tolker svarene. Først når denne normale flyten er klar, kan skjema, Active Directory-særegenheter, replikering, skalering og gjenoppretting settes i riktig sammenheng.

Protokollstakk og øktmodell

Før en applikasjon kan søke, trenger den et konkret tjenestemål. I Active Directory-miljøer leverer DNS-SRV-poster mulige Domain Controllers eller Global Catalogs; andre produkter bruker statiske FQDN-er, egen tjenesteoppdagelse eller en lastbalanserer. Dette valget bestemmer ikke bare IP-adressen, men også plassering, serverrolle og navnet sertifikatet kontrolleres mot. En porttest mot en vilkårlig tilgjengelig server besvarer derfor ikke om applikasjonen når det tiltenkte målet.

På det valgte målet oppretter LDAP en TCP-forbindelse. Port 389 starter som LDAP og kan bytte til en beskyttet økt med StartTLS Extended Operation. Port 636 er registrert hos IANA som ldaps og brukes blant annet av Active Directory for TLS som starter umiddelbart. I begge tilfeller må klienten kontrollere sertifikatkjeden og servernavnet; «kryptert» og «koblet til riktig server» er to forskjellige bevis (RFC 4511, avsnitt 4.14 og 5, IANA Service Name Registry, MS-ADTS, Using SSL/TLS).

Innenfor denne forbindelsen overfører LDAP ikke lesbare kommandolinjer som SMTP. Meldingene er beskrevet som ASN.1-strukturer og kodet med Basic Encoding Rules, BER. Hver LDAPMessage inneholder en messageID, nøyaktig én operasjon og eventuelt kontroller. Via meldings-ID-en kan en langvarig forbindelse skille mellom flere pågående operasjoner; svarene deres trenger ikke å ankomme i forespørselsrekkefølge. En vellykket TCP-handshake sier dermed ingenting om BER-dekoding, bind eller et fullført søk (RFC 4511, avsnitt 3.1, 4.1.1 og 5.1).

For endringer gjelder en viktig grense: En enkelt LDAP-operasjon er atomær innenfor sitt omfang, men flere oppføringer danner ingen felles kjernprotokolltransaksjon. RFC 5805 beskriver en eksperimentell transaksjonsutvidelse, hvis støtte klienten må oppdage på Root DSE. Selv da må det kontrolleres hvordan replikaer ser endringen. Klargjøringsprosesser trenger derfor egne regler for gjentakelse, delfeil og avstemming, i stedet for en stilltiende antatt databasetransaksjon (RFC 4511, avsnitt 3, RFC 5805, avsnitt 1 og 3).

Datamodell: DIT, oppføring, attributt og skjema

Etter at økten er opprettet, må klienten kunne angi hvor og hva den søker etter. LDAP organiserer katalogdataene som et Directory Information Tree, kort DIT. Hver oppføring har et unikt Distinguished Name og attributter. Skjemaet beskriver hvilke attributter som finnes, hvordan verdiene deres sammenlignes, og hvilke Object Classes de krever eller tillater. Uten denne modellen er søkebase, filter og resultater bare strenger uten pålitelig betydning (RFC 4512, avsnitt 2 og 3, RFC 4511, avsnitt 4.1.7).

Distinguished Name danner banen til en oppføring i treet. Ved cn=Mail Gateway,ou=Services,dc=example,dc=ch betegner cn=Mail Gateway den lokale Relative Distinguished Name; de påfølgende RDN-ene leder via beholderen til navneroten. Siden RDN-er kan være flerverdige og tegn som komma, pluss eller omvendt skråstrek escapes, må programvare ikke behandle en DN ved enkel splitting på komma. Den trenger en RFC-4514-kompatibel parser (RFC 4512, avsnitt 2.3, RFC 4514, avsnitt 2 og 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

For eksport og import finnes LDIF som en standardisert tekstrepresentasjon. LDIF representerer oppføringer eller endringsposter, men er ikke wireformatet for den aktive LDAP-økten. Linjebryting, Base64-verdier og Change Records følger egne regler. Fremfor alt inneholder en eksport bare det serveren og tillatelsene gjør synlig; operative attributter, ACL-er eller backendtilstand kan mangle. En LDIF-dump er derfor et datauttrekk, men ikke automatisk en gjenopprettbar serversikkerhetskopi (RFC 2849, avsnitt 2 og 4).

Betydningen av en attributtverdi kommer først fra skjemaet. En Matching Rule som caseIgnoreMatch, integerMatch eller en DN-sammenligning avgjør om to verdier er like, og hvilke filtre som fungerer på dem. På wire-nivå vises verdier først som Octet Strings; syntaks og attributttype gir dem tolkning. Egne skjemaelementer trenger derfor varig unike OID-er, definerte syntakser og Matching Rules, samt en utrulling som tar hensyn til servere og alle avhengige klienter samlet (RFC 4512, avsnitt 4, RFC 4517, RFC 4520).

Operasjoner og tilstandsendringer

Med transport, navn og skjema på plass står grunnstrukturen klar; nå begynner den egentlige protokolldialogen. Den første avgjørende tilstandsendringen er vanligvis Bind. Den fastsetter hvilken identitet og hvilke avledede rettigheter de påfølgende operasjonene kjører med. En ny bind erstatter denne tilstanden. Så lenge serveren behandler en bind, kan klienten ikke starte andre operasjoner på samme forbindelse (RFC 4511, avsnitt 3.1 og 4.2).

Etter vellykket bind kan klienten lese eller skrive. Et søk leverer ikke ett enkelt stort svar, men null eller flere SearchResultEntry-meldinger, eventuelt References og til slutt nøyaktig ett SearchResultDone. Først dette sluttresultatet viser om sekvensen var komplett. Modify, Add, Delete og ModifyDN endrer oppføringer; Compare kontrollerer en attributtverdi etter Matching Rule uten å returnere et ordinært søkeresultat (RFC 4511, avsnitt 4.5 til 4.9).

Også øktavslutningen har en klar semantikk. Unbind er en ensidig forespørsel om å lukke og har ikke noe svar. Abandon ber serveren om å avbryte en bestemt operasjon, men garanterer ikke dette avbruddet. Hvis TCP i stedet brytes, forsvinner alle pågående operasjoner. Ved en skriveoperasjon kan klienten da ikke vite sikkert om endringen trådte i kraft før eller etter forbindelsestapet; en retry krever derfor først en tilstandsavstemming i stedet for blind gjentakelse (RFC 4511, avsnitt 4.3 og 4.11).

Controls og Extended Operations supplerer denne flyten uten å innføre en ny LDAP-versjon. Hver Control har en OID, en Criticality og eventuelt en BER-kodet verdi. Hvis en klient markerer en ukjent eller ikke-eksekverbar Control som kritisk, må operasjonen feile med unavailableCriticalExtension; ellers kan serveren ignorere den. Før Paging, Sync eller en leverandørfunksjon leser en korrekt klient derfor blant annet supportedControl, supportedExtension, supportedFeatures, supportedLDAPVersion og supportedSASLMechanisms på Root DSE (RFC 4511, avsnitt 4.1.11, RFC 4512, avsnitt 5.1).

Bind, SASL og TLS-tillitsgrenser

Bind avgjør hvem serveren tilordner det neste søket til. Ved Simple Bind må tre tilfeller skilles: Tom DN og tomt passord gir anonym tilgang. En ikke-tom DN med tomt passord er en unauthenticated Bind og bekrefter uttrykkelig ikke den oppgitte identiteten, selv om serveren kan returnere success. Først en ikke-tom DN med ikke-tomt passord utgjør vanlig navn/passord-autentisering. Klienter bør derfor avvise tomme passord før forespørselen; servere bør ikke utilsiktet tillate unauthenticated Binds (RFC 4513, avsnitt 5.1.1 til 5.1.3 og 6.3.1).

Ved denne passordautentiseringen kjenner serveren den presenterte hemmeligheten. Transporten må derfor ikke bare være kryptert, men også autentisert. Dette omfatter en gyldig sertifikatkjede og kontroll av om det konfigurerte DNS-navnet finnes i sertifikatet. Den som aksepterer alle sertifikater eller bruker en IP-adresse, kan opprette en kryptert kanal til feil motpart. Den samme kontrollen gjelder for StartTLS og LDAP med umiddelbar TLS (RFC 4513, avsnitt 3.1 og 5.1.3, RFC 9525, avsnitt 2 og 4, TLS).

SASL tillater ulike autentiseringsmekanismer i stedet for en ren passord-bind og kan i tillegg forhandle fram beskyttelse for påfølgende LDAP-meldinger. I Active Directory finnes særlig Negotiate, Kerberos og NTLM. LDAP Signing beskytter der integriteten til bestemte SASL-økter; Channel Binding knytter autentiseringen til den underliggende TLS-forbindelsen. TLS, Signing og Channel Binding løser dermed beslektede, men ikke identiske problemer. En test må gjenspeile produktets faktiske bind-type (RFC 4513, avsnitt 5.2, Microsoft: LDAP signing, MS-ADTS, Channel Binding).

For å innføre strengere AD-policyer er det derfor ikke nok å se på Windows-versjonen. Nye AD DS-distribusjoner på Windows Server 2025 krever LDAP Signing som standard, mens oppgraderinger overtar eksisterende innstillinger. Microsoft oppgir Directory Service-hendelsene 2886 til 2889 for Signing og 3039 til 3041 for Channel Binding. Disse revisjonsdataene viser hvilke klienter, porter og bind-metoder som faktisk ville bli berørt; først deretter kan håndheving planlegges på et solid datagrunnlag (Microsoft: LDAP signing, Default Security Behavior og Event Monitoring, Microsoft: LDAP session security after ADV190023).

Search: base, scope, filter og attributtprojeksjon

Etter sikker bind følger operasjonen de fleste integrasjoner er avhengige av: Search. Forespørselen angir en Base DN, scope, aliashåndtering, egne size- og time-limits, et filter og ønskede attributter. baseObject leser bare baseoppføringen, singleLevel dens direkte barn og wholeSubtree hele undertreet inkludert basen. Serveren kan sette strengere grenser. Null treff med success er et gyldig svar; noSuchObject betyr derimot at søkebasen mangler eller ikke er synlig for denne identiteten (RFC 4511, avsnitt 4.5.1 og 4.5.2).

Filteret beskriver ikke fri SQL-logikk, men et tre i prefiksnotasjon. (&(objectClass=person)(mail=*@example.ch)) kombinerer for eksempel et Equality-uttrykk med et Substring-uttrykk. | står for OR, ! for NOT, =* for Presence og := for et Extensible Match. Om en sammenligning bruker store/små bokstaver, tallrekkefølge eller DN-semantikk, avgjøres av Matching Rule for det aktuelle attributtet (RFC 4511, avsnitt 4.5.1, RFC 4515, RFC 4517).

Dermed blir generering av filtre en sikkerhetsoppgave. Verdier fra brukerinndata må kodes etter RFC 4515; særlig *, parenteser, omvendt skråstrek, NUL og ugyldige UTF-8-oktetts må ikke komme rått inn i uttrykket. Strengkonkatenering kan ellers endre filterstrukturen og muliggjøre LDAP-injeksjon. DN-escaping etter RFC 4514 følger andre regler og erstatter ikke filterkoding (RFC 4515, avsnitt 3, RFC 4514, avsnitt 3).

Ved siden av filteret bestemmer attributtlisten hvor mye serveren returnerer. En tom liste ber om alle vanlige brukerattributter, 1.1 ingen attributter, * alle brukerattributter og + etter RFC 3673 alle operative attributter. ACL-er kan fortsatt skjule verdier. Produksjonsklienter bør bare be om nødvendige attributter: Store flerverdier belaster nettverk, dekoder og minne og kan utløse egne servergrenser (RFC 4511, avsnitt 4.5.1.8, RFC 3673).

Paging, sortering og resultater som endrer seg

Større treffmengder overføres vanligvis med Simple Paged Results Control. Serveren legger ved en ugjennomsiktig cookie for hver side, som klienten sender tilbake sammen med samme forespørsel. Denne cookien er ikke en offset eller en varig cursor. Hvis kataloginnholdet endrer seg underveis, kan oppføringer mangle eller forekomme dobbelt. Paging begrenser dermed datamengden per svar, men skaper ikke et konsistent snapshot (RFC 2696, avsnitt 2 og 3).

Active Directory synliggjør dette skillet i praksis: LDAP-policyen MaxPageSize begrenser upaginerte resultater som standard til 1000 objekter. En import som mottar nøyaktig 1000 oppføringer, har derfor ikke bevist at den er fullstendig. Klienten må behandle sider og cookies korrekt og oppdage avbrudd. Andre policyer begrenser spørrevarighet, Receive Buffer og samtidig holdte Result Sets. I drift må derfor Page Size, antall sider, siste cookie-fremdrift, timeout og gjenoppstart loggføres (MS-ADTS, LDAP Policies, Microsoft: Paging Search Results).

Active Directory som LDAP-serverprofil

Reglene hittil gjelder LDAP generelt. Active Directory Domain Services er en konkret serverimplementasjon med ekstra roller og konvensjoner. Dataene er fordelt på Naming Contexts; en Domain Controller har minst Schema, Configuration og sin egen Domain Naming Context. Root DSE har tom DN og oppgir blant annet defaultNamingContext, configurationNamingContext, schemaNamingContext, alle namingContexts, servernavnet og støttede mekanismer. Etter TCP og TLS er denne oppføringen den første testen som faktisk sier noe om den nådde katalogtjenesten (RFC 4512, avsnitt 5.1, Microsoft RootDSE, MS-ADTS, rootDSE Attributes).

Valget mellom Domain Controller og Global Catalog endrer søkeresultatet. En DC betjener LDAP på 389 eller 636 og kjenner full Domain Naming Context for sitt domene. Global Catalog bruker i tillegg 3268 eller 3269 og har en partiell replika fra alle domener i skogen. Den kan finne objekter på tvers av skogen, men for eksterne domener leverer den bare attributter fra Partial Attribute Set. Et vellykket treff beviser derfor ikke at attributtet applikasjonen trenger, finnes (MS-ADTS, Ports, Microsoft: Searching the Global Catalog, Microsoft: Attributes included in the Global Catalog).

Også filtre kan bli AD-spesifikke. Matching Rule 1.2.840.113556.1.4.1941, LDAP_MATCHING_RULE_TRANSITIVE_EVAL, følger for eksempel koblede attributter og kan evaluere nestede grupper. Støtten står ikke bare i supportedControl. Dessuten inneholder memberOf ikke Primary Group. En autorisasjonsbeslutning basert på gruppemedlemskap må derfor uttrykkelig ta hensyn til gruppenesting, Primary Group, gruppescope, ACL-synlighet og replikeringsstatus (MS-ADTS, LDAP Matching Rules, Microsoft: Primary group membership).

Hvilken server som besvarer disse forespørslene, avgjøres for Windows-klienter av DC Locator sammen med DNS-SRV-poster. Steds- og rollebaserte poster gir kandidater med prioritet og vekt. En statisk angitt IP omgår dette valget og vanskeliggjør sertifikatkontroll. En enkel TCP-lastbalanserer fordeler riktignok forbindelser, men kjenner uten ekstra logikk verken skrivbare DC-er eller Global Catalogs, Naming Contexts eller replikeringsstatus (Microsoft: DC Locator, Microsoft: Verify LDAP SRV records).

Til slutt må LDAP-tilgjengelighet ikke forveksles med sunn replikering. AD replikerer katalogendringer over Directory Replication Service Remote Protocol; OpenLDAPs syncrepl bruker derimot LDAP Content Synchronization med Provider, Consumer og cookies. Et testsøk kan vise at en bestemt server svarer. Om alle servere har de samme endringene og tar igjen etter en feil, må kontrolleres med verktøyene for den aktuelle plattformen (MS-DRSR, Relationship to Other Protocols, RFC 4533, OpenLDAP Administrator’s Guide: Replication).

Integrasjons- og driftsmodeller

For drift er det nå mindre viktig at et produkt «støtter LDAP», enn hvordan det bruker LDAP. Ved et oppslag i kjøretid venter en melding eller økt direkte på Search og serversvar. Ved Credential Check søker en teknisk konto først etter brukerens DN og utfører deretter en andre bind med det oppgitte passordet. En import eller cache leser derimot mange oppføringer og arbeider med en lokal kopi til neste kjøring. Disse mønstrene har ulike konsekvenser for latens, passordbehandling, failover og dataalder; produktdokumentasjonen må angi den konkrete atferden (RFC 4511, avsnitt 4.2 og 4.5, RFC 2696).

Uavhengig av mønsteret trenger klienten separate tidsavbrudd for Connect, Bind, Operation og Idle. En Connection Pool sparer oppsett av TCP, TLS og Bind, men bærer med seg forbindelsens autentiseringstilstand. Døde økter må oppdages, og en forbindelse må ikke utilsiktet skifte mellom brukere eller leietakere. Failover trenger en sporbar målrekkefølge, begrensede gjentakelser og en vei tilbake til foretrukket mål. Ellers mangedobler parallelle retries lasten nettopp under et katalogutfall (RFC 4511, avsnitt 3.1, 4.2 og 5.3).

På serversiden bestemmer Base DN, Scope, Filter og attributtliste arbeidet. En selektiv likhetsbetingelse på et indeksert attributt er noe annet enn en innledende substring eller et stort OR-uttrykk. LDAP publiserer ingen eksekveringsplan og foreskriver ingen indeksteknikk. Administratoren må derfor korrelere de faktiske produktfiltrene med resultatmengde, p95-/p99-latens og servermetrikker. Et raskt søk etter én testkonto beviser ikke at en mottakerkontroll skalerer under toppbelastning (OpenLDAP Administrator’s Guide: Performance Tuning, MS-ADTS: LDAP Policies).

Overvåking bør dele prosessen inn i de samme trinnene som feilsøkingen: DNS-valg, TCP- og TLS-oppsett, Bind, Search-latens, Result Code, treffantall og paging-fremdrift. I tillegg kommer poolbelegg, retryrate og status for import eller synkronisering. En enkelt syntetisk bind kan bekrefte tilgjengelighet, men oppdager verken manglende attributter, en ufullstendig import eller en replikeringspartner som ligger etter.

For backup og recovery er heller ikke det synlige kataloginnholdet tilstrekkelig. Skjema, ACL-er, backend- og serverkonfigurasjon, nøkler og sertifikater, replikeringsidentiteter samt prosedyren for å ta en gjenopprettet node inn i topologien igjen må sikres. Active Directory bruker System State og egne Forest Recovery-trinn til dette; OpenLDAP avhenger av sin backend. Håndboken skiller for eksempel mellom en LMDB-sikkerhetskopi og slapcat og påpeker semantisk inkonsistente LDIF-tilstander ved endringer i flere deler. LDAP definerer ingen backupmekanisme (Microsoft: Back up the System State data, OpenLDAP Administrator’s Guide: Directory Backups).

En gjenopprettingstest er først fullført når en klient finner den gjenopprettede tjenesten via det tiltenkte DNS-navnet, TLS og Bind lykkes, Root DSE og skjemaet stemmer, reelle søk leverer fullstendige attributter og replikeringen starter kontrollert igjen. Dermed fører recovery tilbake til artikkelens begynnelse: Hele banen teller, ikke bare en startet database.

Diagnoseverktøy

Diagnosen følger samme bane som en produksjonsforespørsel. Den starter i nettverket til den berørte applikasjonen og bruker dens DNS-navn, Truststore, bind-metode, Base DN, filter og attributtliste. En test fra administratorens bærbare PC kan ellers lykkes mens gatewayen fortsatt bruker en annen DC, en annen CA eller et annet scope. Eksemplene bruker reserverte navn og leser bare metadata; bind-passord hører verken hjemme i shellhistorikken eller i prosessargumenter. ldapsearch -W ber om dem interaktivt.

Finn tjenestemål via DNS

Resolve-DnsName _ldap._tcp.dc._msdcs.example.ch -Type SRV -DnsOnly
Resolve-DnsName _ldap._tcp.gc._msdcs.example.ch -Type SRV -DnsOnly

dig +noall +answer SRV _ldap._tcp.dc._msdcs.example.ch
dig +noall +answer SRV _ldap._tcp.gc._msdcs.example.ch

Resolve-DnsName og dig viser mål, porter, prioriteter og vekter. Deretter må A-/AAAA-oppløsning, stedstilknytning og tilgjengelighet for hvert faktisk valgbare mål kontrolleres. Én tilgjengelig DC retter ikke et feilaktig SRV-sett (Microsoft: DC Locator).

Kontroller TCP og implisitt TLS på port 636

Test-NetConnection dc1.example.ch -Port 636 -InformationLevel Detailed
$tcp = [Net.Sockets.TcpClient]::new(“dc1.example.ch”, 636)
$tls = [Net.Security.SslStream]::new($tcp.GetStream(), $false)
$tls.AuthenticateAsClient(“dc1.example.ch”)
$tls.SslProtocol
$tls.RemoteCertificate.Subject
$tls.RemoteCertificate.GetExpirationDateString()
$tls.Dispose(); $tcp.Dispose()

openssl s_client \
  -connect dc1.example.ch:636 \
  -servername dc1.example.ch \
  -verify_hostname dc1.example.ch \
  -verify_return_error -brief

Test-NetConnection beviser først bare TCP-tilkoblingen. Den påfølgende .NET SslStream eller openssl s_client kontrollerer TLS med det konfigurerte DNS-navnet. s_client -showcerts viser bare sertifikatene serveren sender og er i seg selv ikke bevis på en vellykket Chain- eller Hostname-kontroll. StartTLS på 389 kan kontrolleres separat under Unix med openssl s_client -starttls ldap (OpenSSL s_client, RFC 4511, avsnitt 4.14).

Les Root DSE og funksjoner

Get-ADRootDSE -Server dc1.example.ch -Properties @(
  "defaultNamingContext"
  "namingContexts"
  "supportedLDAPVersion"
  "supportedControl"
  "supportedSASLMechanisms"
)

ldapsearch -LLL -x -ZZ -H ldap://dc1.example.ch \
  -s base -b "" \
  defaultNamingContext namingContexts supportedLDAPVersion \
  supportedControl supportedSASLMechanisms

Get-ADRootDSE bruker her ActiveDirectory-modulen og som standard den påloggede Windows-identiteten. ldapsearch tvinger med -ZZ frem vellykket StartTLS og leser anonymt bare Root DSE-attributtene serveren har frigitt. En manglende OID beviser at akkurat dette målet ikke publiserer funksjonen; den sier ingenting om andre clusternoder.

Gjenskap reelt søk med scope, filter og paging

$params = @{
  Server         = "dc1.example.ch"
  SearchBase     = "OU=People,DC=example,DC=ch"
  SearchScope    = "Subtree"
  LDAPFilter     = "(&(objectClass=user)(mail=admin@example.ch))"
  Properties     = @("mail", "proxyAddresses", "memberOf")
  ResultPageSize = 500
}
Get-ADUser @params

ldapsearch -LLL -x -ZZ -H ldap://dc1.example.ch \
  -D "CN=svc-lookup,OU=Services,DC=example,DC=ch" -W \
  -b "OU=People,DC=example,DC=ch" -s sub \
  -E pr=500/noprompt \
  "(&(objectClass=user)(mail=admin@example.ch))" \
  mail proxyAddresses memberOf

Get-ADUser godtar med -LDAPFilter den RFC-nære filtersyntaksen og utfører paging via -ResultPageSize . ldapsearch bruker -E pr=500/noprompt for Paged Results Control og -W for interaktiv passordspørring. Testen må, i tillegg til treffet, dokumentere avsluttende resultat, antall sider, returnerte attributter og kjøretid.

Tilordne feil til en grense

Numeriske Result Codes hører til LDAP-protokollen; diagnosticMessage og ekstra AD-subkoder er derimot implementasjonsspesifikk kontekst. Automatisering bør derfor først evaluere Result Code og loggføre teksten som tillegg. For busy og unavailable trenger hver klient et begrenset retrybudsjett med backoff. Ubegrensede gjentakelser gjør ett enkelt katalogproblem til en lasttopp i alle avhengige systemer (RFC 4511, avsnitt 4.1.9 og vedlegg A).

Teknisk historie

LDAP oppsto ikke som en uavhengig katalogdatabase. X.500 hadde på slutten av 1980-årene definert en omfattende katalogmodell og Directory Access Protocol. RFC 1487 beskrev i 1993 en lettere tilgang til denne modellen; RFC 1777 fulgte i 1995 som LDAP Version 2. «Lightweight» viste til den forenklede protokolltilgangen sammenlignet med DAP, ikke til små kataloger eller liten driftsmessig betydning. Den tidlige utviklingen er tett knyttet til Tim Howes og University of Michigan (RFC 1487, RFC 1777).

LDAPv3 ble publisert i 1997 med RFC 2251 og ledsagende dokumenter. Utvidbare operasjoner, Controls, SASL, internasjonalisering og den reviderte datamodellen gjorde det til grunnlaget for dagens implementasjoner. LDAPbis-arbeidet omorganiserte denne statusen i 2006: RFC 4510 fungerer som roadmap, RFC 4511 beskriver protokollen, RFC 4512 informasjonsmodellen og RFC 4513 sikkerheten; RFC 4514 til 4519 utfyller representasjoner, URL-er, syntakser og skjema (RFC 2251, RFC 4510, avsnitt 3).

Parallelt utviklet det seg svært ulike servere. OpenLDAP oppsto i 1998 fra University of Michigan-implementasjonen og videreførte slapd, biblioteker og verktøy som et åpen kildekode-prosjekt. Active Directory brakte med Windows 2000 en LDAPv3-profil med eget skjema, Naming Contexts, Controls, Matching Rules og separat replikeringsprotokoll inn i bred virksomhetsbruk (OpenLDAP Release Road Map, OpenLDAP Administrator’s Guide – Preface, MS-ADTS).

Denne historien forklarer den viktigste driftsregelen: LDAP standardiserer tilgangen, ikke den interne arkitekturen. Den som flytter en klient fra OpenLDAP til AD DS eller mellom to appliances, må derfor kontrollere mer enn host, port og Bind-DN. Skjema, Controls, grenser, gruppeoppløsning, replikering og recovery forblir produktegenskaper.

Kilder

• RFC 4510, avsnitt 1 og 2
• RFC 4511 – LDAP: The Protocol – meldingslag, operasjoner, BER, TCP, StartTLS og Result Codes.
• IANA – Service Name and Port Number Registry – ldap 389 og ldaps 636.
• MS-ADTS – Using SSL/TLS – implisitt TLS og StartTLS i Active Directory.
• RFC 5805, avsnitt 1 og 3
• RFC 4512 – LDAP Directory Information Models – DIT, Entries, attributter, skjema, Root DSE og Subschema.
• RFC 4514, avsnitt 2 og 3
• RFC 2849, avsnitt 2 og 4
• RFC 4517 – LDAP Syntaxes and Matching Rules – standardsyntakser og sammenligningsregler.
• RFC 4520 – IANA Considerations for LDAP – registrering av OID-er og protokollparametere.
• RFC 4513 – LDAP Authentication Methods and Security Mechanisms – bind-metoder, SASL, TLS og sikkerhetsgrenser.
• RFC 9525, avsnitt 2 og 4
• Microsoft – LDAP signing for AD DS – Signing, Channel Binding, standarder og hendelser.
• MS-ADTS – Channel Binding – LDAP Channel Binding i Active Directory.
• Microsoft – LDAP session security after ADV190023 – sikkerhetskrav per bind- og TLS-modell.
• RFC 4515 – String Representation of Search Filters – filtergrammatikk og verdikoding.
• RFC 3673 – All Operational Attributes – + som attributtvelger for operative attributter.
• RFC 2696 – Simple Paged Results Control – sider, cookies og konsistensgrenser.
• MS-ADTS – LDAP Policies – administrative søke- og ressursgrenser.
• Microsoft – Paging Search Results – Paged Search i Active Directory.
• Microsoft – RootDSE – Naming Contexts og serverfunksjoner.
• MS-ADTS – rootDSE Attributes – AD-spesifikke Root DSE-attributter.
• MS-ADTS – Ports – LDAP-, LDAPS- og Global Catalog-porter.
• Microsoft – Searching the Global Catalog – søk på tvers av skogen og partiell replika.
• Microsoft – Attributes included in the Global Catalog – Partial Attribute Set i Global Catalog.
• MS-ADTS – LDAP Matching Rules – AD-spesifikke Extensible-Match-OID-er.
• Microsoft – Primary group membership – avgrensning mellom memberOf og Primary Group.
• Microsoft – DC Locator – DNS-SRV-valg, LDAP Ping og stedstilknytning.
• Microsoft – Verify LDAP SRV records – SRV-registrering for Domain Controllers.
• MS-DRSR – Relationship to Other Protocols – avgrensning av AD-replikering fra LDAP.
• RFC 4533 – LDAP Content Synchronization Operation – LDAP Sync-Controls, cookies og tilstandsmodell.
• OpenLDAP Administrator’s Guide – Replication – syncrepl, cookies og Provider-/Consumer-modell.
• OpenLDAP Administrator’s Guide – Performance Tuning – indeksering og serverinterne søkekostnader.
• Microsoft – Back up the System State data – System State-sikkerhetskopiering for AD DS.
• OpenLDAP Administrator’s Guide – Directory Backups – LMDB-sikkerhetskopi, slapcat og konsistensgrenser.
• Microsoft Learn – Resolve-DnsName – DNS- og SRV-forespørsler i Windows.
• BIND 9 – dig manual – DNS- og SRV-forespørsler i Unix-systemer.
• Microsoft Learn – Test-NetConnection – TCP-tilkoblingsdiagnostikk i Windows.
• Microsoft Learn – SslStream – TLS-handshake og sertifikatkontroll med .NET.
• OpenSSL – s_client – TLS-handshake, navnekontroll og LDAP-StartTLS.
• Microsoft Learn – Get-ADRootDSE – Root DSE-diagnostikk i Windows.
• OpenLDAP – ldapsearch(1) – Search-, StartTLS-, SASL- og Control-alternativer.
• Microsoft Learn – Get-ADUser – LDAPFilter, SearchBase, Scope og Paging.
• RFC 1487 – X.500 Lightweight Directory Access Protocol – første LDAP-spesifikasjon fra 1993.
• RFC 1777 – Lightweight Directory Access Protocol – LDAPv2 og historisk protokollmodell.
• RFC 2251 – Lightweight Directory Access Protocol v3 – første LDAPv3-kjernespesifikasjon.
• OpenLDAP – Release Road Map – Release 1.0 i august 1998.
• OpenLDAP Administrator’s Guide – Preface – University of Michigan LDAP som grunnlag for prosjektet.
• MS-ADTS – Active Directory Technical Specification – LDAP-serverprofil for AD DS og AD LDS.