LDIF

LDAP Data Interchange Format ( LDIF , LDAP Data Interchange Format) er et format til at repræsentere adressebogstjenesteposter eller ændringer til dem i tekstform. Katalogposter eller ændringer er repræsenteret af et sæt LDIF-poster, en for hver telefonbogspost eller ændring. En LDIF-fil kan kun indeholde én type indgang, det vil sige kun en katalogpostrepræsentation eller kun en katalogpostændringsrepræsentation.

LDIF blev udviklet i begyndelsen af ​​90'erne af Tim Howes , Mark C Smith og Gordon Good ved University of Michigan og blev videreudviklet og udvidet i slutningen af ​​90'erne til brug med LDAP version 3. Denne senere version af formatet, givet versionsnummer 1, blev formelt specificeret af IETF i RFC 2849 , offentliggjort i juni 2000, og er i øjeblikket en foreslået standard.

Mange udvidelser til LDIF er blevet foreslået gennem årene. En af dem er officielt specificeret af IETF og offentliggjort i RFC 4525 . Andre udvidelser forventes også at blive offentliggjort.

Katalogindtastningsformat

Katalogposter er repræsenteret af grupper af linjer adskilt af en tom linje, hvor hver linje i gruppen repræsenterer en separat indgangsattributværdi. Den første linje i gruppen skal repræsentere et unikt postnavn. Attributværdien er skrevet i 7-bit ASCII -kodning og er adskilt fra navnet med  tegnet ":" . Værdier, der ikke passer til denne kodning, er skrevet i base64- kodning og er adskilt fra attributnavnet med  "::"- tegn . Attributværdien kan også indstilles fra en ekstern ressource ved at angive dens enkelte pointer og adskille den fra attributnavnet med  ":<"- tegn . File://-skemaet er påkrævet for alle implementeringer og betyder, at værdien af ​​attributten læses uændret fra den angivne fil.

dn: <unikt_navn> <attribute_name>: <attribute_value> <attributnavn>:: <base64_attribute_value> <attributnavn>:< <url> dn: <unikt_navn> <attribute_name>: <attribute_value> <attribute_name>: <attribute_value>

Hjælpeprogrammer, der bruger LDIF

LDIF-begrænsninger

Attributværdier med flere værdier kan ikke erstattes direkte. Du skal først fjerne attributværdierne og derefter bruge "add:" flere gange for at indsætte alle de nødvendige værdier.

LDIF felter

dn: unikt navn

Henviser til et navn, der entydigt identificerer en adressebogspost.

dc: domænenavn

Refererer til hvert domæne fra det fuldt kvalificerede navn . For eksempel skal www.google.com skrives som DC=www,DC=google,DC=com

ou: organisatorisk enhed

Refererer til den organisatoriske enhed (nogle gange en brugergruppe), som brugeren er en del af. Hvis en bruger tilhører mere end én gruppe, så kan denne skrives som OU= Advokat,OU= Dommer.

cn: almindeligt navn

Henviser til navnet på den enhed (navn på person; mødelokale; opskrift; stillingsbetegnelse), som anmodningen blev fremsat om.

LDIF-eksempler

Et eksempel på en simpel adressebogspost med flere attributter:

dn: cn=Postmesteren,dc=eksempel,dc=com objektklasse: organisatorisk Rolle cn: Postmesteren

Et eksempel på ændring af værdierne for flere enkeltværdiattributter for to forskellige biblioteksposter (formatet brugt af Microsoft LDIFDE-værktøjet):

dn: CN=John Smith,OU=Legal,DC=eksempel,DC=com changetype: modificere erstatte:medarbejder-ID medarbejder-id: 1234 - erstatte:medarbejdernummer medarbejdernummer: 98722 - erstatte: extensionAttribute6 extensionAttribute6: JSmith98 - dn: CN=Jane Smith,OU=Regnskab,DC=eksempel,DC=com changetype: modificere erstatte:medarbejder-ID medarbejder-id: 5678 - erstatte:medarbejdernummer medarbejdernummer: 76543 - erstatte: extensionAttribute6 extensionAttribute6: JSmith14 -

Bemærk: Tegnet "-" mellem hver ændring af attributværdien er påkrævet. Hver telefonbogspost skal ende med et "-" efterfulgt af en tom linje. Det sidste tegn "-" er også påkrævet.

Et eksempel på tilføjelse af telefonnummeret på en eksisterende bruger:

dn: cn=Peter Michaels, ou=kunstnere, l=San Francisco, c=US changetype: modificere tilføje: telefonnummer telefonnummer: +1 415 555 0002

RFC'er

Se også