El servei de directori

Avui dia les persones i empreses confien en els sistemes informàtics connectats en xarxa per utilitzar aplicacions distribuïdes. La informació de la xarxa pot ser recollida en una base de dades especial que es diu directori. Un directori s’utilitza habitualment per emmagatzemar la informació dels usuaris, com ara el nom de l’usuari i la contrasenya. També es possible emmagatzemar-hi informació com les dades de contacte dels usuaris (directori d’una empresa) i també s’utilitza sovint per inventariar recursos (inventari de màquines, impressores, servidors i altres recursos de xarxa).

A mesura que el nombre de xarxes i aplicacions creix, el nombre de directoris especialitzats d’informació també augmenta, cosa que dóna lloc a “illes” d’informació que són difícils de compartir i gestionar. El Lightweight Directory Access Protocol (LDAP) és un estàndard obert que ha evolucionat per proporcionar un mètode estàndard per accedir a la informació en un directori i actualitzar-la. L’LDAP ha obtingut una gran acceptació com a mètode d’accés a directoris dins de les xarxes corporatives. Està recolzat per un gran nombre de proveïdors de programari i ha estat incorporat a un nombre creixent d’aplicacions.

Servei de directori

Un directori és un llistat d’informació sobre uns objectes disposats en un ordre que dóna detalls sobre cada objecte. Exemples comuns de directoris són una guia telefònica d’una ciutat o un catàleg d’una biblioteca. En una guia telefònica, els objectes de la llista són les persones, els noms estan ordenats alfabèticament i els detalls guardats sobre cada persona són la direcció i el número de telèfon. Els llibres d’un catàleg d’una biblioteca estan ordenats per autor o per títol, i se’n guarda informació com l’ISBN o altres característiques de la publicació.

En termes informàtics, un directori és una base de dades especialitzada (també anomenada repositori de dades) que emmagatzema informació sobre objectes i que està específicament dissenyada per optimitzar les operacions de consulta. Un servei de directori és el programari que emmagatzema, organitza i facilita l’accés a la informació d’un directori.

Per exemple, un directori pot incloure informació sobre les impressores (els objectes), que consistirà en dades com ara la ubicació (una cadena de caràcters), la velocitat en pàgines per minut (numèric), els fluxos d’impressió compatibles (per exemple, PostScript o ASCII) i així successivament.

Els directoris permeten als usuaris o a les aplicacions trobar informació que compleixi unes característiques determinades. Per exemple, un directori es pot utilitzar per buscar una adreça de correu electrònic d’una persona concreta, per trobar una impressora en color propera, per consultar la informació de facturació d’un client específic…

En un directori es pressuposa un nombre molt més alt de lectures que d’escriptures, ja que generalment la informació continguda canvia rarament (per exemple el nombre de telèfon d’una persona). Aquest aspecte és important i el diferencia d’una base de dades de propòsit general, en la qual les operacions són tant de lectura com d’escriptura. En el disseny d’un directori, els esforços d’optimització es concentren en les cerques i les lectures, i no és cap problema que això penalitzi les actualitzacions.

Els directoris poden contenir molts tipus d’informació i estendre la seva utilitat a diverses aplicacions, però complint sempre aquestes característiques:

  1. La informació que contenen està basada en objectes (cada objecte és una entrada del directori) i en els atributs d’aquests objectes.
  2. Les actualitzacions i modificacions de les dades són simples i no gaire freqüents.
  3. Estan optimitzats per donar una resposta ràpida a operacions de cerca i revisió.
  4. Poden replicar la informació per augmentar-ne la disponibilitat i la fiabilitat alhora que disminueix el temps de resposta a les consultes.

Alguns exemples d’ús de directori són:

  1. Autenticació d’usuaris.
  2. Autenticació de màquines.
  3. Llibreta d’adreces.
  4. Representació de l’estructura de l’organització.
  5. Emmagatzematge d’informació telefònica.
  6. Cerca d’adreces de correu electrònic.

Clients i servidors de directori

Els serveis de directori solen implementar-se seguint el model client-servidor, de manera que una aplicació que vol accedir al directori no accedeix directament a la base de dades, sinó que, tal com mostra la figura, crida a una funció de l’API (Application Programming Interface) proporcionada pel servei, que envia un missatge a un procés del servidor. Aquest procés accedeix al directori i retorna el resultat de l’operació.

API i protocol

Una API defineix la interfície de programació que un llenguatge de programació particular utilitza per accedir a un servei. El format i contingut dels missatges intercanviats entre el client i el servidor s’han d’adherir al protocol acordat.

Algunes vegades, el servidor pot convertir-se en el client d’un altre servidor per aconseguir la informació necessària per processar la petició que se li ha realitzat.

Figura Arquitectura client-servidor del directori

Seguint aquest model, el client no depèn de l’arquitectura del servidor i el servidor pot implementar el directori de la manera més convenient.

El servidor del directori i el client han d’implementar un protocol comú per comunicar-se i és aquest el que caracteritza les diferents solucions que s’han desenvolupat. El Lightweight Directory Access Protocol (LDAP) facilita serveis centralitzats i distribuïts d’informació mitjançant una xarxa TCP/IP i s’ha convertit en l’estàndard de facto d’accés a la informació emmagatzemada en un servidor de directori per a usuaris i aplicacions.

Avantatges dels serveis de directori

Un directori específic d’una aplicació només emmagatzema la informació necessària per a aquella aplicació en particular i no és accessible per altres aplicacions. La mateixa adreça de correu electrònic emmagatzemada per una aplicació de calendari també pot ser emmagatzemada per una aplicació de correu electrònic i per una aplicació que avisa els operadors del sistema de problemes en els equips. Cada aplicació crea i administra el seu propi directori.

En un entorn on només una aplicació ha d’accedir a les dades, potser l’esforç necessari per implantar un servei de directori electrònic estàndard és innecessari, però l’experiència demostra que tard o d’hora diverses aplicacions acaben utilitzant aquestes dades, i en el cas de no haver implantat un directori centralitzat ens trobem amb diversos directoris que han d’estar sincronitzats i que accedeixen de maneres diferents a les dades contingudes en directoris creats a mida. Això implica un major esforç per fer el manteniment i un fre al desenvolupament d’aplicacions basades en el directori.

El fet de disposar d’un servei de directori comú, multiplataforma, accessible mitjançant un protocol estàndard i amb una API estàndard, permet als programadors desenvolupar les aplicacions sense haver de crear directoris específics.

Des del punt de vista de l’administració de sistemes, configurar el sistema perquè les aplicacions utilitzin un servei de directori comú, dissenyat de manera adequada, permet controlar més fàcilment els riscos de fallada per inconsistència de dades i concentrar els esforços en millorar l’administració i la tolerància a fallades del servei.

El protocol LDAP

LDAP són les inicials de Lightweight Directory Access Protocol (protocol lleuger d’accés a directoris). Com el seu nom indica, és un protocol pensat per permetre l’accés a serveis de directori.

L’LDAP funciona amb un esquema client-servidor, en el qual un (o diversos) servidors mantenen la mateixa informació de directori (actualitzada mitjançant rèpliques) i els clients fan consultes a qualsevol d’ells.

A l’LDAP la informació està estructurada en forma d’arbre. Aquesta estructura s’anomena directori i cada node s’anomena entrada. Per la seva part, cada entrada està formada per un conjunt d’atributs, cadascun dels quals és d’un tipus i conté un o més valors.

Origen de l'LDAP

El 1984, la UIT-T (llavors anomenada CCITT) va decidir desenvolupar una especificació de directori de propòsit general. La necessitat més immediata era proporcionar un directori per a la gestió de l’estàndard X.400 de missatges de correu electrònic. Al mateix temps, l’ISO/IEC JTC1 va iniciar una activitat similar. Les dues organitzacions van acordar fusionar els dos treballs en un de sol per evitar la producció de dues normes diferents per al mateix propòsit. Aquesta col·laboració va donar com a resultat la norma X.500. Aquesta norma és un conjunt d’estàndards de xarxes d’ordinadors per a serveis de directori. La norma defineix un protocol anomenat DAP (Directory Access Protocol o protocol d’accés a directoris).

Organitzacions relacionades amb el protocol LDAP

UIT-T és el Sector de Normalització de la Unió Internacional de Telecomunicacions.

CCITT és l’acrònim de Comitè Consultiu Internacional Telegràfic i Telefònic.

ISO és l’acrònim de la International Organization for Standardization i IEC ho és de la International Electrotechnical Commission. ISO/IEC treballen conjuntament en la preparació, adopció i utilització de diferents estàndards.

ISO/IEC JTC1 és el comitè tècnic que treballa en l’estandardització dins del camp de les tecnologies de la informació.

El DAP és un protocol molt complex (i d’elevat cost computacional), ja que està definit sobre la pila completa del model OSI (Open System Interconnection, en català ‘Interconnexió de Sistemes Oberts’). L’LDAP és un protocol més lleuger, gairebé equivalent al DAP, més senzill i eficient, ja que està dissenyat per funcionar directament per TCP/IP.

L’LDAP és un subconjunt del DAP que s’ha desenvolupat per al seu ús amb TCP/IP, de manera que hereta els conceptes fonamentals de la norma X.500, però simplifica la comunicació entre el servidor i el client i no inclou les característiques menys utilitzades del DAP.

L’especificació LDAP es defineix a l’RFC 4510 de l’Internet Engineering Task Force (IETF).

Característiques de l'LDAP

Existeixen altres tecnologies que ofereixen informació a un client, però els serveis de directori que implementen el protocol LDAP ofereixen alguns avantatges significatius:

  1. Consulta ràpida de dades: l’objectiu d’un servidor de directori és la recuperació ràpida d’informació. L’LDAP ofereix un mètode lleuger de connexió a un dipòsit, lectura de dades i tancament de la connexió.
  2. Solució distribuïda: com que l’LDAP és un protocol natiu de xarxa d’arquitectura distribuïda, pot distribuir a tota la xarxa informació llesta per ser usada per totes les aplicacions. Fins i tot pot reproduir una part del directori per donar un servei amb certes característiques en un entorn determinat. O moure (delegar) la informació a diversos llocs sense afectar cap accés extern a aquestes dades.
  3. Independència de la plataforma: com que l’LDAP és un protocol estàndard, que proporciona un mètode d’accés a dades remot i local, és possible intercanviar completament la implementació de l’LDAP sense afectar la forma en que es podrà accedir a les dades. Hi ha una àmplia gamma de implementacions. Per suposat, el client i el servidor es poden executar en sistemes operatius diferents.
  4. Seguretat integrada en el repositori: la informació d’accés s’emmagatzema en el mateix repositori. Alguns productes poden treballar amb drets i permisos de granularitat fina i també proporcionen la capacitat de controlar els drets d’accés en funció de factors externs, com ara l’adreça IP del client. Com que aquests controls s’executen de manera centralitzada pel servidor, són fàcils de mantenir. Els clients, per tant, no s’han de preocupar d’aquests detalls.
  5. Implementació fàcil del client: la disponibilitat d’interfícies de programació (API) de l’LDAP per a gairebé qualsevol llenguatge de programació facilita la compatibilitat de l’LDAP amb pràcticament totes les aplicacions.
  6. Gran difusió: com que l’LDAP és un protocol estàndard, molts proveïdors l’han adoptat al seu programari. Per exemple, IBM Tivoli, Microsoft Active Directory, Novell eDirectory o RedHat Directory Server.
  7. Baix cost: l’LDAP és un protocol estàndard i no cal pagar llicències pel seu ús ni per disposar de clients o servidors (de codi font obert).

Característiques de l'LDAPv3

L’LDAPv2 es va dissenyar amb l’objectiu de ser implementat amb facilitat. Encara que ja realitza les principals operacions, va ser substituït per l’LDAPv3 perquè tenia algunes limitacions. Actualment només es recomana la compatibilitat amb la versió 3 de l’LDAP.

Algunes de les característiques particulars de l’LDAPv3 són:

  1. La majoria dels elements de dades del protocol es poden codificar com a cadenes normals.
  2. Els valors dels atributs i els noms distintius s’han internacionalitzat mitjançant l’ús del conjunt de caràcters ISO 10646 (UTF-8).
  3. El protocol pot ser ampliat per permetre noves operacions.
  4. El resultat retornat poden ser referències. Això significa que un servidor de directoris que no contingui les dades sol·licitades les pot demanar a un altre servidor de directori o pot informar el client d’on les pot trobar.
  5. Els clients poden demanar l’esquema que descriu les estructures de dades disponibles al directori.
  6. Hi ha atributs operacionals (amb finalitats administratives) gestionats pel servidor.
  7. Disposa de protecció per contrasenya, ús de certificats digitals i accés SSL.
  8. Els mecanismes SASL (capa d’autenticació i seguretat) es poden utilitzar amb l’LDAP per proporcionar serveis de seguretat.

Funcionament de l'LDAP

En el model client-servidor de l’LDAP, davant d’una consulta concreta d’un client, el servidor contesta amb la informació sol·licitada. La resposta pot ser, de forma alternativa (o a més de la informació que s’havia sol·licitat), un punter que indica on aconseguir aquesta informació o dades addicionals (habitualment, el punter apunta a un altre servidor de directori).

Aquesta configuració client-servidor es pot fer amb un únic servidor, com es pot veure en la figura. Amb aquest funcionament es proveeix el servei de directori per a una sola organització.

Figura L’LDAP com a servei local

Es pot decidir separar el directori entre diversos servidors per motius organitzatius o per facilitar-ne la gestió. Es aquest cas es poden delegar parts del directori a un altre servidor, com s’observa en la figura. Aquesta configuració també es fa servir si es vol que el directori formi part d’un directori global. El servidor està configurat per tornar referències a altres servidors LDAP en el cas que se li demani informació de la qual no disposa, però que sap on aconseguir.

Figura LDAP amb delegació

Es pot augmentar la disponibilitat i la fiabilitat del directori fent servir més d’un servidor LDAP per mantenir la informació. D’altra banda, durant un temps limitat pot mancar sincronització entre mestre i esclaus.

L’actualització de dades es produeix a nivell d’entrada i no d’atribut, de manera que si es modifica un atribut, el mestre envia als esclaus tota l’entrada, cosa que és problemàtica quan hi ha entrades grans o modificacions freqüents.

A més de la configuració mestre-esclau com la que mostra la figura, hi ha implementacions amb replicació multimestre (les actualitzacions es repliquen a diversos nodes que poden actuar com a mestre).

Figura LDAP amb replicació

Missatges LDAP

L’LDAP s’implementa directament a TCP/IP i fa servir cadenes simples per transportar les dades. És un protocol orientat a missatges, és a dir, tan bon punt arriba un missatge al receptor, l’operació de recepció ha acabat, perquè ja s’ha rebut tota la informació referent a aquell missatge.

Tots els missatges d’anada i tornada entre el servidor i el client —les peticions que el client envia al servidor, els resultats que el servidor envia al client i els codis de resultat—viatgen en aquest format.

El procés de negociació és el següent:

  1. El client LDAP envia una sol·licitud al servidor LDAP.
  2. El servidor executa una o diverses operacions (segons el que s’especifiqui a la sol·licitud).
  3. En el cas d’una transmissió correcta, el servidor envia els resultats. En cas d’error s’envia al client el codi d’error corresponent.

Cada missatge LDAP, tant si és una petició com una resposta, conté la identificació del missatge, un codi d’operació i les dades. L’identificador del missatge es necessita per determinar la sol·licitud a la qual correspon una resposta, dada molt important, perquè el mode l’LDAP no requereix que les sol·licituds i respostes es facin de forma síncrona.

Els models LDAP

L’LDAP és un estàndard i no pas un maquinari o programari que es pot comprar. El que s’instal·la en l’equip client o servidor és la implementació d’aquest protocol; la qüestió de com emmagatzemar o tractar les dades es deixa als proveïdors de l’aplicació de la norma final.

Implementacions del protocol LDAP

Existeixen diverses implementacions del protocol LDAP realitzades per diferents companyies, entre d’altres:

  • Active Directori: és la implementació de Microsoft en els seus sistemes operatius Windows Server.
  • RedHat Directory Server o 389 Directory Server: una implementació realitzada per RedHat/Fedora.
  • ApacheDS: un servei de directori que ofereix l’Apache Software Foundation.
  • OpenDS: una implementació Java del protocol LDAP.
  • OpenLDAP: una implementació lliure de l’estàndard.

Tot i la llibertat d’implementació, el sistema pot caracteritzar-se segons algun dels quatre models següents:

  1. El model d’informació descriu l’estructura de la informació emmagatzemada en el directori LDAP.
  2. El model de noms descriu com s’organitza i identifica la informació en el directori LDAP.
  3. El model funcional descriu quines operacions poden ser realitzades amb la informació emmagatzemada en el directori LDAP.
  4. El model de seguretat descriu com es pot protegir la informació continguda en el directori LDAP davant d’intents d’accés no autoritzats.

Model d’informació

El model d’informació defineix quin tipus d’informació es pot emmagatzemar en el directori i les unitats bàsiques en què l’LDAP estructura la informació.

DIT

A l’LDAP la informació està estructurada en forma d’arbre. Aquest arbre s’anomena arbre d’informació del directori o DIT (Directory Information Tree).

Tradicionalment, aquesta estructura ha reflectit límits geogràfics i organitzatius. A la part superior de l’arbre s’han representat els països, i a sota, els estats, les organitzacions , les unitats organitzatives, les persones, els ordinadors, les impressores, els documents o altres conceptes. Aquesta estructura es mostra en la figura.

Figura Arbre de directori LDAP amb nomenclatura tradicional

L’arbre del directori també es pot estructurar en funció dels noms de domini d’Internet (DNS). Aquesta pràctica està cada vegada més estesa, ja que permet trobar un servidor LDAP realitzant una consulta DNS. En la figura es pot veure un exemple d’arbre de directori amb una organització basada en el DNS. Aquest tipus de representació és el més habitual a dia d’avui a l’hora d’implementar serveis de directori per administrar dominis informàtics.

Figura Arbre de directori LDAP amb nomenclatura DNS

Entrada (entry)

Cada node de l’arbre s’anomena entrada. Una entrada és una col·lecció d’atributs identificada per un nom distintiu (distinguished name o DN). Aquest DN és únic al directori i fa referència a l’entrada de manera unívoca (de la mateixa manera que un identificador caracteritza de manera unívoca un registre en una base de dades relacional).

El DN de cada entrada del directori es representa mitjançant una cadena de caràcters formada per parells de la forma:

<tipus_atribut>=<valor>[,<tipus_atribut>=<valor>]

Aquest nom representa la ruta des de la posició de l’entrada fins a l’arrel de l’arbre (base, segons la nomenclatura LDAP). Com que se suposa que un directori es fa servir per emmagatzemar els objectes d’una organització determinada, la base serà la ubicació d’aquesta organització. Així, la base es converteix en el sufix de totes les entrades del directori.

Cada entrada té una entrada pare (parent) i pot tenir o no entrades fills (child). Cada entrada fill és un germà (sibling) de les altres entrades fills del mateix pare.

Exemples de noms distintius

En l’arbre de la figura 5 la base seria “o=Empresa,st=Catalunya,c=ES” i el DN de la persona representada seria “cn=Marc Freixas,ou=Vendes,o=Empresa,st=Catalunya,c=ES”.

En l’arbre de la figura 6 la base seria “dc=Empresa,dc=com” i el DN de la persona representada seria “uid=mfreixas,ou=Persones,dc=Empresa,dc=com”.

Atributs (attributes)

Les entrades estan formades per un conjunt d’atributs. Cada atribut d’una entrada té un tipus i un valor (SINGLE-VALUE) o més (MULTI-VALUE, que és el comportament predeterminat). El tipus d’atribut té associat els valors permesos i el seu comportament a l’hora de fer comparacions, ordenacions o treballar amb subcadenes.

Els tipus són habitualment cadenes de text mnemòniques, com poden ser cn per fer referència a common name (nom comú), sn asurname (cognom) o mail a email address (adreça de correu electrònic).

La sintaxis dels valors dependrà del tipus de l’atribut, per exemple, l’atribut cn podria contenir el valor “Marc Freixas”, l’atribut mail podria contenir un valor com “mfreixas@empresa.com” i un atribut jpegPhoto contindria una imatge en format binari.

Classes d’objecte (objectClass)

Els atributs que conté una entrada estan condicionats per les classes d’objecte a les quals pertany. Una classe d’objecte agrupa conjunts d’atributs que poden ser opcionals (indicat amb MAY) o obligatoris (indicat amb MUST) i la unió de tots els atributs de totes les classes d’objecte de les quals forma part una entrada són els atributs permesos per aquesta entrada.

La classe d’objecte es reconeix amb un identificador (OID) i opcionalment el nom (NAME).

L’atribut objectClass pot ser de tres tipus:

  1. objectClass estructural: s’utilitza per crear entrades (objectes de dades). Cada entrada ha de tenir una classe d’aquest tipus i prou.
  2. objectClass auxiliar: es pot afegir a qualsevol entrada. Per exemple, dcObject (que inclou l’atribut dc, domain component, per fer referència a noms DNS).
  3. objectClass abstracta: utilitzada per tractar entitats inexistents.

La classe d’objecte abstracta més comú és top, que constitueix el nivell més alt de les jerarquies d’objecte estructurals. Cal tenir en compte que una entrada només pot tenir una classe d’objecte abstracta.

Herència

Totes les classes d’objectes tenen un origen comú, la classe d’objecte top. També és possible que una classe d’objecte sigui part d’una jerarquia. En aquest cas hereta totes les característiques de les classes d’objecte pare (classes superiors o SUP). En particular cal fer servir tots els atributs obligatoris de les classes superiors, a més dels atributs addicionals necessaris que defineixen la nova classe.

Exemple d'herència a les classes d'objecte

La classe d’objecte inetOrgPerson deriva de la classe d’objecte organizationalPerson, que al seu torn deriva de person, que, a la fi, té el pare top. Per tant, inetOrgPerson inclourà els atributs de les classes d’objecte top, person, organizationalPerson i les que ella mateixa hagi definit.

Si una classe d’objecte és part d’una jerarquia ha de ser del mateix tipus (estructural o auxiliar) que l’objectClass superior. L’excepció a aquesta regla és si el superior és un tipus abstracte (per exemple, top).

Regles de coincidència (matching rules)

Les regles de coincidència defineixen els mètodes de comparació disponibles al servidor LDAP.

En general no cal definir-les de manera explícita, sinó que el servidor ja les inclou per defecte.

Les regles de coincidència es fan servir per a cada atribut mitjançant les propietats opcionals EQUALITY, SUBSTR i ORDERING, a les que s’assigna els seus noms auto-descriptius o el seu OID.

Consulteu el document “Sintaxi de l’esquema” de la secció “Annexos” del material web.

Esquemes (schemas)

Els esquemes són unitats d’embalatge: en general totes les classes d’objecte i atributs estan definits dins dels esquemes. S’ha de considerar que, inicialment, el servidor de directori no coneix cap esquema, de manera que cal carregar-hi els arxius d’esquema que contenen la descripció de les classes d’objecte que el directori ofereix.

Els esquemes següents són d’ús habitual:

  1. core.schema: per a les classes i els atributs bàsics.
  2. cosine.schema: per a algunes extensions útils com es defineix en l’RFC 1274, com ara la identificació d’usuari, el correu…
  3. inetorgperson.schema: útil en alguns casos quan es necessiten més atributs, com s’especifica en l’RFC 2798.

Els esquemes són reutilitzables: la creació d’un objectClass dins d’un nou esquema pot fer servir atributs d’objectClass definits en altres esquemes.

Excepcionalment, hi ha algunes classes d’objecte i atributs definits com a operacionals, que estan implícits en el programari del servidor LDAP i no necessiten un arxiu d’esquema. Aquests afecten totes les entrades d’un servidor i es fan servir a l’entrada “subschema”, localitzable pel valor de l’atribut subschemaSubentry de qualsevol entrada.

Consulteu el document “Sintaxi de l’esquema” de la secció “Annexos” del material web.

Exemple de creació d'una classe d'objecte dins d'un esquema

A continuació es mostra la definició de la classe d’objecte person. Aquesta classe d’objecte està definida en l’esquema core.schema; és, per tant, una classe d’objecte bàsica.

attributetype ( 2.5.4.41 NAME 'name'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

attributetype (2.5.4.3 NAME ( 'cn' 'commonName' ) SUP name )

attributetype (2.5.4.4 NAME ( 'sn' 'surname' ) SUP name )

objectclass ( 2.5.6.6 NAME 'person' SUP top STRUCTURAL
  MUST ( sn $ cn )
  MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
  

dn: uid=jperez,ou=people,dc=exemple,dc=edu
objectclass: top
objectclass: person
cn: José Pérez
sn: Pérez

En fer servir objectclass: person per declarar una entrada, automàticament es requereix que els atributs sn (cognom) i cn (nom comú) continguin un valor, ja que així està establert en la definició de la classe d’objecte. A més, permet l’ús dels atributs userPassword, telephoneNumber, seeAlso i description, però no obliga a assignar-hi un valor.

Informació no textual en directoris LDAP

Tradicionalment s’associen els directoris amb informació de tipus text. Cada implementació ofereix un ventall de possibles tipus de dades. En general n’hi ha de molts tipus diferents, incloses les dades binàries. Però s’han desenvolupat opcions en el cas que calgui incloure informació que no s’ajusti als tipus disponibles (per exemple, mitjançant la codificació Base64).

Base64

Base64 és un sistema de numeració posicional que fa servir 64 com a base. És la major potència de dos que pot ser representada usant únicament els caràcters imprimibles de ASCII i això ha propiciat el seu ús per la codificació de diversos tipus d’informació.

Model de nomenclatura

El model de nomenclatura defineix com s’organitza i es referencia la informació. Les entrades de directori es disposen en una estructura arborescent jeràrquica per tal de reproduir fronteres polítiques, geogràfiques, d’organització o altres criteris.

Com cal esperar, igual que els noms de domini (www.google.com) o la ruta completa d’un fitxer (/etc/passwd), el nom d’una entrada ha de ser únic en cada servidor LDAP.

A diferència d’altres models, en aquest tots els nodes poden tenir contingut.

Nom distintiu (DN)

La posició d’una entrada en la jerarquia del DIT ve determinada pel seu nom complet (DN). Cada component d’un DN es diu nom distintiu relatiu (RDN).

No hi ha normes especifiques sobre com construir aquest nom distintiu, l’única cosa important és que aquest nom ha de ser únic dins de l’espai de noms. És a dir, tots els fills d’una entrada han de tenir RDN diferents. Un RDN pot estar compost per un o més parells atribut/valor. És similar als noms de domini, però el separador és una coma (dn: uid=mfreixas,ou=Personal,dc=empresa,dc=com). També hi poden haver RDN multivalor (dn: cn=Marc Freixas+uid=mfreixas,ou=Personal,dc=empresa,dc=com)

Consulteu el document “Sintaxi del DN” de la secció “Annexos” del material web.

Però en el cas que la entrada serveixi per a la autenticació de l’usuari (operació bind), cal indicar el paràmetre “Bind DN” i opcionalment una contrasenya. Com que no es produeix cap operació de cerca, cal que el “Bind DN” coincideixi amb el DN de creació de l’entrada.

Sufix de directori (directory suffix)

Totes les entrades del directori tenen un node comú (arrel) que es diu sufix del directori o base.

L’LDAP permet construir el sufix del directori amb qualsevol d’aquests tres estils:

  1. L’estil de noms X.500 (el nom de l’organització seguit del codi de país): o=nom_empresa,c=es.
  2. L’estil de DNS. La mateixa entrada ara queda: o=nom_empresa.es.
  3. L’estil de component de domini utilitza l’atribut dc per separar el nom de domini en components dc: dc=nom_empresa,dc=es.

Àlies (alias)

Hi ha situacions en què és útil estalviar-se duplicar la inserció d’una entrada real en el DIT. Es pot crear una entrada àlies, amb un comportament similar al dels enllaços simbòlics (accessos directes) en un sistema de fitxers.

Un àlies pot apuntar fins i tot a un servidor de directori. Com que un àlies erroni pot provocar un desastre, no totes les implementacions de directoris permeten l’ús d’àlies. Si la implementació no permet àlies, pot utilitzar referències.

El procediment de creació és el mateix que s’usa per afegir una nova entrada: amb un DN i classe d’objecte àlies, i només hi ha un atribut necessari, aliasedObjectName, que indica on és l’entrada real.

Exemple de creació d'un àlies

dn: cn=barcelona,dc=empresa,dc=com
objectClass: top
objectClass: alias
objectClass: extensibleObject
cn: barcelona
aliasedObjectName: cn=bcn,dc=empresa,dc=com

Referències (referrals)

Pot arribar un punt en què ja no és pràctic o eficient mantenir l’arbre del directori en un únic servidor. Per motius de rendiment pot interessar fer particions (partitioning), ja que tenir més servidors que ofereixen serveis de directori permet distribuir les peticions dels clients entre aquests servidors. O pot ser interessant per raons administratives, per permetre diferents polítiques per a diferents parts de l’arbre de directoris.

El procediment de creació és el mateix que s’usa per afegir una nova entrada: amb un DN i classe d’objecte referral, i només hi ha un atribut necessari, ref, que indica on resideix l’entrada real amb una URL LDAP.

Exemple on es referencia un subarbre del directori

Un servidor gestiona dc=empresa,dc=com, però un altre servidor, anomenat srvB, conté la informació de dc=bcn,dc=empresa,dc=com:

dn: DC=bcn,DC=exemple,DC=edu
objectClass: referral
objectClass: extensibleObject
dc: bcn
ref: [[ldap://srvB/DC=bcn,DC=exemple,DC=edu|ldap://srvB/dc=bcn,dc=exemple,dc=edu]]

Arrel DSE (rootDSE)

La informació operacional del servidor és en una entrada anomenada arrel DSE. DSE vol dir “entrada DSA específica”. DSA vol dir “agent de servidor de directori” i conté atributs del servidor.

L’entrada “arrel DSE” té un DN de longitud zero i conté:

  1. La versió LDAP compatible amb el servidor. Si el client no aconsegueix recuperar aquesta informació, l’usuari pot concloure que és l’LDAP versió 2, que no és compatible amb aquesta funció.
  2. Totes les classes d’objecte i tipus d’atributs reconeguts pel servidor.
  3. Els sufixos emmagatzemats al servidor de directori.
  4. Les operacions ampliades i els controls compatibles amb el servidor de directori.
  5. Informació sobre els mecanismes de suport SASL.
  6. Una llista de servidors LDAP per consultar la informació que el servidor original no pot proporcionar.

Model funcional

El model funcional defineix com es recupera i modifica la informació del directori, descrivint les operacions que es poden realitzar en l’accés, el manteniment i la gestió del directori.

Hi ha funcions que permeten buscar, comparar, afegir, modificar i esborrar entrades al directori. Totes són atòmiques, és a dir, l’operació s’executa en la seva totalitat o s’avorta si ocorre un error. Acompanyant al paquet d’instal·lació d’un servidor LDAP, s’acostuma a oferir un conjunt de programes per fer servir des de l’intèrpret de línia d’ordres que implementen l’accés a aquestes funcions.

A continuació descrivim les operacions agrupades per funcionalitat, sense aprofundir en la gestió d’errors.

Operacions d'autenticació i control

La primera operació és obrir la connexió amb el servidor (bind); després el client pot proporcionar al servidor les credencials de l’usuari (per exemple, uid i userPassword) per provar la seva identitat. Si el servidor accepta aquestes credencials, associa o “uneix” certs drets d’accés a les credencials d’usuari fins que es tanca la connexió (unbind) o s’envien noves credencials per obtenir drets d’accés diferents.

Connexió (bind)

Permet que el client s’autentiqui al servidor de directori.

Paràmetres:

  1. version: la versió de l’LDAP que el client vol utilitzar.
  2. name: nom de l’objecte de directori al qual el client desitja unir-se (un DN). En cas de referències o àlies no es resoldrà.
  3. authentication: autenticació d’elecció, que té dos valors possibles:
    1. simple: indica que el missatge viatja en text clar.
    2. sasl: utilitza el mecanisme d’autenticació i seguretat de la capa SASL com es descriu en l’RFC 4752.
Desconnexió (unbind)

Allibera els recursos assignats al client, descarta la informació d’autenticació i tanca la connexió. No cal cap paràmetre ni es retorna cap valor.

Abandonar (abandon)

S’informa al servidor que aturi una operació prèviament sol·licitada. El servidor no envia cap resposta.

Paràmetre:

  1. operationID: identificació de l’operació que s’abandona.

Operacions interrogatives

Les operacions interrogatives són les que s’utilitzen tant per buscar com per llegir les entrades. Són les següents:

  1. Cercar (search)
  2. Comparar (compare)
Cercar (search)

Sol·licita a un servidor que retorni el conjunt d’entrades coincidents amb un criteri de cerca complex.

Paràmetres:

  1. baseObject: un DN base per iniciar la recerca.
  2. filter: un filtre que defineix les condicions que ha de complir la cerca perquè coincideixi amb una entrada determinada.
  3. scope: àmbit d’aplicació: en el nivell del DN (baseObject), en un nivell inferior (singleLevel) o en el conjunt del subarbre (wholeSubtree).
  4. Attributes: quins atributs s’han de retornar. Hi ha dos casos especials:
    1. llista buida (sense atributs) o %x2A, és a dir, un asterisc, *. Ambdós valors indiquen que es retornin tots els atributs de les entrades coincidents.
    2. %x31.2E.31, és a dir, 1.1: si és l’únic OID de la llista, no es retorna cap atribut, però sí els DN. Si no és l’únic s’ignora.
  5. derefAliases: indica com s’ha de fer la resolució de les referències:
    1. neverDerefAliases: no resol les referències dels àlies.
    2. derefInSearching: resol la referència d’àlies en les entrades subordinades a l’objecte base en la cerca, però no per localitzar l’objecte base de la cerca.
    3. derefFindingBaseObj: resol la referència d’àlies per localitzar l’objecte base de la cerca, però no en les entrades subordinades a l’objecte base en la cerca.
    4. derefAlways: resol sempre les referències.
  6. sizelimit: el nombre màxim d’entrades a retornar. “zero” significa que el client no imposa cap límit de mida. El servidor pot imposar un límit màxim.
  7. timeLimit: nombre màxim de segons que una consulta pot trigar. “zero” significa que el client no imposa cap límit de temps. El servidor pot imposar un límit màxim.
  8. typesOnly: un valor booleà. Establert a “true” indica que només es retornen els tipus d’atributs. En cas d’estar establert a “false”, retorna els tipus d’atributs i els valors dels atributs.
Comparar (compare)

Permet a un client comparar una afirmació de valor amb els valors d’un atribut en particular en una entrada particular. El resultat és compareTrue en cas positiu, compareFalse en cas negatiu, o algun codi d’error, si no.

Paràmetres:

  1. entry: el nom de l’entrada que s’ha de comparar (un DN). En cas de referències o àlies no es resol.
  2. ava: una afirmació de valor d’un atribut que serà comparada.

Operacions d'actualització

Tot i no ser les més habituals sobre un directori, les operacions d’actualització tenen una gran importància a l’hora de mantenir la correcció de les dades.

Les operacions d’actualització són les següents:

  1. Afegir (add)
  2. Esborrar (delete)
  3. Modificar (modify)
  4. Modificar DN (modify DN)
Afegir (add)

Demana l’addició d’una entrada.

Paràmetres:

  1. entry: nom complet de la nova entrada (un DN). En cas de referències o àlies no es resol.
  2. attributes: una llista de parells nom-valor dels atributs continguts en l’entrada.
Esborrar (delete)

Demana l’eliminació d’una entrada.

Paràmetre:

  1. entry: nom complet de la entrada a eliminar (un DN). En cas de referències o àlies no es resol.
Modificar (modify)

Modifica una entrada.

Paràmetres:

  1. object: nom complet de la entrada a canviar (un DN). En cas de referències o àlies no es resol.
  2. changes: una llista de modificacions a realitzar. Les opcions són:
  3. operation: tipus d’operació que s’executa en aquesta entrada, amb tres valors possibles:
  4. add: afegeix un nou atribut.
  5. delete: elimina un atribut.
  6. replace: modifica un atribut.
  7. modification: una llista de parelles nom-valor que s’afegeix o modifica.
Modificar DN (modify DN)

Canvia l’RDN d’una entrada o passa un subarbre d’entrades a una nova ubicació al directori (vegeu la figura).

Figura Modificació del DN

Paràmetres:

  1. entry: nom complet de la entrada a canviar (un DN). En cas de referències o àlies no es resol. En l’exemple és uid=empleat_2,ou=departament5,ou=empleats, dc=exemple,dc=edu.
  2. newrdn: nou nom complet relatiu (un RDN). En l’exemple és uid=empleat_2.
  3. deleteoldrdn: valor booleà que indica si l’RDN vell s’ha de mantenir en el directori.
  4. newSuperior: és un paràmetre opcional que indica quin serà el superior immediat d’entry. En cas de referències o àlies no es resol. En l’exemple és ou=departament1,ou=empleats, dc=exemple,dc=edu.

Operacions ampliades

Les operacions ampliades es poden utilitzar per definir les noves operacions que no eren part de l’especificació del protocol original.

L’operació estesa més habitual és StartTLS.

StartTLS

L’operació StartTLS (definida a l’RFC 2830) permet a un client sol·licitar una connexió de tipus Transport Layer Security (el descendent d’SSL) mitjançant la transmissió d’una petició ampliada (ExtendedRequest, LDAPv3). Si el servidor és capaç i està en disposició de negociar TLS, el client ha de començar la negociació TLS (RFC 5246) o tallar la connexió. En la figura es mostren les capes de seguretat en una sessió LDAP.

Figura Capes de seguretat SASL i TLS en una sessió LDAP

Model de seguretat

El model de seguretat mostra com es controla l’accés a la informació continguda en el directori.

Abans que un client pugui accedir a les dades d’un servidor LDAP, s’han de dur a terme dos processos: autenticació i autorització.

El model de seguretat (RFC 4513) descriu aquests processos juntament amb la integritat i confidencialitat en la transmissió de dades o la limitació en l’ús de recursos.

Autenticació

L’autenticació és el procés que assegura que les identitats dels usuaris i màquines (servidors o clients) estan correctament validades.

Normalment, la seva funció es redueix a verificar la identitat de l’usuari abans de permetre-li l’accés al sistema. Aquest control permet definir el nivell d’accés de cada usuari i objecte del directori.

Els serveis de directori s’utilitzen habitualment com a eines d’autenticació que emmagatzemen credencials de manera centralitzada, no només contrasenyes per autenticar els usuaris del mateix directori, sinó també mecanismes per verificar contrasenyes que autentiquin usuaris d’altres sistemes. Tanmateix, el protocol no imposa que les contrasenyes associades amb un usuari estiguin al servidor, sinó que permet que s’integrin amb serveis d’autenticació externs (per exemple, SASL).

Autenticació anònima

Tots els servidors LDAP han d’acceptar el tipus d’autenticació “sense autenticació en absolut”, també anomenat usuaris anònims, ja que el servidor no sap qui està demanant una connexió. Aquest tipus d’autenticació té associada una autorització de tipus anònima.

S’aconsegueix escollint la opció d’autenticació simple a bind, però sense proporcionar credencials d’usuari al servidor.

Connexió no autenticada

Una connexió no autenticada dóna lloc a una autorització anònima, però la identificació facilita la traçabilitat de la connexió.

S’aconsegueix escollint la opció d’autenticació simple a bind, però sense proporcionar cap contrasenya al servidor.

Autenticació bàsica

L’autenticació bàsica també s’utilitza en altres protocols com HTTP. El client simplement envia les credencials d’usuari per la xarxa en format clar.

S’aconsegueix escollint l’opció d’autenticació simple a bind, proporcionant nom distintiu i contrasenya al servidor. El servidor busca un atribut anomenat userPassword en l’entrada corresponent al nom distintiu i el compara amb l’entrada enviada pel client. Si la contrasenya coincideix, s’estableix la connexió amb el servidor LDAP. Si no, s’envia un missatge d’error i es tanca la connexió.

SASL

És el mètode recomanat pel protocol LDAP. SASL Separa els mecanismes d’autenticació dels protocols de l’aplicació, permetent que qualsevol protocol d’aplicació que faci servir SASL utilitzi qualsevol mecanisme d’autenticació suportat per SASL (RFC 4422 i 4752). La capa d’autenticació i seguretat (SASL) proporciona serveis d’autenticació a un protocol orientat a la connexió, com el LADP. Un cop el servidor i el client estan connectats, estableixen un acord sobre el mecanisme de seguretat.

Els clients poden determinar els mecanismes SASL que un servidor admet llegint l’atribut supportedSASLMechanisms des de l’arrel DSE.

A més de l’autenticació, ofereix seguretat de dades (integritat i confidencialitat).

Alguns mecanismes d’autenticació definits per SASL són:

  • EXTERNAL (per exemple, IPSec o TLS)
  • ANONYMOUS
  • PLAIN (text clar)
  • OTP (One Time Password)
  • SKEY
  • CRAM-MD5
  • DIGEST-MD5
  • NTLM
  • GSSAPI
  • GATEKEEPER
Contrasenyes

El protocol LDAP (RFC 4519) ofereix userPassword, un tipus d’atribut multivalor definit per donar suport a l’operació bind amb autenticació simple i accessible únicament pel propi usuari. En ser multivalor, per validar l’usuari es prova la contrasenya candidata amb cada valor (útil en períodes de transició). Aquest atribut apareix en classes d’objecte com organizationalUnit o person i a la seva definició es diu que s’emmagatzema com a text clar.

Algunes implementacions aprofiten el text clar per fer ús de més tipus de mecanismes d’autenticació, fent servir una funció resum (one-way hash) i guardant el resultat codificat en Base64.

L’RFC 3112 oficialitza aquesta pràctica i defineix l’authentication password schema per guardar valors derivats de les contrasenyes de l’usuari amb un nou tipus d’atribut, authPassword, que permet esquemes d’emmagatzemament múltiple i regles de coincidència per validar que una contrasenya en text clar coincideix amb un dels valors de l’atribut. Aquest atribut apareix a classes d’objecte com posixAccount, posixGroup o shadowAccount. Els clients poden determinar els esquemes que un servidor suporta llegint l’atribut supportedAuthPasswordSchemes des de l’arrel DSE (per exemple, BASE64, CLEAR, CRYPT, MD5, SHA, SMD5, SSHA, SSHA256, SSHA384, SSHA512 o SASL).

Per exemple, si la contrasenya és abcd123:

abcd123 xifrat amb SHA = fDYHuOYbzxlE6ehQOmYPIfS28/E=
userPassword: {SHA}fDYHuOYbzxlE6ehQOmYPIfS28/E=

{SHA}fDYHuOYbzxlE6ehQOmYPIfS28/E= codificat en Base64 = e1NIQX1mRFlIdU9ZYnp4bEU2ZWhRT21ZUElmUzI4L0U9

authPassword:: e1NIQX1mRFlIdU9ZYnp4bEU2ZWhRT21ZUElmUzI4L0U9

La creació d’atributs nous en esquemes personalitzats per guardar contrasenyes no es considera una bona pràctica.

En cap cas no és convenient fer la transferència de la contrasenya ni del hash. Per això és important saber que si no s’utilitza SSL/TLS o SASL amb algorisme de negociació segur el client LDAP enviarà les credencials amb text clar i serà el servidor qui calcularà el valor de hash i el compararà amb el valor emmagatzemat.

D’altra banda, és important crear una política de contrasenyes, encara que la seva implementació i compliment no sigui fàcil (implica que els usuaris canviïn les seves contrasenyes periòdicament, requisits de construcció de les contrasenyes, restringir la reutilització d’una contrasenya vella, impedir els atacs d’endevinació de contrasenyes…).

Consulteu l’adreça web “Model de polítiques de contrasenyes” a la secció “Adreces d’interès” del material web per accedir a la desena versió d’un Internet draft que recull un conjunt de regles que controla com s’utilitzen i administren les contrasenyes en un servei de directori basat en l’LDAP.

Internet draft

Internet draft són esborranys vàlids per a un màxim de sis mesos que poden ser actualitzats o reemplaçats per altres documents o esdevenir obsolets en qualsevol moment. No és apropiat l’ús d’Internet drafts com a material de referència ni citar-los d’altra manera que com a “treballs en curs”.

La classe d’objecte pwdPolicy es defineix amb atributs que mantenen la informació de l’estat de la directiva de contrasenyes general per a cada usuari. La seva declaració és:

( 1.3.6.1.4.1.42.2.27.8.2.1
NAME 'pwdPolicy'
SUP top
AUXILIARY
MUST ( pwdAttribute )
MAY ( pwdMinAge $ pwdMaxAge $ pwdInHistory $ pwdCheckQuality $
pwdMinLength $ pwdMaxLength $ pwdExpireWarning $
pwdGraceAuthNLimit $ pwdGraceExpiry $ pwdLockout $
pwdLockoutDuration $ pwdMaxFailure $ pwdFailureCountInterval $
pwdMustChange $ pwdAllowUserChange $ pwdSafeModify $
pwdMinDelay $ pwdMaxDelay $ pwdMaxIdle ) )

pwdAttribute és el nom de l’atribut al qual s’aplica la directiva (per exemple, userPassword). Es recomana exigir un nivell de qualitat de les contrasenyes, canvis periòdics i bloqueig (temporal o no) de comptes en superar el límit d’intents.

Autorització i control d'accés

Una política de control d’accés és un conjunt de regles que defineixen la protecció dels recursos en termes de les capacitats de les persones o entitats que accedeixen a aquests recursos.

La sol·licitud pot estar associada a una àmplia varietat de factors de control d’accés (ACFs), per exemple, l’adreça IP d’origen, el nivell de xifrat, el tipus d’operació que se sol·licita, l’hora del dia…

Cada sessió LDAP té associat un estat d’autenticació vinculat a una identitat d’autorització.

L’autenticació anònima i la connexió no autenticada comporten un estat d’autorització anònima, mentre que una autenticació bàsica comporta un estat d’autorització autenticada. SASL permet, opcionalment, que el client comuniqui la identitat d’autorització desitjada.

Cada implementació estableix els seus propis mecanismes d’administració i emmagatzemament. L’RFC 2820 descriu els requeriments de control d’accés, però no en facilita la implementació, cosa que dificulta la interoperabilitat en aquest aspecte.

El control d’accés es gestiona normalment en forma de llistes de control d’accés (ACL). Així, les polítiques de control d’accés sovint s’expressen en termes d’identitats d’autorització: “L’entitat X pot realitzar l’operació Y del recurs Z”.

Consulteu el document “Sintaxi de configuració dinàmica del control d’accés a l’OpenLDAP” de la secció “Annexos” del material web.

Per exemple:

access to * by * read

access to *
    by self write
    by anonymous auth
    by * read

olcAccess: to *
    by users read

Privacitat i integritat de les dades

És important assegurar que les dades no es modifiquen ni es donen a conèixer durant la seva transmissió.

L'LDAP amb SSL/TLS

El protocol SSL (Secure Sockets Layer) implementa mecanismes de seguretat basats en criptografia de clau pública a la pila de protocols TCP/IP entre la capa de transport i la capa d’aplicació, és a dir, la capa LDAP.

TLS proporciona un mecanisme de seguretat que permet l’autenticació mútua del servidor i el client, la negociació segura i fiable del protocol d’encriptació i les claus criptogràfiques, tot això abans que el protocol d’aplicació (LDAP) envii o rebi el seu primer byte de dades.

L’LDAP li dóna suport mitjançant l’operació ampliada StartTLS i, opcionalment, ofereix autenticació quan es combina amb SASL EXTERNAL.

El protocol TLS 1

Transport Layer Security va néixer a partir de la versió 3 de l’SSL per oferir confidencialitat i integritat a la comunicació entre dues aplicacions. Es descriu als RFC 5246, 5746, 5878 i 6176. Les característiques del TLS, ordenades per prioritats del disseny, són: seguretat criptogràfica, interoperabilitat, extensibilitat i eficiència.

SASL

Aquest tipus de connexió ja s’ha presentat com a opció d’autenticació.

El client sol·licita una connexió segura mitjançant l’operació ampliada StartTLS. Si el servidor respon que està llest per negociar amb el protocol TLS Handshake de TLS, primer es posen d’acord en la versió del TLS i després en el mecanisme de seguretat que s’utilitzarà per a la comunicació. Ambdues parts decideixen si accepten o no el nivell de seguretat assolit. Si el servidor o el client decideixen que el nivell no és suficient, es tanca la connexió (TLS).

Protecció contra la monopolització

Per tal de garantir la disponibilitat del servei, cal limitar l’ús de recursos per evitar que un únic usuari monopolitzi el sistema.

L’LDAP ofereix límits d’autocontrol en la mida del resultat o temps d’algunes operacions. D’altra banda, l’estàndard recomana definir límits administratius mitjançant els controls de servei per tal de protegir el servidor, però no ho concreta, de manera que cada implementació ha desenvolupat la seva pròpia solució.

El format d'intercanvi de dades LDIF

L’LDIF (LDAP Data Interchange Format o format d’intercanvi de dades LDAP) és un estàndard de format de text pla utilitzat per representar el contingut d’un directori LDAP i les sol·licituds d’actualització del directori (afegir una entrada, modificar-la, eliminar-la…).

Podem crear fitxers de text pla amb format LDIF per representar la informació que conté un directori i també es poden fer servir per modificar el contingut del directori.

LDIF representa el contingut d’un directori amb una sèrie de registres, cadascun dels quals representa una entrada del directori. De la mateixa manera, una sol·licitud d’actualització del directori (adició, modificació, eliminació) es representa també com un registre (de fet, hi haurà un registre per a cada sol·licitud).

L’ús d’un fitxer de text pla és molt útil. En primer lloc és autoexplicatiu, fàcil de llegir i d’entendre. A més, és molt fàcil de produir o processar utilitzant scripts o algun llenguatge de programació. D’altra banda, com que la compatibilitat entre les diferents implementacions de servei de directori no està garantida, sempre es poden fer servir els fitxers en aquest format per transportar informació d’un servei de directori a un altre, és a dir, per importar i exportar informació entre servidors LDAP.

Format d'un fitxer LDIF

El format de fitxer LDIF està definit a l’RFC 2849.

Els fitxers LDIF estan formats per un conjunt de línies de diversos tipus. Els tipus de línies que es distingeixen són els següents:

  • Línia de directiva: una línia que comença amb qualsevol caràcter, excepte espai o coixinet. Aquestes són les línies realment importants, ja que contenen la informació de les entrades i les operacions a realitzar.
  • Línia en blanc: les línies en blanc s’utilitzen normalment per separar les diferents seqüències d’entrada.
  • Línia de comentari: una línia que comença amb un coixinet.
  • Línia de continuació: una línia que segueix una línia de directiva i comença amb un espai. Se suposa que els caràcters següents són part de la línia anterior.
  • Línia de separació: una línia que comença amb un guió (). Les línies de separació són utilitzades típicament per acabar les seqüències d’operador.

Els fitxers LDIF són molt sensibles als espais i les línies en blanc. S’ha de ser molt respectuós amb la sintaxi del format.

S’anomena seqüència a l’agrupació de directivesseparades per una o més línies en blanc. Existeixen dos tipus de seqüències: d’entrada i d’operador.

Seqüència d'entrada

Les seqüències d’entrada defineixen una entrada del directori. Són un grup de directives que comencen amb una directiva DN (nom distintiu), seguida d’altres directives que descriuen els diferents atributs d’una entrada al DIT. Les seqüències d’entrada sempre comencen amb la directiva DN i acaben amb una línia en blanc.

Exemple de seqüència d'entrada

dn: ou=Persones, dc=empresa,dc=com
ou: Persones
objectClass: organizationalUnit

L’exemple mostra una entrada del directori, concretament una unitat organitzativa. Inclou tresdirectives: la primera defineix el DN i les altres dues descriuen diferents atributs de l’entrada o objecte. Especifiquen que l’objecte és una unitat organitzativa i donen valor a l’atribut ou.

Seqüència d'operador

Una seqüència d’operador és un grup de directives que inclou la directivachangetype. Una seqüència d’operador acaba amb una línia de separació o una línia en blanc.

La directiva changetype admet com a valors:

  • add: afegeix entrades.
  • delete: elimina entrades.
  • modify: modifica entrades, però cal especificar quin atribut volem modificar i quina és la modificació que cal realitzar. Aquestes modificacions poden ser add, delete o replace. Per fer diverses modificacions en una entrada es fa servir el separador -.

Exemple de seqüència d'operador changetype: modify

dn: cn=Marc Freixas,ou=Persones,dc=empresa,dc=com 
changetype: modify 
add: work-phone 
work-phone: 931234561 
work-phone: 931234562 
- 
delete: home-fax 
- 
replace: home-phone 
home-phone: 415/697-8899

En l’exemple es modifica l’entrada “Marc Freixas”. S’hi han afegit dos telèfons de la feina, s’ha esborrat el fax del domicili i s’ha modificat el telèfon particular. Es pot observar com desprès del DN apareix la directiva changetype. Com que hi ha més d’una modificació, cada modificació se separa de la següent mitjançant un guionet (-).

  • modrdn: modifica el DN relatiu, és a dir, sense canviar la base. Cal fer servir la directiva newrdnper definir el nou DN. Es pot decidir si es vol mantenir o eliminar l’antic DN amb la directiva deleteoldrdn.

Exemple de directiva modrdn

dn: cn=Marc Freixas,ou=people,dc=example,dc=com
changetype: modrdn
newrdn: Marc Freixas Vila
# deletes old RDN entry
deleteoldrdn: 1

En l’exemple s’ha canviat el nom de la persona de “Marc Freixas” a “Marc Freixas Vila” i s’ha esborrat l’anterior DN.

  • moddn: modifica el DN complet. Això implica moure l’objecte a un altre node del DIT. S’ha d’especificar el nou pare de l’objecte amb la directiva newsuperior. Opcionalment, es pot mantenir o esborrar l’entrada anterior amb la directiva deleteoldrdn.

Exemple de directiva moddn

dn: cn=Marc Freixas,ou=Persones,dc=empresa,dc=com
changetype: moddn
newsuperior: ou=exempleats,dc=empresa,dc=com
# Mantenim l'anterior entrada RDN
deleteoldrdn: 0

En l’exemple, Marc Freixas ha passat a tenir com a nou DN “cn=Marc Freixas,ou=exempleats,dc=empresa,dc=com”.

Anar a la pàgina anterior:
Referències
Anar a la pàgina següent:
Activitats