Vanlige LDAP-funksjoner


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

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.

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.

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

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