Vanlige LDAP-funksjoner

• S?kefiltre
• LDAP-URL-er
• Krypterte forbindelser (TLS/SSL)
• Autentisering (login) med passord

S?kefiltre

Et LDAP-s?k returnerer de poster som matcher det oppgitte s?kefilter og "search scope". Et enkelt filter ser ut som "(attributtnavn=verdi)", hvor verdien kan inneholde "*" som matcher hva som helst. Filtre kan kombineres med "&" (og), "|" (eller) og "!" (ikke): "(&(objectClass=person)(|(cn=*ola*nordmann*)(uid=olan)))" ser etter en person hvor enten navnet matcher *ola*nordmann* eller brukernavnet er olan. "(!(sn=Berg))" ser etter en post som ikke inneholder etternavn Berg.

En del klienter masserer imidlertid det oppgitte filteret. Dette gj?r at brukeren ikke trenger vite s? mye om LDAP, men det kan ogs? bli vanskelig ? f? klienten til ? bruke akkurat det filteret man vil. For eksempel skal kanskje klienten konfigureres med noe slikt som (cn=$0), som den endrer til (&(objectClass=person)(|(cn=*$0*)(mail=*$0*))) og bytter ut $0 med s?keteksten. Det filteret finner bare personer, selv om du har satt s?kebasen til "dc=uio,dc=no" som inneholder b?de personer og organisasjons?enheter. (Attributt objectClass=person finnes i hver personpost, uavhengig av navnet p? s?ketreet "cn=people,dc=uio,dc=no" som alle personposter ved UiO er plassert under.)

Persons?k kan s?ke etter attributtene cn (fullt navn), givenName (fornavn), sn (etternavn), uid (brukernavn - "*" virker ikke her), telephoneNumber og mail.

En kan s?ke etter organisasjons?enheter med ou (navn, forkortelse eller akronym), telephoneNumber og mail. De har ogs? cn (fullt navn) registrert, men det er un?dvendig ? s?ke etter det siden vi registrerer samme verdi i ou.

Dermed kan f.eks. s?keteksten "hei" skrives om til filteret (|(cn=*hei*)(uid=hei)(mail=*hei*)(telephoneNumber=*hei*)(ou=*hei*)).

Trengs mer kompliserte s?k, som ? finne en person ved en gitt enhet, les om innholdet i katalogen.

LDAP-s?kefiltre er formelt definert i RFC 4515.

LDAP-URL-er

Noen klienter vil ha LDAP-oppsettet som en LDAP-URL, typisk "ldap://ldap.uio.no/dc=uio,dc=no" - eller bare "ldap://ldap.uio.no/" pluss at s?kebasen (som "dc=uio,dc=no") oppgis separat.

Noen nettlesere kan sl? opp LDAP-URL-er direkte. F.eks. ldap://ldap.uio.no/dc=uio,dc=no??sub?(ou=USIT) for ? finne USIT. Det er imidlertid sjelden s?rlig brukervennlig i forhold til web-grensesnittet nevnt ?verst.

En LDAP-URL ser ut som ldap://ldap.uio.no/base-dn?attr?scope?filter

• alt etter "ldap://" kan utelates hvis klienten har standardverdier fra andre steder.
• base-dn er hvor i katalogtreet ? s?ke fra, typisk dc=uio,dc=no.
• attr kan som regel utelates. Det er en komma-separert liste med attributter som skal returneres hvis de finnes.
• scope er base (bare sl? opp base-dn), one (objekter rett under base-dn) eller sub (hele subtreet fra og med base-DN). Som regel bruker man sub.
• filter er s?kefilteret.
• en del tegn i filter og m? DN skrives p? %hex-format som i andre URL-er.

LDAP-URL-er er formelt definert i RFC 4516.

Krypterte forbindelser (TLS/SSL)

Hvis du trenger sikker kommunikasjon med LDAP, m? du kryptere forbindelsen med TLS eller SSL og sjekke sertifikatet som LDAP-tjeneren da skal oppgi.

En kryptert LDAP-forbindelse settes opp ved ? bruke en "ldaps:" URL (LDAP over SSL) i stedet for en "ldap:" URL, eller ved ? be programmet starte TLS over "ldap:"-forbindelsen.

• TLS (Transport Layer Security) og SSL (Secure Sockets Layer) er omtrent samme protokoll internt, men de brukes forskjellig. "ldaps:" (LDAP over SSL) har sin egen port, 636. StartTLS er en operasjon mot den vanlige LDAP-porten, 389. Det virker ikke ? blande dem sammen: ? bruke port 636 uten ? oppgi "ldaps:" protokollen, eller ? gj?re StartTLS mot "ldaps:"-porten.
• Dessverre finnes det forvirrede klienter som bruker "ldaps:" hvis du konfigurerer dem med en "ldap:"-URL og at de skal bruke TLS. Det er derfor best ? unng? ? oppgi portnummer hvis klienten ikke krever det, slik at klienten kan velge porten til den protokollen den vil bruke.

Programmet m? ogs? sjekke LDAP-tjenerens sertifikat, som den skal sende n?r man starter TLS/SSL. Hvis ikke kan en angriper "stjele" forbindelsen slik at du setter opp en kryptert forbindelse til en fiendtlig tjener. Det er ikke lurt hvis man f.eks. binder til LDAP med passordet sitt, som tjeneren dermed f?r vite.

• Det er dette nettlesere klager over n?r de ber deg se p? en tjeners sertifikat. Sertifikatet kan v?re ugyldig eller maskinnavnet i sertifikatet ulikt maskinnavnet du koblet til, som avgjort gir grunn til mistanke. Eller s? kjenner den verken igjen sertifikatet eller CA-sertifikatet som signerte det, s? programmet ikke vet om sertifikatets eier er den han sier han er.
• N?r sertifikat A er signert av sertifikat B, betyr det at eieren av sertifikat B bekrefter identiteten til eieren av sertifikat A. Det er ikke n?dvendigvis en bekreftelse av at eieren av sertifikat A er ? stole p?, du bestemmer selv om du stoler p? den adressen/tjenesten du kobler deg til.

For ? kunne sjekke sertifikatet, be katalog-drift@usit.uio.no om CA-sertifikatet som signerte LDAP-tjenerens sertifikat.

• Det er bedre ? registrere CA-sertifikatet som signerte tjener-sertifikatet enn ? registrere tjener-sertifikatet, siden sistnevnte endres oftere.
• Hvordan du gir CA-sertifikatet til klienten varierer med klientene. Med en nettleser kan det antakelig registreres med dens andre sertifikater. Med programmer som bruker OpenLDAP-biblioteket kan det konfigureres i filen ~/.ldaprc eller ldap.conf.

Du kan ogs? melde deg p? e-postlisten "ldap-varsel", som bl.a. varsler n?r CA-sertifikatet vil endres (kanskje 1-2 ganger pr ti?r).

Autentisering (login) med passord

For ? autentisere mot LDAP m? forbindelsen krypteres, siden passordet ellers ville blitt sendt i klartekst over nettet. Tjeneren avviser uansett passord fra ukrypterte forbindelser. Se ogs? Bruk av Bind.

Dette er uavhenging av hvordan du er logget inn p? maskinen du bruker.

Brukerprogrammer:

Normale brukerprogrammer har ikke bruk for ? autentisere mot LDAP.

Noen e-postklienter kan st?tte dette (de ber da gjerne om brukerens "Bind DN" eller om de skal logge inn i LDAP), men det er un?dvendig. E-postklienter trenger brukernavn og passord for ? lese e-post, men de bruker ikke LDAP til det. De bruker bare LDAP til adressebok, som trenger "Base DN" men ikke "Bind DN".

Tjenester:

Tjenester som trenger ? autentisere personer eller brukere (be om passord og sjekke om det er riktig) kan bruke LDAP til det. Generelt b?r imidlertid ikke tjenester be om passord, s?rlig ikke web-tjenester skrevet av andre enn USIT.

Snakk med USIT om du planlegger en tjeneste som krever brukernavn og passord, enten den skal bruke FEIDE, LDAP eller NIS.

Hvis brukeren oppgir et eksisterende brukernavn men feil passord, b?r tjenesten bare svare noe slikt som "Feil brukernavn eller passord" heller enn ? opplyste at brukernavnet eksisterer.

Tjenester - autentisere personer:

Tjenester b?r helst bruke Uninetts FEIDE-tjeneste til ? autentisere personer. FEIDE bruker person-treet i LDAP til autentiseringen. Inntil videre kan brukere som ikke er i dette treet ogs? autentisere seg, men den ordningen skal fjernes.

Hvis du likevel autentiserer personer via LDAP, ikke s?k etter personen f?rst og deretter bind med den DN som ble funnet. Da kan ikke skjulte personer autentisere seg, siden s?ket ikke vil finne dem. Generer i stedet DN "uid=prim?rbruker,cn=people,dc=uio,dc=no" direkte og bind med denne. (En person kan ha flere brukere, hvorav en er hans prim?rbruker. Bare prim?rbrukeren er i person?treet.) N?r personen er autentisert, kan du sl? opp informasjon om personen om n?dvendig - selv om personen ellers er skjult i katalogen.

Tjenester - autentisere e-postbrukere:

Tjenester som IMAP, POP og Webmail m? bruke mail-targets-treet i LDAP og ikke NIS (Network Information Service, tidl. "YP") til ? autentisere e-postbrukere, bl.a. siden det finnes e-postbrukere som ikke har hjemmeomr?de og dermed ikke er i NIS.

Autentiser ved ? s?ke under cn=targets,cn=mail,dc=uio,dc=no etter "(&(target=brukernavn)(targetType=user))" og deretter binde med den DN som ble funnet. Bare utvalgte maskiner har aksess til mail-tr?rne.

Autentisere brukere:

Du kan ogs? autentisere brukere mot bruker-treet (som reflekterer NIS) med DN "uid=brukernavn,cn=users,cn=system,dc=uio,dc=no". Som regel er det imidlertid personer man ?nsker ? autentisere: UiO har et ordnet forhold til "personer", de finnes i sentrale registre (L?nns- og trekksystemet eller Felles Studentsystem). Derimot har vi ikke n?dvendigvis oversikt over hvem en "bruker" egentlig er - vi vet kanskje bare ved hvilket sted brukeren er registrert og hvem hans IT-ansvarlige er.

Det har v?rt diskutert om vi skal legge inn andre brukere enn de som har hjemmeomr?de (p? Unix) i bruker-treet. Hvis en tjeneste bare vil slippe inn de som har hjemmeomr?de b?r den derfor antakelig sjekke om brukeren har objektklasse posixAccount.

SASL, Kerberos