SQUID-autentisering (Kerberos og LDAP) basert på Active Directory-domenegrupper. LDAP-protokoll

Legg igjen en kommentar 6,950

LDAP Lightweight Directory Access Protocol (Lightweight Directory Access Protocol) er en nettverksprotokoll for tilgang til X.500-katalogtjenesten utviklet av IETF som en lettvektsversjon av DAP-protokollen utviklet av ITU-T.

Katalog- en spesiell type database som inneholder informasjon i en trestruktur.

LDAP er en relativt enkel protokoll som bruker TCP/IP og tillater autorisasjon (bind), søk og sammenligne operasjoner, samt operasjoner for å legge til, endre eller slette oppføringer. Vanligvis aksepterer LDAP-serveren innkommende tilkoblinger på port 389 ved bruk av TCP- eller UDP-porter. For LDAP-sesjoner innkapslet i SSL-sertifikater for nettsted, e-post, brukes vanligvis port 636. LDAP-katalogtjenesten er basert på en klient/server-modell. En eller flere LDAP-servere inneholder data som lager et kataloginformasjonstre (DIT). Klienten kobler seg til serveren og ber om det. Serveren gir klienten et svar og/eller en indikasjon på hvor den kan få mer informasjon (vanligvis en annen LDAP-server).

LDAP-implementeringer

LDAP er en mye brukt standard for tilgang til katalogtjenester. Av de gratis open source-implementeringene er den mest kjente OpenLDAP-serveren, av de proprietære - protokollstøtten er tilgjengelig i Active Directory - en katalogtjeneste fra Microsoft, designet for å sentralisere Windows-nettverksadministrasjon, konfigurasjon, akselerasjon og ofte stilte spørsmål . Andre katalogtjenesteimplementeringer som støtter LDAP som tilgangsprotokoll: Red Hat Directory Server, Mandriva Directory Server, Novell eDirectory, OpenDS.

Hvordan kan du få informasjon? En post refereres til med dets unike navn, som består av det faktiske navnet på posten (det såkalte Relative Distinguished Name (RDN), vedlagt stamfarpostnavnene. For eksempel posten som beskriver Barbara Jensen i internetteksemplet ovenfor ) navngivning, har RDN uid = babs, og DN - uid = babs, ou = People, dc = eksempel, dc = com.

Hva er slapd og hva kan det gjøre? slapd(Frittstående LDAP-daemon) er en LDAP-katalogserver. Du kan bruke den til å gi din egen katalogserver. Katalogen din kan inneholde all informasjon du ønsker. Du kan også koble katalogen til den globale LDAP-katalogtjenesten eller starte katalogtjenesten selv. Noen slapd funksjoner: avsnitt 1.9. slik som SASL, TLS (eller SSL), støtter Unicode og språkkoder.

Hva er slurpd og hva kan det gjøre? slurpd(8) er en demon som bruker slapd (8) for å kjøre replikeringstjenesten. Den er ansvarlig for å spre endringer som er gjort i master-slapd-databasen til andre slapd-databaser. Slurpd frigjør slapd fra å måtte bekymre seg hvis andre slapd-databaser er nede eller utilgjengelige når det gjøres endringer i masterdatabasen. Slurpd prøver automatisk oppdateringsforespørsler på nytt. Slapd og Slurpd er koblet gjennom en enkel tekstfil som brukes til å registrere endringer.

LDAP, og spesielt OpenLDAP, har en rekke sikkerhetsfunksjoner som kan virke litt skremmende ved første (og andre og tredje) øyekast. Figur 15-1 viser det store bildet av problemet før du går i detalj. De følgende delene viser de ulike metodene for tilgang til og grensesnitt til et LDAP-system, og beskriver deretter sikkerhetsproblemene og risikohåndteringsteknikkene som er tilgjengelige. Målet med denne øvelsen er enten å definere et sett med sikkerhetspolicyer eller å prioritere implementering.

Figur 15-1. Det store bildet av sikkerhetsproblemer

Alle tall i beskrivelsen nedenfor refererer til figur 15-1.

Interaksjon med eksterne abonnenter (1):Å sikre sikkerhet når du samhandler med eksterne abonnenter kan være et problematisk problem eller ikke. Når du gir ubegrenset (anonym) tilgang til ikke-konfidensiell LDAP-informasjon, tas det ikke opp sikkerhetsproblemer. Merk følgende: under disse forholdene blir serveren din fortsatt et potensielt mål for DoS/DDoS-angrep ved å laste den med ondsinnede LDAP-forespørsler. Dermed kan selv denne tilsynelatende trivielle implementeringen kreve nøye utforming.

Hvis all interaksjon med LDAP er garantert å finne sted på et pålitelig nettverk, kan du velge å jobbe med enkle passord i klartekst uten ekstra sikkerhetsproblemer. Men selv i slike tilfeller, avhengig av topologien til det pålitelige nettverket, er det ganske enkelt å avskjære trafikk og motta enten konfidensielle data (1-2) eller passord (1-1) sendt i klartekst.

Når interaksjon med LDAP utføres gjennom upålitelige nettverk, har destruktive individer på nettverket umiddelbart noe å gjøre: være forberedt på avlytting, sporing, man-in-the-middle-angrep osv. NS. vil være en konstant hendelse. Husk også at bruk av online OLC-konfigurasjon (cn = config) og overvåkingsfunksjoner (cn = monitor) kan føre til at LDAP-nettlesere blir et vanlig verktøy for ekstern administrasjon og administrasjon av LDAP-servere. Og denne trafikken er i sin natur utrolig konfidensiell.

Hvis det blir bestemt at et visst sikkerhetsnivå fortsatt er nødvendig, så er det første spørsmålet som oppstår i dette tilfellet: trenger vi kun å beskytte passord (1-1), eller må vi beskytte begge dataene (1-2) og passord (1-1 )? Avhengig av svaret på dette spørsmålet, vil våre neste trinn bli bestemt.

Passord (1-1): Ikke forveksle beskyttelsespassord under overføring over nettverket med beskyttelse av dem i konfigurasjonsfiler eller i DIT-er. Selv om du har beskyttet alle passord i konfigurasjonsfilene eller i DIT ved hjelp av hashing-metoder som (SSHA), når klienten sender passordet til serveren for autentisering, sendes det i klartekst, hashes på serveren, og sammenlignes med den lagrede verdien. Uten å iverksette ytterligere tiltak, kan det dermed bli fanget opp (eller sporet, avhengig av din preferanse for slike vilkår). Merk: Når en klient ber om en post som inneholder for eksempel attributtet bruker passord, hvis verdi er hashed, for eksempel i henhold til (CRYPT)-algoritmen, så sendes dette passordet ikke i klartekst, men i sin hashed-form (det vil si i den der det er lagret). Men når tilgang utføres på vegne av den samme posten, sender klienten passordet (som det autentiseres med) i klartekst, og naturligvis, hvis autentiseringen er vellykket, kan avskjæreren med rimelighet anta at passordet som ble sendt i klartekst var riktig ...

Når man sender hash-passord i en datastrøm som kan avskjæres, blir de sårbare for ordbokangrep – etter å ha mottatt et hash-passord, kjører angriperen listen over passord (den såkalte ordboken) gjennom hashing-algoritmen til den finner et samsvar. Bruk salt(en eller flere byte - avhengig av implementeringen - lagt til passordet før hashing og forkastet før sammenligning) forbedrer sikkerheten til hash-passord betraktelig, og med mindre du har en tvingende grunn til å ikke gjøre det, bør du alltid bruke formen til en hashalgoritme med salt... Man bør også bruke ACLå gi tilgang til passord kun til en viss krets av autoriserte brukere. For eksempel, forutsatt at passord er lagret i attributtet bruker passord, vil følgende ACL bare tillate tilgang til dette attributtet for eieren av oppføringen og for en spesifikk brukergruppe (admin):

# OLC-skjema (cn = config) olcAccess: til attrs = brukerpassord selv skriv av anonym auth av group.exact = "cn = admin, ou = grupper, dc = eksempel, dc = com" skriv av * ingen # Formater slapd. conf tilgang til attrs = brukerpassord selv skriv av anonym auth av group.exact = "cn = admin, ou = grupper, dc = eksempel, dc = com" skriv av * ingen

Hvis du bare trenger å beskytte passord, kan løsningen være å bruke SASL med en eller annen algoritme (for eksempel CRAM-MD5), som sikrer en sikker tilkoblingsdialog (ved hjelp av en delt hemmelig sekvens), der passord aldri blir overført i klartekst ( ). Et alternativ vil være å bruke TLS / SSL (med eller uten SASL) eller Kerberos 5. I dette tilfellet kan enkle passordmekanismer brukes, siden all kommunikasjon over nettverket er kryptert og derfor ikke kan avskjæres.

Så langt har vi bare diskutert enkle problemer med datatilgang. Hva med å endre eller modifisere disse dataene? OpenLDAP gir to alternativer for revisjon: overlegg revisjonslogg(se man-siden for slapo-auditlog for mer informasjon) og tilgangsloggoverlegget. Begge har funksjonalitet for å logge endringer som er gjort i den fungerende DIT, og accesslog har til og med muligheten til å logge informasjon om tilkoblinger, lese-/søketilganger og tidligere innhold i oppføringer eller attributter.

Lokal tilgang (2): Lokal tilgang betyr alle hendelser som oppstår direkte på LDAP-serveren eller serverklyngen (eller gjennom sikker ekstern tilgang til serveren ved hjelp av for eksempel ssh). Mest åpenbart faller manipulasjoner med konfigurasjonsfiler / kataloger (2-1) og lokalt utførte kommandoer (2-2) inn i denne kategorien.

Konfigurasjonsfiler (2-1): Det er to komponenter å vurdere her:

Eiere og rettigheter: Som standard kjører moderne LDAP-systemer under bruker-/gruppekontoer med begrensede rettigheter (vanligvis ldap: ldap). OpenLDAP starter opp som root (for å åpne privilegerte porter) og går deretter veldig raskt i gang med sine normale (lave) arbeidsrettigheter. Når du bruker OLC (cn = config), krever OpenLDAP at innholdet i konfigurasjonskatalogen har minst 0750 privilegier for kontoen den vil fungere under (vanligvis ldap: ldap), men den angir ikke de tilsvarende privilegiene alene. Denne oppførselen skiller seg fra å jobbe med konfigurasjonsfilen slapd.conf, som automatisk tildeles tillatelser 0600.

Passord: Passord som finnes i slapd.d-katalogene (når du bruker OLC (cn = config)) og i konfigurasjonsfilen (slapd.conf), slik som olcRootPw / rootpw, er klassifisert som spesielt sensitive. Det er best å fjerne både olcRootDn / rootdn og olcRootPw / rootpw fullstendig etter at DIT er oppe og går. Og selvfølgelig bør alle passord lagres i hash-form for å forhindre utilsiktet kompromittering (dette bør fastsettes på sikkerhetspolicynivå).

Lag (2-2): Historisk sett ble LDAP administrert gjennom et lokalt grensesnitt, for det meste fra kommandolinjen. Det ble antatt at lokal (intra-server) trafikk ikke er gjenstand for sporing, og derfor ble til og med bruk av vanlige passord i klartekst ansett som et tilstrekkelig beskyttelsesmål for de fleste administrative tjenester. Imidlertid, som nevnt ovenfor, kan økningen i kjøretidskonfigurasjon (OLC, cn = config) og overvåking (cn = monitor) katalogimplementeringer bety at eksterne LDAP-nettlesere blir normen når det kommer til å administrere LDAP-systemer. I dette tilfellet genererer tilgang til disse tjenestene overføring av svært viktig informasjon over nettverket, som må beskyttes ved hjelp av spesielle datasikkerhetsteknologier, for eksempel TLS / SSL.

Til slutt, siden kjøretidskonfigurasjon lagrer alle innstillinger i DIT (cn = config), er det verdt å vurdere å bruke den kraftige overleggstilgangsloggen, et logggenereringsverktøy for å revidere endringer som er gjort i en gitt DIT.

DIT (3): DIT-sikkerhet er definert av LDAP-sikkerhetsmodellen og håndheves utelukkende med olcAccess / tilgang til rettigheter bør begrenses så strengt som mulig, og ACL-er bør testes med slapacl etter hver endring.

Replikering (1-3): Selv om normal klienttilgang til LDAP-systemet ikke krever alvorlige sikkerhetstiltak, kan situasjonen være annerledes ved replikering av samme DIT. I løpet av replikeringssyklusen, på et tidspunkt, vil alle data i DIT (bruker- og driftsattributter) overføres over nettverket. Noe av denne informasjonen er sannsynligvis svært viktig. Replikeringsnettverk fortjener en separat vurdering. Du kan konfigurere en blandet TLS / SSL og annen sikker (eller til og med usikker) type tilkobling til samme server (se eksempler på konfigurasjon av TLS / SSL og SASL blandet tilgang).

Konfigurere SASL i OpenLDAP

Vi avslutter denne delen veldig snart (en dag virkelig snart nå ™)

Konfigurere SASL TLS / SSL i OpenLDAP

OpenLDAP Administrator's Guide sier at når du bruker TLS med EKSTERN SASL, må både klienten og serveren ha et gyldig X.509-sertifikat. Hvis dette er sant, får vi en unødvendig kompleks konfigurasjon, og sikkerhetsnivået øker litt, og derfor virker bruken i de fleste tilfeller tvilsom (men det er bemerkelsesverdige unntak, som replikering). Vi vil ikke diskutere dette i detalj på nåværende tidspunkt.

Konfigurere TLS / SSL i OpenLDAP

Oversikt

TLS (Transport Level Security) er ganske enkelt navnet på den IETF standardiserte versjonen av Secure Sockets Layer (SSL) fra Netscape. Det er praktisk talt ingen forskjell mellom SSL (v3) og TLS (v1), og disse begrepene anses som synonyme i denne dokumentasjonen. TLS / SSL støttes av OpenLDAP siden versjon 2.1.

Vanligvis krever TLS / SSL et X.509-sertifikat (mer kjent som et SSL-sertifikat), som kan kjøpes fra en kommersiell CA eller Certificate Authority (CA), eller det kan være et selvsignert sertifikat. Denne dokumentasjonen gir en trinnvis veiledning for å lage selvsignerte sertifikater og gir ytterligere merknader om bruk av kommersielle sertifikater etter behov.

Merknader:

cn = konfigurasjon: blir snart.

Forventer tilkoblinger bare for LDAPS URL: argument -h når du starter slapd. Som standard er denne verdien ikke spesifisert, som (vanligvis) tilsvarer -h ldap: ///. På grunn av kravene til denne konfigurasjonen må vi bare tillate ldaps-operasjoner, så når du starter slapd, må kommandoen brukes:

Slapd -h ldaps: /// -u ldap -g ldap

slapd_flags = "ldaps: ///".

Hvis du er bekymret for brannmurkonfigurasjonen, kan LDAPS konfigureres til å bruke port 389 (LDAPS er et URL-skjema som forteller at TLS skal brukes, ikke hvilken port som skal brukes). I dette tilfellet vil startkommandoen være slik:

Slapd -h ldaps: //: 389 / -u ldap -g ldap # ved tilkobling av ldaps URL-er skal ha formen: ldaps: //ldap.server.name: 389

Forby, kreve og sikkerhetsdirektiver:Å vente på tilkoblinger kun på LDAPS-porten(e) tvinger TLS / SSL på alle tilkoblinger. Ingen andre typer tilkoblinger vil bli akseptert i denne serverkonfigurasjonen. For å tvinge brukere til å bestå LDAP-autentisering, bruk direktivet krever binding, og for å hindre anonyme tilkoblinger, brukes direktivet disallow bind_anon... Derfor, for å få tilgang til DIT, må enhver tilkobling være bind, og tilkoblingen kan ikke være anonym. Hvis du bare spesifiserer direktivet sikkerhet simple_bind = 128, vil dette ikke føre til det nødvendige beskyttelsesnivået. Dette direktivet sier ganske enkelt: hvis enkel binding utføres, bør TLS / SSL brukes. Det krever ikke at tilkoblingen er nødvendig. Det eneste formålet med bruken sikkerhet simple_bind = 128 i denne konfigurasjonen, definer minimum SSF-verdi. Hvis det ikke er nødvendig, kan dette direktivet utelates.
Tilgang til rootDSE: En bieffekt av denne policyen er forbudet mot anonym tilgang til rootDSE, som, som allerede nevnt, kan være ganske rettferdiggjort for sikre servere.
ACL-direktiver: Denne konfigurasjonen gir ikke ytterligere sikkerhetstiltak basert på bruk av ACL-er - serversikkerhet er fullt ut sikret av globale konfigurasjonsdirektiver og begrenser tilkoblinger kun på LDAPS-porter. ACL kan brukes til å etablere nødvendig tilgangskontroll basert på brukerlegitimasjon.

Kundetilpasning: Fra kravet om at LDAP-serveren kun skal betjene TLS-tilkoblinger, må alle klienter bruke en LDAPS-URL og verifisere serverens X.509-sertifikat ved tilkobling, noe som krever tilgang til CA (root)-sertifikatet. Klienter i vår kontekst refererer til ldap-verktøyene og -verktøyene, så vel som LDAP-serverne som kjører syncrepl-replikeringstjenesten. Siden ldap-verktøyene og -verktøyene er klienter, får de selvsagt innstillingene fra ldap.conf-filen. Det er kanskje mindre åpenbart at LDAP-serverne som kjører replikeringstjenesten også er TLS-klienter, og derfor også henter CA (root) sertifikatinformasjon fra ldap.conf. Ldap.conf-konfigurasjon:

# kopier sertifikatet generert i trinn 1 # til et passende sted på klientsystemet # antar: /certs/ldapscert.pem # legg til ldap.conf TLS_CACERT /certs/ldapscert.pem

Konfigurasjon av LDAP-serveren som kjører replikaen:

# slapd.conf # global seksjon ... # Sikkerhet - TLS-seksjon # ingen innstillinger # replikert DIT-database bdb-suffiks "d = eksempel, dc = com" ... # replikering forbrukerinnstillinger syncrepl rid = 000 type = RefreshandPersist provider = ldaps : //ldap-master.example.com bindmethod = enkel søkebase = "dc = eksempel, dc = com" prøv på nytt = "5 3 300 +" attrs = "*, +" binddn = "...." legitimasjon = . ... ...

Merknader:

CA (root) sertifikat brukt i eksemplet av forbrukeren syncrepl(og definert av TLS_CACERT-direktivet i ldap.conf) er det samme som brukes som serversertifikatet av DIT-hovedleverandøren. Dette er en konsekvens av å bruke metoden med et enkelt sertifikat som vi brukte til å generere dette sertifikatet: det fungerer umiddelbart både som et serversertifikat og som et CA-sertifikat. Med andre metoder for å generere selvsignerte sertifikater kan serversertifikatet og CA-sertifikatet være forskjellige, og selvfølgelig er de alltid forskjellige ved bruk av kommersielle sertifikater.

Hvis, som diskutert ovenfor, ldaps-tjenesten serveres på port 389 (for eksempel for å feilsøke problemer med blokkering av brannmurtrafikk), vil syncrepl-definisjonen bruke det utvidede URL-formatet med porten:
Syncrepl ... leverandør = ldaps: //ldap-master.example.com: 389 ...

LDAP-servere som TLS-klienter: Når LDAP-serveren fungerer som en syncrepl-replikeringsforbruker, fungerer den som en TLS-klient og må derfor autentisere serversertifikatet med CA (rot)-sertifikatet som den signerte. Siden denne serveren fungerer som en TLS-klient, vil den bruke TLS-direktivene (og dermed TLS-sertifikatfilene) definert for LDAP-klienter - spesielt vil den bruke TLS_CACERT-direktivet i ldap.conf. TLS-klienten må generere en nøkkelutvekslingsmelding kryptert med offentlig nøkkel server, som trekkes ut fra X.509-sertifikatet sendt av serveren. Også TLS-klienten når den første etableringen av en TLS-tilkobling på stadiet KlientHei sender en liste over tillatte chifferserier, som kontrolleres av TLS-klientkonfigurasjonsdirektivet TLS_CIPHER_SUITE (som standard sendes alle mulige chifferserier (ALL), som tilsvarer kommandoen openssl chiffer -v ALLE). Ta et dypt pust før du leser neste setning. Hvis en LDAP-server som er en syncrepl-replikeringsforbruker og derfor en TLS-klient også gir tilgang til en annen DIT (for eksempel cn = config) og antar at TLS-støtte også kreves for å kontrollere denne tilgangen, så samtidig vil være en TLS-server og krever alle TLS-serverdirektivene definert i trinn 2 og 3 ovenfor.

Konfigurere TLS / SSL Mixed Access i OpenLDAP

Hvis du umiddelbart hoppet til denne seksjonen og omgå beskrivelsen av den normale TLS-konfigurasjonen, vennligst ta deg tid til å gjøre deg kjent med i det minste, og helst med hele seksjonen, for ellers kan du bli forvirret veldig raskt (selv om du etter å ha lest den kan bli forvirret enda raskere). Forhåpentligvis vil imidlertid noen opplysning komme.

Konfigurasjon - noen bruker TLS, noen gjør det ikke

I dette tilfellet fremsettes kravet om at noen brukere skal bruke TLS og andre ikke. For eksempel kan retningslinjene være som følger:

Tillatt anonym tilgang (og usikret kommunikasjon) til et begrenset sett med offentlige LDAP-oppføringer.
Brukere som har bestått LDAP-autentisering (en enkel tilkobling med usikker datautveksling) får lesetilgang til offentlige LDAP-oppføringer, pluss begrensede oppdateringsrettigheter til kun oppføringen som eies av denne brukeren.
Brukere med rettigheter til å oppdatere mer enn én av sine egne poster må bruke TLS og autentisere (forutsatt at de alle er medlemmer av administratorgruppen).
Alle replikeringsforbrukere må bruke TLS / SSL.
TLS / SSL må brukes ved ekstern tilgang til cn = config.

Denne løsningen krever bruk av tilgangskontrollister og serverkonfigurasjonsdirektiver som vist nedenfor:

Generering av LDAP-server- og CA-sertifikater: På dette tidspunktet vil et selvsignert sertifikat bli generert - hvis et kommersielt X.509 (SSL) sertifikat brukes, er denne prosessen unødvendig og kan hoppes over helt. En enkel enkommandometode brukes til å generere et enkelt X.509-sertifikat som kan brukes til både å autentisere serveren og fungere som CA (rot)-sertifikatet for klienten. Denne metoden er dokumentert i detalj (med alle dialogbokser). Sekvens av kommandoer:

# opprette nye kataloger (valgfritt) mkdir / certs mkdir / certs / keys cd / certs # opprette server / CA-sertifikat og privat nøkkel uten passord # gyldig i 10 år med gjeldende retningslinjer for RSA-nøkkelstørrelse # RSA brukes som protokollnøkkelutveksling openssl req -x509 -noder -days 3650 -newkey rsa: 2048 -keyout keys / ldapskey.pem -out ldapscert.pem # sertifikat kan brukes som serversertifikat eller CA-sertifikat # put sertifikat i: /certs/ldapscert.pem # put the private tast inn: /certs/keys/ldapskey.pem # angi tillatelsene -R ldap: ldap / certs / * chmod 0400 keys / ldapskey.pem

Merknader:

For en fullstendig forklaring av alternativene for openssl-kommandoen, se.

Nøkkelfiler har vanligvis en passordfrase (passord) for å beskytte sensitive data. Hvis et sertifikat genereres for en server, brukes aldri en slik passordfrase (genereringen av den undertrykkes av -nodes-argumentet).

Avhengig av kravene til sertifikatet kan andre metoder for å generere selvsignerte sertifikater brukes som beskrevet.

Legger til TLS- og ACL-direktiver til slapd.conf:(se slutten av denne delen for merknader om cn = config). De nødvendige TLS-direktivene legges til i delen for globale innstillinger:

# slapd.conf # global seksjon ... # Sikkerhet - TLS-seksjon TLSCertificateFile /certs/ldapscert.pem TLSCertificateKeyFile /certs/keys/ldapskey.pem TLSCipherSuite TLSv1 + RSA:! NULL # følgende direktiv er satt til dette som standard, # men vi inkluderer det her for klarhetens skyld TLSVerifyClient aldri ... # tilpasset DIT-database bdb-suffiks "d = eksempel, dc = com" # ingen rootdn- eller rootpw-direktiver # se merknader om sikring av rootdn-tilgang ... # ACL # ACL1 - tilgang for replikeringsforbruker # (forutsetter bind som cn = replika, dc = eksempel, dc = com) # forbruker som bruker TLS har lesetilgang til hele DIT # alle andre går til ACL2 (pause) tilgang til * av dn. exact = "cn = replika, dc = eksempel, dc = com" tls_ssf = 128 lest av * pause # ACL2 - tilgang til brukerpassordattributtet # anonyme brukere kan bare autentisere # autentiserte brukere kan endre sine egne passord roller (selv) # medlemmer av administratorgruppen som bruker TLS kan endre passord tilgang til attrs = brukerPassord selv skrive av anonym auth av group.exact "cn = admins, ou = grupper, dc = eksempel, dc = com" tls_ssf = 128 skriv # ACL3 # begrenset anonym skrivebeskyttet tilgang til undertreet offentlig # alle autentiserte brukere kan endre sine # egne oppføringer (selv) i undertreet # admins gruppemedlemmer som bruker TLS har skrivetilgang til hele undertreet offentlig tilgang til dn.subtree = "ou = offentlig, dc = eksempel, dc = com" av group.exact "cn = admins, ou = grupper, dc = eksempel, dc = com" tls_ssf = 128 skriv selv skriv av anonym lest av brukere lest # ACL4 # medlemmer av admins-gruppen som bruker TLS har skrivetilgang til resten av DIT-tilgangen til * ved av group.exact "cn = admins, ou = grupper, dc = eksempel, dc = com" tls_ssf = 128 skriv # siste ACL4 for enkel - hvis ytterligere regler kreves, # bør den erstattes med den nedenfor, som vil filtrere ut alle ikke-TLS-brukere. I dette tilfellet betyr pause at hvis brukeren bruker TLS, # går han til neste ACL, ellers stopper behandlingen. # ACL4 tilgang til * av group.exact "cn = admins, ou = grupper, dc = eksempel, dc = com" tls_ssf = 128 break # ACL5 etc. tilgang .... # replikeringsleverandør overlegg syncprov # cn = config DIT database konfig rootdn "cn = admin, cn = config" rootpw (SSHA) hfkhfhfldkhlkhh # SSF større enn eller lik 128 brukes for å gi sikker tilgang til cn = config sikkerhet simple_bind = 128

Merknader:

Mer informasjon om TLScipherSuite. Parametrene som brukes utelukker bruken av NULL-chiffer (ingen kryptering). TLSv1 dekker SSLv3. EKSPORT-siffer tillatt - internasjonale forbindelser tillatt. Hvis ytelses- og belastningsproblemer er akutte, er det bedre å eksplisitt spesifisere en liste over chiffer med akseptable ytelses- og senn å la vilkårlig chiffervalg stå under TLS/SSL-forhandlinger.

DSA-konfigurasjon: blir snart.

cn = konfigurasjon: blir snart.

ACL-merknader:
1. ACL1: Denne tilgangskontrollisten, som like gjerne kan plasseres i den globale innstillingsdelen, er designet for å isolere på et tidlig stadium av tilkobling av replikeringsforbrukere (DN cn = replika, dc = eksempel, dc = com må være tilstede i DIT med passende passord). av dn.exact = "cn = replika, dc = eksempel, dc = com" tls_ssf = 128 lest inneholder to betingelser som fungerer (selv om de ikke er eksplisitt dokumentert), og treff som vil bli funnet hvis forbrukeren vellykket autentiserte OG brukte SSF (TLS) minst 128. For at replikeringsforbrukeren (og alle andre) skal kunne for å bestå autentisering (eller bare få tilgang til DIT), må betingelsen være til stede ved * pause for å navigere til ACL2 og fortsette å analysere forbindelsen.
  
  ACL2: Lar enhver autentisert bruker endre passordet sitt. Anonym tilgang er gitt for autentiseringsformål ( auth). Ethvert medlem av cn = admins, ou = grupper, dc = eksempel, dc = com gruppen som bruker TLS for å koble til, kan endre et hvilket som helst passord.
  
  ACL3: I denne rekkefølgen har et hvilket som helst medlem av cn = admins, ou = grupper, dc = eksempel, dc = com-gruppen som bruker TLS for å koble til, tillatt å skrive til et hvilket som helst attributt for enhver oppføring i det offentlige undertreet til databasen. Anonyme brukere gis lesetilgang til undertreet offentlig DIT (unntatt userPassword-attributter). Den autentiserte brukeren har lov til å endre hvilken som helst del av oppføringen sin. Til slutt får den autentiserte brukeren (som kobler til med eller uten TLS) skrivebeskyttet tilgang til det offentlige undertreet, med unntak av userPassword-attributtene (og ekskluderer også sine egne oppføringer, hvis tilgangskontroll ble spesifisert i selvklausulen).
  
  ACL4: Bare medlemmer av gruppen cn = admins, ou = grupper, dc = eksempel, dc = com som bruker TLS ved tilkobling er tillatt skrivetilgang til alle andre deler av DIT. Alle andre brukere nektes all tilgang (implisitt betingelse av * ingen).

Venter på tilkoblinger for LDAPS og LDAP URL: Portene som det forventes tilkoblinger på, styres av -h-argumentet når du starter slapd. Som standard er denne verdien ikke spesifisert, som (vanligvis) tilsvarer -h ldap: ///. I henhold til kravene til denne konfigurasjonen, må vi tillate begge operasjonene ldap og ldaps så når du starter slapd må kommandoen brukes:

Slapd -h "ldap: /// ldaps: ///" -u ldap -g ldap

For å gjøre dette automatisk, må du rette oppstartsskriptene i linux (/etc/rc.d/init.d/slapd), og i BSD skal /etc/rc.conf inneholde følgende linje: slapd_flags = "ldap: /// ldaps: ///".

Rootdn tilgangssikkerhet: Etter at DIT opprinnelig ble lastet, hvilke funksjoner gjør det rootdn? I alle standard tilfeller, privilegiene rootdn type for DIT kan gis til enhver spesifikk bruker (la oss kalle det pseudo superbruker) ved å bruke en ACL, og derfor direktivet rootdn kan trygt slettes. I et gjennomtenkt kontrollsystem kan du skaffe en ny pseudo-superbruker de nødvendige tillatelsene ved å bruke standard ACL-er - faktisk er det det de er ment for. Den eneste fallgruven ved denne tilnærmingen er at en feil i ACL kan føre til en begrensning av nødvendige tillatelser. I verste fall, rootdn kan gjenopprettes midlertidig, og deretter fjernes igjen når problemet er løst. Den beste løsningen for å sikre tilgang på vegne av rootdn til en normal DIT, vil det være en sletting av rootdn... Og poenget. Som i konfigurasjonen ovenfor.

I tilfeller hvor rootdn er den eneste tilgangsmetoden som cn = config i eksemplet ovenfor, sikkerhetsdirektivet simple_bind = 128 brukes til å håndheve sikkerhetsmekanismer i en spesifikk databaseseksjon.

Problemer, kommentarer, forslag, rettelser (inkludert ødelagte lenker), eller er det noe å legge til? Ta deg tid til å skrive til oss, webmasteren eller supportteamet. Du vil tilbringe resten av dagen med en følelse av tilfredshet.

For noen mennesker var det første møtet med LDAP når de flyttet fra Windows NT-domener til Active Directory-domener eller når de jobbet med Novell NDS / eDirectory. I andre tilfeller var LDAP-støtte sekundært til kjernefunksjonalitet. For eksempel ble mange kjent med LDAP når de satte opp Exchange 5.5 eller Netscape Messaging e-postservere, opprettet nettsteder med autentiseringskrav, i prosessen med å jobbe med Web Proxy osv. Som et resultat begynte LDAP-kataloger å bli oppfattet som en rent utilitaristisk verktøy for å løse en eller flere andre spesifikke oppgaver. Hensikten med denne artikkelen er å gi leserne en bredere forståelse av applikasjonene til denne teknologien og den interne strukturen til LDAP-kataloger.

LDAP-KATALOGER

En LDAP-katalog er et hvilket som helst LDAP-aktivert datalager. De vanligste katalogene i dag er Microsoft Active Directory, Sun ONE Directory Server (og tidligere versjoner av samme produkt, merket Netscape og iPlanet), og Novell eDirectory (tidligere kjent som Novell NDS).

I en mer generell forstand betyr en katalog vanligvis lagring av relativt statiske data, det vil si de som leses mange ganger oftere enn endret. De grunnleggende datatypene som er lagret i LDAP-kataloger, tilfredsstiller betingelsen om å være relativt statiske. Disse inkluderer:

data som kreves for brukerautentisering (brukernavn, passord);
brukerrettighetsdata, brukerprofiler og innstillinger;
adressedata om en person (telefonnummer, e-postadresse, stilling);
data om grupper av personer (e-postdistribusjonslister, lister, avdelingsansatte);
data om objekter i bedriftsnettverket (datamaskiner, skrivere).

Merk at i dataverdenen eksisterer det allerede ett storskala system, som faktisk er en katalog - dette er DNS-serversystemet. Den eksisterende spesialiserte DNS-teknologien har vist seg godt og krever ingen forbedring (selv om Microsoft tok beslutningen om å implementere DNS i Windows 2000 Server basert på Active Directory, det vil si i hovedsak basert på LDAP-teknologi).

BRUKE LDAP-DIREKTØRER

De fleste LDAP-kataloger kan kategoriseres i flere hovedgrupper basert på deres bruk.

Nettverksoperativsystem (NOS) kataloger... For øyeblikket er det vanligste eksemplet på slik bruk å bygge et bedriftsnettverk som kjører Windows basert på Microsoft Active Directory eller Novell eDirectory.

NOS-kataloger inneholder informasjon om alle objekter på nettverket: data om brukere, brukergrupper, arbeidsstasjoner, servere, skrivere osv. Implementering av en slik katalog gir sentralisert nettverksadministrasjon og styring av autentisering og autorisasjon ved tilgang til nettverksressurser. Dette lar deg unngå duplisering av regnskapsinformasjon ved forskjellige brukspunkter. (Det bør bemerkes at funksjonaliteten til Active Directory og eDirectory ikke er lik - naturlig nok er Active Directory bedre integrert med Windows NT og 2000 operativsystemer. Begge løsningene har både styrker og svakheter, og derfor må et helt sett med faktorer være nøye. veid før du tar en avgjørelse.)

Brukerautentisering på nettverk som kjører forskjellige UNIX-varianter kan ordnes på lignende måte; i dette tilfellet brukes PAM-modulen og enhver LDAP-katalog.

Kataloger for lagring av data om applikasjonsbrukere. Mange bedriftsprogramvareprodusenter har valgt å ikke finne opp hjulet på nytt og bygge sitt eget lagringssystem. I stedet plasseres brukerpassord, tillatelser og profiler i LDAP-kataloger.

Et typisk eksempel på denne tilnærmingen er Sun ONE-produktlinjen, som blant annet inkluderer en e-postserver, en webproxy, en kalenderserver og en webserver. Disse produktene er naturlig designet for å fungere med Sun ONE Directory Server, og alle applikasjoner kan lagre brukerdata på samme katalogserver. På samme måte er Exchange 2000-postboksserver avhengig av Active Directory som et depot for informasjon om brukerne.

LDAP støttes av et stort antall applikasjoner fra mindre leverandører. Dette gjelder spesielt for webteknologiprodukter som webservere, portalservere og applikasjonsservere.

Kataloger som adressebøker til organisasjoner. Katalogen kan inneholde referanseinformasjon om ansatte - e-postadresse, telefonnummer, rom, stillingstittel osv. Brukergrensesnittet er vanligvis en e-postklient som Microsoft Outlook eller Netscape Messenger (kun for søk og lesing) eller en spesiallaget klient vanligvis tilgjengelig via nettet. Adresseboken brukes til å søke og se informasjon, automatisk fylle ut e-postadresser og lagre PKI-sertifikater som er nødvendige for å organisere elektronisk utveksling av konfidensiell informasjon.

Eksterne brukerkataloger. Når du bygger nettapplikasjoner som forretningspartnere eller kunder i organisasjonen din jobber med, må du opprette en autentiseringsmekanisme; Tradisjonelt brukes også LDAP-kataloger til dette.

Det er viktig å merke seg at fra et synspunkt om å administrere informasjonsmiljøet, bør antallet kataloger som dannes ved bedriften (og generelt antall brukerdatalagre) minimeres. Derfor er det alltid nyttig å vurdere mulighetene for å bruke én katalog til forskjellige formål. For eksempel kan NOS-katalogen fungere som en adressebok, og katalogen for en spesifikk applikasjon kan gjøres tilgjengelig for andre applikasjoner. En slik tilnærming (konsolidering av brukerdata) tilbys eksplisitt av de største produsentene av kataloger og programvare som bruker dem - først og fremst snakker vi om Microsoft og Sun.

Dermed er den samme LDAP-katalogen i stand til å utføre en rekke oppgaver.

LDAP-PROTOKOLL

Lightweight Directory Access Protocol (LDAP) er en applikasjonslagsprotokoll; den støtter klient-server-kommunikasjon og kjører over TCP/IP (som standard bruker LDAP TCP-port 389). Ideen til LDAP oppsto etter eksperimentering med tidlige implementeringer av X.500-standarden på slutten av 1980-tallet og begynnelsen av 1990-tallet. (disse implementeringene viste seg å være svært komplekse og for krevende for dataressurser på klientsiden, noe som førte til behovet for å utvikle en annen klientprotokoll). De tekniske spesifikasjonene for den nye protokollen (RFC 1487 for LDAP versjon 2 og RFC 1777 for den nå allestedsnærværende LDAP versjon 3) ble utgitt i henholdsvis 1993 og 1995.

LDAP ble opprinnelig brukt for å komplementere X.500-klientprotokollen, DAP. Dermed er LDAP-kataloginformasjonsmodellen fullstendig arvet fra X.500. I moderne kataloger støttes enten ikke X.500-protokollene i det hele tatt, eller eksisterer på nivå med LDAP, men X.500-informasjonsmodellen er fortsatt implementert - LDAP-klienten "vet ikke" fra hvem den mottar informasjon - fra gatewayen mellom LDAP og DAP, eller fra uavhengig LDAP-server.

LDAP er designet for å være så enkelt som mulig fra begynnelsen: for eksempel mangler det støtte for komplekse transaksjoner. Standarden definerer ni operasjoner:

lesing og søk - søke, sammenligne;
redigering - legge til, slette, endre, gi nytt navn;
etablere og bryte kommunikasjon - binde, løsne, forlate.

Navnene på disse operasjonene taler generelt for seg selv og krever ingen forklaring. La oss bare ta hensyn til fraværet av leseoperasjonen - funksjonene utføres ved søk. (Vi forklarer nedenfor hvordan søkeoperasjonen fungerer.)

DATALAGRING

Protokollspesifikasjoner spesifiserer ikke i hvilket format selve dataene skal lagres, og leverandører løser dette problemet på forskjellige måter. I de fleste katalogservere er hvelv spesielt designet for å ta hensyn til den relative statiske naturen til katalogdataene. Kataloger som kombinerer X.500- og LDAP-støtte bruker lagringsformatet foreskrevet av X.500. I Oracle Internet Directory og IBM SecureWay lagres data i den respektive leverandørens administrasjonssystemer for relasjonsdatabaser (Oracle og DB2). Til slutt kan systemer der denne funksjonaliteten er sekundær fungere som LDAP-kataloger, for eksempel en Exchange-postserver eller et Lotus Domino-miljø, der data presenteres i "native" formater.

Merk at når du bygger et LDAP-katalogsystem basert på produkter basert på et DBMS, vil en merkbar del av funksjonaliteten til denne lagringen forbli ubrukt og kan påvirke systemytelsen negativt. Derfor er det ganske logisk at de mest utbredte er kataloger basert ikke på et DBMS, men på spesialiserte lagringer.

Til slutt, produkter som MaXware Virtual Directory (MVD) er "virtuelle kataloger". MVD fungerer som en gateway mellom ethvert datalagringsformat (standard eller ikke-standard – den kommer med sitt eget API-bibliotek for håndtering av ikke-standardformater) og LDAP. Med MVD kan nesten alle depoter representeres som en LDAP-katalog.

INFORMASJONSMODELL

Data i LDAP-kataloger er representert som objekter; informasjon om hvert objekt lagres i et sett med attributter (mer presist, i form av par "attributtnavn - attributtverdi"). En viktig forskjell fra et DBMS er muligheten til å tildele flere attributter med et felles navn til ett objekt: for eksempel kan et objekt som beskriver en bruker inneholde flere telefonnumre eller e-postadresser.

Et sett med mulige attributter er satt for hver katalog på forhånd. Standardsettet kan endres eller utvides om nødvendig. Sammen med navnet på attributtet er syntaksen fast (streng, nummer, dato, etc.), og derfor, i motsetning til DBMS-verdenen, er navnet på attributtet nesten alltid uendret fra katalog til katalog. Altså attributtet c (land) overalt betyr navnet på landet, l (lokalitet)- bosetting, ou (organisasjonsenhet)- avdelinger av organisasjonen, cn (vanlig navn)- en kombinasjon av for- og etternavn osv. Attributet dc (domenekomponent), angir navnet på segmentet til bedriftsnettverket.

Hvert katalogobjekt tilhører en eller flere objektklasser. En objektklasse beskriver typen av et objekt og definerer:

hvilke attributter må være tilstede for et objekt av denne klassen;
hvilke attributter kan være tilstede i et objekt av denne klassen;
hvilken attributt kan brukes til å navngi objekter i en gitt klasse

Objektklasser danner sitt eget trehierarki; et objekt som tilhører en objektklasse eies automatisk av alle dens superklasser (alle klasser er underklasser av den generiske klassen topp) - dette objektet er underlagt alle begrensningene spesifisert for underklassene, så vel som begrensningene for sin egen klasse.

For eksempel et objekt som tilhører klassen person, må ha ikke-tomme attributter cn og sn(etternavn, etternavn) og kan ha attributter telefonnummer, beskrivelse og noen andre. Et objekt som tilhører underklassen organisatoriskPerson (underklasseperson) må tilfredsstille de samme kravene og kan i tillegg inneholde andre attributter, bl.a. tittel(stilling) og ou.

Den vanligste objektklassen for lagring av brukerinformasjon i dag er inetOrgPerson(her inet brukes som en forkortelse for Internett). Dette er en underklasse av klassen organisatorisk person, er det beskrevet i RFC 2798 (i motsetning til klassene person og organisatorisk person som er inkludert i X.521-standarden). Dette er fordi X.500-standardene ble formulert på 1980-tallet. selv før Internetts utbredelse, og klassene beskrevet der, mangler for eksempel et standardfelt for en e-postadresse.

Katalogobjektklasser er delt inn i hoved og hjelpe (hjelpe). Hvert objekt må tilhøre minst én hovedklasse og kan tilhøre ytterligere klasse(r). Vanligvis er attributtene til sistnevnte applikasjonsspesifikke. For eksempel når det gjelder å tildele et objekt i klassen inetOrgPerson til tilleggsklassen nsmessagingserverbruker det annonseres som en bruker av Sun ONE Messaging-e-postserveren; denne klassen lar deg legge til et attributt til et objekt nsmsg forbyr tilgang kreves for at denne serveren skal fungere. Dermed lar mekanismen til tilleggsklasser deg bruke en eksisterende katalog som lagring av data om brukere av en ny applikasjon.

Settet med attributttyper og objektklasser definert for en gitt katalog kalles skjemaet. Skjemaet for alle de viktigste LDAP-katalogene konfigureres av administratoren, selv om det foreløpig ikke er noen standard måte å konfigurere det på, noe som fører til en viss grad av inkompatibilitet: en applikasjon som trenger en LDAP-katalog for å lagre brukerdata må ha prosedyrer for tilpasse katalogskjemaet separat for hver (mye brukte) katalogserver.

NAVN PÅ KATALOGOBJEKTER

Katalogobjekter er organisert i en hierarkisk logisk struktur - et tre. Roten er et tomt rotobjekt rot; objekter på neste nivå kalles suffikser.

Hvert objekt er tildelt ett navneattributt (Relative Distinguished Name, RDN). Den fullstendige identifikatoren til et objekt (Distinguished Name, DN) er en streng oppnådd ved å sette sammen alle RDN-er mens du beveger deg gjennom treet fra dette objektet til roten (se eksempel nedenfor). Merk at RDN ikke trenger å være unikt på tvers av hele katalogen: for å sikre at DN er unikt, er det tilstrekkelig at RDN er unikt blant objekter i nærheten (de som ligger rett under objektet ett nivå høyere).

Hierarkiet pålegger visse begrensninger på muligheten til å slette katalogobjekter: et objekt som andre objekter forblir under kan ikke slettes.

FORMAT FOR DATAUTVEKSLING

LDAP Data Interchange Format (LDIF) er en standard måte å representere katalogdata på som tekstfiler. Med LDIF kan informasjon leses fra en katalog, redigeres med et vanlig tekstredigeringsprogram, og eksporteres til samme eller til en annen katalog. En LDIF-fil kan inneholde data for et hvilket som helst antall katalogobjekter.

Som et eksempel, la oss ta en titt på LDIF for et enkelt Sun ONE Directory Server-objekt:

dn: uid = vshabat, ou = IKT, o = NIICHAVO

Cn; lang-ru :: 0JLQsNGB0LjQu9C40Lkg0Kj

Nsmsgdisallowaccess: pop http

Foretrukket språk: ru

Mailhost: mail.niichavo.ru

Postleveringsalternativ: postkasse

Fornavn; lang-ru :: 0JLQsNGB0LjQu9C

Post: [e-postbeskyttet]

Objektklasse: topp

Objektklasse: person

Objektklasse: organisatoriskPerson

Objektklasse: inetorgperson

Objektklasse: postmottaker

Objektklasse: nsmessagingserveruser

Cn: Vasily Shabat

Sn; lang-ru :: 0KjQsNCx0LDRgg ==

Fornavn: Vasily

Ou: Administratorer

Eksemplet viser at:

RDN for objektet - " uid = vshabat»;
Objekt DN - " uid = vshabat, ou = IKT, o = NIICHAVO", Det vil si at det er to objekter til over den i treet (med DN" ou = IKT, o = NIICHAVO"og" o = NIICHAVO", henholdsvis);
dette katalogobjektet tilhører objektklassen inetOrgPerson og dens superklasser, organisatorisk person, person og topp samt to tilleggsklasser postmottaker og nsmessagingserverbruker, dvs. vshabat er bruker av Sun ONE Messaging Server;
attributtverdi nsmsg forbyr tilgang Indikerer at den aktuelle brukeren ikke har rett til å få tilgang til e-post via POP- og HTTP-protokollene;
verdien av ou-attributtet trenger ikke samsvare med RDN til oppstrømsenheten;
egenskaper cn, sn og fornavn har lokaliserte versjoner på russisk. I en LDIF-fil er de gitt etter base64-kodede doble kolon (LDAPv3 støtter fullt ut UTF8-koding)

AUTENTISERING OG KONTROLL AV TILGANG TIL KATALOGDATA

Med enkel autentisering må klienten enten erklære seg anonym eller oppgi bruker-DN og passord under bindingsoperasjonen ( binde). Tilgangskontrollinformasjonen i katalogen lar deg finne ut om den har fått rett til å utføre den forespurte operasjonen.

Operasjon binde det brukes ofte av andre applikasjoner når det ikke umiddelbart er behov for å jobbe med katalogdata. For eksempel kan en applikasjon be om et brukernavn og passord, fra dem en forespørsel til katalogen for en operasjon binde og kontroller implementeringen. Hvis operasjonen går uten feil, anses autentiseringen som vellykket. Merk bare at i de fleste tilfeller, når autentisering utføres av sluttbrukere, er ikke detaljene for arbeid med DN synlige: applikasjonen ber om et brukernavn og passord, og finner deretter (kobler til katalogen i samsvar med sine egne rettigheter) DN av et objekt med et spesifikt brukernavn og prøver først deretter å utføre kommandoen binde.

Autentisering kan gjøres på mer komplekse (men også sikrere) måter, for eksempel ved å bruke PKI-nøkler.

Presentasjonsmetoder for tilgangskontrollinformasjon (ACI) er fortsatt ikke standardiserte og implementeres forskjellig i forskjellige LDAP-servere.

SØK DATA I KATALOGEN

For å utføre en søkeoperasjon ( Søk) i LDAP-katalogen trenger klienten følgende parametere:

serveradresse (DNS-navn eller IP-adresse);
portnummer (standard 389);
LDAP-versjon (2 eller 3, standard 3). For øyeblikket er servere som kun støtter versjon 2 sjeldne, og mange klienter bruker versjon 3 som standard;
Bruker-DN, passord - for autentisering;
Base-DN definerer grunnlaget for søket. Søket vil kun utføres i den delen av treet som ligger under det angitte objektet;
et søkefilter som inneholder meningsfulle krav til attributtverdier. Strengeattributter kan kontrolleres mot en gitt streng eller for tilstedeværelsen av en gitt understreng. For numeriske attributter er et ulikhetssøk mulig. I tillegg kan standard logiske operasjoner (AND, OR, NOT) også brukes i filtre;
søkeområde ( omfang). Mulige alternativer - undertre, ett eller utgangspunkt... Når du søker etter undertre(den vanligste; mange klienter angir dette som standard) en del av treet skannes under basisobjektet. Ved søk en bare de objektene som er rett under basen (det vil si ett nivå under) vurderes. Til slutt, når du søker etter utgangspunkt bare selve basisobjektet analyseres (operasjon Søk med søkeomfang utgangspunkt er mer en leseoperasjon enn et søk, selv om posten fortsatt kontrolleres mot søkefilteret);
nødvendige attributter. Som standard vil et søk returnere attributtene til alle postene som er funnet, og et tilpasset søk vil returnere verdiene til spesifikke attributter.

Et søkefilter kan bestå av et objektklassekrav. For eksempel filteret " objektklasse = inetOrgPerson»Samsvarer med alle objekter i denne klassen i søkeomfanget.

Merk at de fleste servere sørger for at tilgangskontroll avhenger av typen søkeoperasjon. En administrator kan for eksempel sette en betingelse slik at et objekt er synlig for en spesifikk bruker kun ved søk. utgangspunkt det vil si når brukeren søker etter det bestemte objektet.

I eksemplet vist i figur 1 er søkefilteret sammensatt som en logisk kobling av OG-betingelser for brukerens tittel og hans navn.

FORESPØRSEL FOR DROPPE, RETNING OG RELÉ

Når det gjelder de ofte brukte systemene, har kataloger høye krav til tilgjengeligheten av tjenesten deres. Dette betyr at katalogdataene må plasseres på flere sammenkoblede servere, noe som vil gjøre det mulig å implementere:

et geografisk spredt system der katalogservere er i umiddelbar nærhet av brukerne;
et feiltolerant system når data dupliseres på to eller flere servere, og feilen på en av dem ikke avbryter katalogen;
skalerbart system med høy tilgjengelighet som tåler betydelige belastninger på grunn av deres fordeling mellom ulike servere.

For å implementere slike systemer er det nødvendig med en mekanisme for differensiell replikering av data mellom individuelle katalogservere (bare endringer i innholdet i katalogen overføres over nettverket). Slike mekanismer finnes i alle vanlige katalogservere, men de er fortsatt ikke standardiserte, noe som betyr at det er umulig å organisere replikering mellom servere til forskjellige produsenter uten involvering av tredjepartsverktøy.

Replikering kommer i to varianter - med en eller flere masterservere. Den første metoden sørger for at hvert katalogobjekt kan endres på en av serverne; kopiene på andre servere er skrivebeskyttet. Den andre fjerner denne begrensningen. Et fullverdig feiltolerant system, det vil si et system som fortsetter å behandle forespørsler om dataredigering etter at en av serverne feiler, er bare mulig i det andre tilfellet. Multi-master replikering er implementert i Active Directory, eDirectory og Sun ONE Directory (i sistnevnte tilfelle kan det ikke være mer enn to hovedservere). Merk at et slikt opplegg er potensielt farlig: i fravær av en transaksjonskontrollmekanisme kan endringer som gjøres på hovedserverne komme i konflikt med hverandre. Den passende mekanismen bestemmer hvilke endringer som til slutt vil finne sted og hvilke som ikke vil (og som et resultat vil gå tapt).

For å implementere feiltolerante og høye tilgjengelige systemer, kreves det ekstra lastbalanseringsverktøy. Dette verktøyet kan være en LDAP-proxyserver, DNS Round Robin eller en maskinvareløsning som Cisco Local Director.

Flere servere kan kobles til et enkelt system på andre måter. Når du bruker en henvisning, kommuniserer LDAP-serveren at klienten må kontakte en annen LDAP-server for å behandle forespørselen. Videresending krever at alle involverte LDAP-klienter tolker henvisningen riktig – dessverre gjør ikke de fleste klienter på markedet det.

På den annen side, overleveringsforespørsler ( lenking) fra LDAP-klienten innebærer ingen tilleggsfunksjonalitet: LDAP-servere deler katalogtreet seg imellom og videresender forespørselen fra server til server selv. LDAP-klienten i dette tilfellet "vet" ikke engang at en reléforespørsel ble brukt. Reléforespørsler implementeres i katalogservere som støtter X.500 - Siemens DirX, Critical Path Directory Server, Nexor. Den tilsvarende protokollen, DSP, er en del av X.500-standarden.

ADMINISTRASJON AV KATALOG

Hver katalogserver kommer med et grensesnitt som lar deg både konfigurere og administrere serveren og administrere katalogdataene. Spørsmålet om dataadministrasjon er imidlertid ikke fullstendig løst av disse verktøyene.

Til å begynne med er noen av grensesnittene for å jobbe med katalogdata ganske enkelt vanskelige hvis du regelmessig får tilgang til dem; for eksempel kan strukturen til et bestemt katalogtre være slik at det tar omtrent ti museklikk for å redigere ett attributt for én bruker. Slike grensesnitt gir ikke muligheten til å automatisere eller forenkle ofte utførte oppgaver.

På den annen side er det ingen produkter på markedet som vil gjøre det mulig å fullstendig forlate administrasjonsverktøyene til enhver LDAP-katalog. Problemet er at et slikt verktøy ikke bare skal tillate redigering av data, men også å administrere tilgangsrettigheter og endringer i katalogskjemaet, og lignende funksjoner implementeres på forskjellige servere på forskjellige måter. Nylig har imidlertid verktøy som Softerra LDAP Administrator og det gratis verktøyet for administrasjon av LDAP-nettleserkataloger blitt mer populære. Driften av begge er begrenset til håndtering av katalogdata.

Generelt trenger ikke systemadministratorer å administrere katalogdata. Delegering av administrasjon, et sett med mekanismer og konvensjoner der brukere utenfor IT-avdelingen er ansvarlige for å legge inn katalogdata, er en fornuftig ansvarsfordeling. For eksempel er den generelle styringen av personalinformasjon overlatt til HR-avdelingen, og enkelte attributter, som et telefonnummer, kan redigeres av de ansatte selv.

Til slutt kan ulike lagre av brukerdata kombineres til et enkelt katalogsystem - med metakataloger som er ansvarlige for synkronisering mellom lagrene. For eksempel, ved å bruke metakatalogen, kan Active Directory som brukes på bedriftsnettverket kombineres med Sun ONE Directory Server som brukes av Sun ONE-applikasjoner som Messaging Server, så vel som med bedriftens HR-system. Som et resultat blir innholdet i katalogen administrert automatisk basert på data fra andre systemer.

Vasily Shabat - Leder for løsningsutviklingsavdelingen hos Open Technologies. Du kan kontakte ham på:

Kataloginformasjonsbase - DIB). Informasjonen inkluderer navnet på et objekt samt ulike attributter som kjennetegner det objektet. Disse anbefalingene kalles X.500-standarden.

Directory Access Protocol (DAP) ble utviklet for å få tilgang til objektene i denne distribuerte databasen.

LDAP ( Lightweight Directory Access Protocol) gir de fleste funksjonene til DAP til en betydelig lavere implementeringskostnad. For eksempel er overflødige og sjelden brukte operasjoner fjernet. LDAP, i motsetning til X.500, bruker TCP-stakken i stedet for OSI.

Det er imidlertid ingen en-til-en-korrespondanse mellom LDAP-operasjoner og X.500 DAP-operasjoner.

LDAP er en protokoll som brukes for å få tilgang til informasjon som er lagret på servere distribuert over et nettverk.

Denne informasjonen er dataene som er lagret i attributtene. Dette forutsetter at slike data leses oftere enn endres. LDAP er basert på en klient-server kommunikasjonsmodell.

Den generelle modellen for denne protokollen er at serveren utfører operasjonene som kreves av klienten. Klienten sender en forespørsel som beskriver operasjonen som skal utføres av serveren. Serveren utfører de nødvendige operasjonene i katalogen. Etter at en operasjon eller flere operasjoner er fullført, returnerer serveren et svar til klienten som inneholder resultatene eller en feilkode.

Merk at mens servere er pålagt å returnere svar når slike svar er spesifisert i protokollen, er det ingen krav til synkron klient- eller serveradferd. Forespørsler og svar for flere operasjoner kan sendes mellom klient og server i hvilken som helst rekkefølge, men klienter må motta et svar for hver av sine forespørsler.

Informasjon på en LDAP-server er en samling poster som inneholder et sett med attributter og er gruppert i en trelignende hierarkisk struktur.

Posten identifiseres med et globalt unikt navn (Distinguished Name - DN) - som ligner på et domenenavn i DNS-strukturen.

Katalogen er en spesialisert database som kan brukes i hverdagen - telefonbok, programguide, etc. Katalogdataene antas å være ganske statiske. DNS er et klassisk eksempel på en slik spesialisert database.

LDAP-fordeler

Hovedårsakene til den økende populariteten til LDAP er relatert til det faktum at:

LDAP har et standard lagringsskjema, i motsetning til relasjonsdatabaser, der hvert tilfelle definerer sitt eget lagringsskjema i form av tabeller og kolonner og relasjoner mellom tabeller. Derfor er LDAP ikke spesifikk for hver katalog og for hver administrasjonsapplikasjon - det er ikke noe såkalt "N + 1 Directory-problem". Alle LDAP-servere bruker et enhetlig lagringsskjema, en enhetlig måte å navngi lagrede objekter på og en enhetlig tilgangsprotokoll.
LDAP lar deg raskt finne dataene du trenger fordi den fokuserer mer på å lese og hente informasjon enn på å endre den.
LDAP trenger ikke være begrenset til en enkelt server, det er mulig å organisere distribuerte systemer fra flere servere. Koblinger kan opprettes mellom forskjellige LDAP-servere slik at du kan søke i flere LDAP-servere samtidig.
Både LDAP-protokollen og LDAP-katalogstrukturen er organisert i henhold til standarder slik at forskjellige leverandør-LDAP-implementeringer kan brukes konsekvent.

Sammenligning av LDAP og database

La oss sammenligne de to mest populære metodene for å lagre informasjon i dag, relasjonsdatabaser og LDAP-servere, i henhold til følgende egenskaper:

Lese-skrive-forhold- LDAP er, i motsetning til relasjonsdatabaser, optimert for lesing.
Utvidbarhet- LDAP-skjemaer er lettere å endre på farten enn databaseskjemaer.
Fordeling- LDAP-data kan lokaliseres på flere servere, som kan søkes ved hjelp av en enkelt kommando. Som et resultat kan du lage optimalt plasserte LDAP-serverkonfigurasjoner basert på hvor informasjonen er nødvendig, samtidig som du sikrer at all informasjon som er lagret på alle LDAP-servere kan søkes. Dette oppnår en høyere grad av distribusjon enn relasjonsdatabaser.
Replikering– LDAP-data kan lagres på flere servere, samtidig som det er mulighet for å bruke ulike metoder for informasjonssynkronisering.
Dataapplikasjon- LDAP er designet for effektiv bruk av data lagret i katalogen av forskjellige applikasjoner, databaser er utviklet for en applikasjon.
Kompleksiteten av relasjoner mellom objekter- databaseobjekter har mer komplekse relasjoner enn LDAP-poster.
Transaksjoner- i LDAP er transaksjoner enklere, vanligvis endres én post, transaksjoner i databaser er mer komplekse.
Type informasjon som er lagret- LDAP lagrer informasjon i attributter.
Navnemetode– LDAP er en hierarkisk datastruktur. Navnet på et objekt er banen til det objektet i hierarkietreet, på samme måte som filstier i vanlige filsystemer.
Ordninger- relasjonsdatabaseskjemaer er fullstendig definert av utvikleren av den tilsvarende databasen, LDAP har standardskjemaer, inkludert kjerneskjemaet, felles for enhver katalog. Dette oppnår større interoperabilitet sammenlignet med databaser.
Standarder- bruk av standard lagringsskjemaer og en standard tilgangsprotokoll er en fordel med LDAP fremfor databaser, siden i dette tilfellet kan LDAP-klienter kommunisere med hvilken som helst LDAP-server, og databaseklienter kan bare samhandle med databasen de er designet for.
Evne til å rulle tilbake ved mislykkede operasjoner- Relasjonsdatabaser har mer fleksible tilbakerullingsmuligheter, derfor er de mer egnet for å endre informasjon enn LDAP. For dynamiske objekter kan det hende at LDAP-funksjonene ikke er tilstrekkelige.

Prinsipper for distribusjon av LDAP-servere

Når du distribuerer LDAP-servere, må du fullføre følgende oppgaver:

Bestem hva som skal lagres i katalogen. Du må ha en klar forståelse av hvilke applikasjoner som fungerer med dataene.
Bestem datastrukturen i katalogen og etablere deres relasjoner.
Bestem settet med nødvendige katalogskjemaer basert på applikasjonskrav.
Definer et navneområde.
Bestem serverplasseringstopologien.
Bestem replikasjonene som kreves, og sørg for at data er tilgjengelige der det er nødvendig.
Bestem det optimale sikkerhetsnivået, ta hensyn til de spesifikke sikkerhetskravene.

Denne artikkelen ble skrevet for et datamagasin for lenge siden. Siden siden da har de ikke kontaktet meg om hennes videre skjebne, konkluderer jeg med at det ikke var nyttig, og jeg legger det ut til offentligheten.

Dette er IKKE en LDAP-installasjons- og implementeringsveiledning. Bare en oversikt for de som ikke vet ennå - hva slags dyr er dette ...

Kommentarer er velkomne.

TJENESTER AV KATALOGER. hva er det og hva er det for

Og uansett hva folk sier der -
Jeg vil leve, jeg vil gå gjennom stjernene,
Jeg vil fortelle dem i katalogen,
Jeg skal lese dem på nytt fra nattens bok.

Nettverk vokser. Lokale nettverk er intet unntak. Ofte har nettet som bare i går koblet sammen tre datamaskiner vokst, modnet og overgrodd med ressurser i dag. Hvordan ikke gå seg vill i dem? Hvordan ikke bli forvirret i pålogginger og passord? Hvordan finne informasjonen du trenger raskt? Før eller siden dukker disse spørsmålene opp for nesten alle systemadministratorer.

Mange klarer seg med selvskrevne manus. Disse er ekte samuraier, viljen deres er som bladet til en katana, og tiden som brukes kompenseres lett av erfaringen. Andre, sofistikerte av prosessen med å overføre saker og stillinger i tilfelle bytte av jobb eller reise på ferie, bruker standardiserte løsninger. Navnet på disse løsningene er katalogtjenester.

I denne anmeldelsen vil jeg kort introdusere deg til kurset. Så hva er egentlig katalogtjenester?

Veldig kort og veldig forenklet - dette er en slags database som lagrer informasjon om brukere, noder og nettverksobjekter. Formålet med opprettelsen er å forenkle administrasjonen.

Spørsmålet oppstår: hvorfor ikke bruke databasen? Poenget er at det er ganske betydelige forskjeller mellom en katalogtjeneste og en relasjonsdatabase:

informasjonslagringsmodell - en hierarkisk trestruktur (en database har en relasjonsstruktur);
LDAP er fokusert på å fremskynde leseoperasjonen, mens skriveoperasjonen er prioritert i databasen;
data i LDAP endres relativt sjelden;
klienter bruker standard LDAP-protokoll, mens databaseinteraksjonsprotokollen med klienter ikke er standardisert;
og til slutt er katalogtjenesten vanligvis lett skalerbar (replisert) på tvers av flere servere.

Katalogtjenesten integreres enkelt med en rekke tjenester, alt fra webservere til CMS (content managment system). Se i dokumentasjonen for applikasjonen du bruker som krever autorisasjon, og se etter LDAP-nøkkelordet. Funnet det? Så dette er det...

Det hele startet enkelt. Nettverk var små og datamaskiner var store. Og det var ikke så mange av dem. I de halvglemte, nesten episke tidene, var det enkelt å kopiere konfigurasjonsfiler fra en datamaskin til en annen.

Men tiden gikk. Nettverkene vokste og modnet. Det ble mer og mer åpenbart at det måtte noen form for løsninger til. Noe som vil gjøre det allerede vanskelige livet til system- og nettverksadministratorer enklere.

En av de første implementeringene av denne typen tjenester var utviklingen av Sun Microsystems, opprinnelig kalt Gule Sider. Deretter, på grunn av juridisk friksjon, ble navnet endret til Network Information Service (NIS) som det fortsatt er viden kjent under (i smale sirkler).

Utviklingen var basert på en enkel idé – mange av konfigurasjonsfilene for datamaskiner som jobber i nettverket er helt like. Så hvorfor ikke få datamaskiner til å ta disse filene fra én server. Dermed ble ikke bare diskplass spart (NIS ble utviklet for lenge siden og denne faktoren var ganske relevant), men også tiden brukt på å synkronisere disse filene.

Det var vanskelig å kalle det en katalogtjeneste, men de første skritt i riktig retning ble tatt.

Ettersom ideen viste seg å være etterspurt, gikk CCITT og ISO videre og utviklet en serie X.500-standarder, som inkluderte følgende protokoller: DAP (Directory Access Protocol), DSP (Directory System Protocol), DISP (Directory Information Shadowing Protocol) ), og DOP (Directory Operational Bindings Management Protocol). Imidlertid ble disse protokollene senere funnet å være altfor komplekse, og det ble arbeidet med å utvikle en erstatning. Det ble Lightweight Directory Access Protocol (LDAP), som fungerte som grunnlaget for mange vellykkede løsninger.

Historien til de mest kjente LDAP-baserte produktene går tilbake til 1995, da ansatte ved University of Michigan skrev den første LDAP-serveren - slapd. I 1996 ansatte Netscape dem. I 1999 ble AOL eier av Netscape. For å fortsette arbeidet med serverprodukter ble det inngått en strategisk allianse med Sun. De kalte det iPlanet Alliance. Fra 1999 til 2001 jobbet Netscape Directory Server-teamet i samarbeid med Sun Directory Server-teamet, og deretter med utviklerne av Innosoft Directory Server (IDDS). Det ble utført arbeid på både Directory Server og relaterte prosjekter som Meta Directory og Directory Access Router. I oktober 2001 ble iPlanet Alliance oppløst, og medlemmene Sun og Netscape begynte uavhengig å utvikle produktene sine. Fra 2001 til 2004 jobbet Netscape Directory Server-utviklerne mye med dette prosjektet. I desember 2004 ble Netscape Directory Server eiendommen til Red Hat.

Så, med denne historien over, la oss se hvilke katalogtjenester som er tilgjengelige og hvordan de er gode.

NIS (selv om det strengt tatt ikke er en katalogtjeneste).

Denne utviklingen av Sun Microsystems viste seg å være veldig seig og er fortsatt i bruk i dag. Dens fordeler er enkelhet i konsept og implementering. Minus - kan bare brukes på UNIX-kompatible operativsystemer med samsvarende konfigurasjonsfiler. La oss hylle henne og gå videre til fullverdige LDAP-produkter. I denne artikkelen vil jeg ikke dvele ved de tekniske detaljene, jeg vil bare si at deres grunnleggende funksjonalitet avviker litt. Forskjellene begynner på nivået av dokumentasjon og applikasjonsprogramvare som gjør administrasjonen enklere.

Så la oss starte med åpen kildekode og gratis. Det er ikke mange av dem. Faktisk bare to.

Red Hat Directory Server og Fedora Directory Server

Red Hat Directory Server ble opprinnelig kjøpt fra Netscape Security Solutions som et kommersielt produkt for Red Hat Enterprise Linux, og er nå utgitt av Red Hat selv under navnet Red Hat Directory Server. I tråd med sin policy, gir Red Hat også ut en versjon for Fedora Core. Navnet er Fedora Directory Server. Red Hat Directory Server kjører Red Hat Enterprise Linux (x86, versjon 3 og 4), Solaris 9 (SPARC, både 32-bit og 64-bit), HP-UX 11i for HP-9000 og 64-bit linje med HP Integrity server. Fedora Directory Server er mindre kresen og godtar å jobbe under Fedora Core (x86, versjon 3 og 4) og Red Hat Enterprise Linux, så vel som andre linux-versjoner - gentoo, debian, etc. Solaris, Windows 2000 og HP/UX 11i (pa-risc) støttes også. Konklusjon: Godt valg for RedHat-baserte distribusjoner. Godt dokumentert hvordan det er gunstig sammenlignet med OpenLDAP. Koden til disse prosjektene er stort sett den samme (på grunn av felles stamfar).

Åpne LDAP

OpenLDAP er en videreutvikling av den opprinnelige slapden. Stor spredning. Den brukes på mange plattformer som Linux, FreeBSD, Windows og MacOS X. Dokumentasjonen på siden vil bli kalt Spartan. Imidlertid satt sapienti, og det er mange trinnvise opplæringsprogrammer på nettet. Hvis du av en eller annen grunn ikke er fornøyd med å bruke et produkt fra RedHat, er OpenLDAP et utmerket valg, tidstestet. Funksjonaliteten til begge prosjektene er nesten identisk.

Det er her åpne og gratis LDAP-servere slutter og bedriftsbaserte løsninger begynner. Dessverre er detaljene om deres opprinnelse og funksjonalitet skjult bak glansen av markedsføringspressemeldinger. Derfor skal jeg gjøre meg kort.

Novell eDirectory

Først noen få ord om lisenspolitikken da den er ganske interessant. For det første er alle produkter gratis for universiteter. For det andre kan du installere dette produktet og bruke det helt gratis (årlig lisens for 100 000 brukere. Det er ingen teknisk støtte. Du kan få det ved å be om en prøvenøkkel en gang i året). For det tredje kan du kjøpe det. Pris - $ 2 for én brukerlisens uten tidsbegrensning. Fungerer under følgende operativsystemer: Novell Netware, Windows (NT-gren), Linux (SUSE Enterprise eller RedHat), Solaris, AIX, HP-UX. Sammendrag: løsningen er alt i ett - hele spekteret av nødvendige programmer leveres umiddelbart. Installasjon og konfigurasjon gjøres så praktisk som mulig. Lav pris. Flott dokumentasjon. For registrerte brukere - de. Brukerstøtte. Kryssplattform. Minus - lukket kilde.

Microsoft ActiveDirectory

Inkludert med Windows Server 200x. Ideell løsning for MS-nettverk. Hvis du planlegger å bruke en produktlinje kun fra MS - det er verdt å vurdere. Hvis det derimot brukes noe annet enn Windows 200x som server, anbefaler jeg å følge nøye med på produktene ovenfor. Konklusjon: Utmerket integrering i systemet, dokumentasjon av høy kvalitet. Ulempen er den ganske høye prisen.

Sun Java System Directory Server

På begynnelsen av 2000-tallet fusjonerte Sun med iPlanet og ved hjelp av utviklingen (spesielt iPlanet Directory Server) skapte det sitt eget produkt - Sun ONE, senere omdøpt til Sun Java System Directory Server. Det er ikke et frittstående produkt, men bare en del av Java Enterprise System. Systemkrav: Solaris 10, Solaris 9, Solaris 8 (kun SPARC), Red Hat Enterprise Linux 2.1 og 3.1, HP-UX 11i, Microsoft Windows 2000, XP (for utviklere), 2003. Selges ikke separat fra Java Enterprise System. Konklusjon - hvis du bestemmer deg for å bruke en helhetlig løsning fra Sun, vil du selvsagt ikke ha noen spesielle problemer. Sun-ingeniører kan hjelpe deg med å installere og tilpasse den til dine behov. For penger, selvfølgelig.

IBM Tivoli Directory Server

LDAP-løsning fra IBM. Fungerer under følgende operativsystemer: AIX, Solaris, Microsoft Windows 2000, HP-UX, samt Linux for Intel og IBM eServer iSeries, pSeries og zSeries. Prisene starter på $ 10 000. Løsningen er tydeligvis ikke for alle. Det er imidlertid verdt å merke seg dokumentasjonen som er tilgjengelig for alle. Jeg anbefaler på det sterkeste til alle med interesse for LDAP IBM Red Books Understanding LDAP - Design and Implementation Selv om den hovedsakelig dekkes av IBM Tivoli Directory Server, inneholder den mye teoretisk materiale av høy kvalitet om hva LDAP er og hvordan det er bedre å planlegge katalogen din.

Dette avslutter min litt utstrakte fortelling. Håper jeg klarte å interessere deg. Til slutt vil jeg si følgende. LDAP er neste trinn i implementeringen av DHCP. Bekvemmeligheten oppnådd gjennom bruken oppveier arbeidskraften som er involvert i introduksjonen. Hvis det lokale nettverket ditt har mer enn 10 datamaskiner, tenk på LDAP.