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