LDIF est un format de fichier très répandu qui décrit des informations de répertoire ou des opérations de modification pouvant être réalisées sur un répertoire. LDIF est totalement indépendant du format de stockage utilisé au sein d'une implémentation de répertoire spécifique, et est typiquement utilisé pour exporter des informations de répertoire depuis des serveurs LDAP et pour importer des données vers des serveurs LDAP.
D'une façon générale, la génération de LDIF est simple. Elle vous permet d'utiliser des outils, tels que awk ou perl, pour déplacer des données d'un format propriétaire dans un répertoire LDAP. Vous pouvez également écrire des scripts permettant de générer des données de test au format LDIF.
L'utilitaire d'importation/de conversion/d'exportation NetIQ requiert des fichiers au format LDIF 1. Voici les règles de base applicables à un fichier LDIF 1 :
La première ligne (autre qu'un commentaire) doit correspondre à la version 1.
Une série d'un ou de plusieurs enregistrements suit la version.
Chaque enregistrement se compose de champs (un champ par ligne).
Les lignes sont séparées par un saut de ligne ou par une paire retour chariot/saut de ligne.
Les enregistrements sont séparés par au moins une ligne vide.
Il existe deux types d'enregistrements LDIF : enregistrements de contenu et enregistrements de modification. Un fichier LDIF peut comporter un nombre illimité d'enregistrements, mais ceux-ci doivent tous être du même type. Vous ne pouvez pas mélanger des enregistrements de contenu et des enregistrements de changement dans le même fichier LDIF.
Toute ligne commençant par le signe dièse (#) est un commentaire et est par conséquent ignorée lors du traitement du fichier LDIF.
Un enregistrement de contenu LDIF représente le contenu de l'ensemble d'une entrée. L'exemple de fichier LDIF ci‑après comprend quatre enregistrements de contenu :
1 version: 1 2 dn: c=US 3 objectClass: top 4 objectClass: country 5 6 dn: l=San Francisco, c=US 7 objectClass: top 8 objectClass: locality 9 st: San Francisco 10 11 dn: ou=Artists, l=San Francisco, c=US 12 objectClass: top 13 objectClass: organizationalUnit 14 telephoneNumber: +1 415 555 0000 15 16 dn: cn=Peter Michaels, ou=Artists, l=San Francisco, c=US 17 sn: Michaels 18 givenname: Peter 19 objectClass: top 20 objectClass: person 21 objectClass: organizationalPerson 22 objectClass: iNetOrgPerson 23 telephonenumber: +1 415 555 0001 24 mail: Peter.Michaels@aaa.com 25 userpassword: Peter123 26
Ce fichier LDIF comprend les parties suivantes :
|
Composant |
Description |
|---|---|
|
Spécificateur de version |
La première ligne d'un fichier LDIF comporte la version. Vous pouvez ajouter ou non des espaces entre les deux points et le numéro de version, actuellement défini sur 1. Si la ligne de version est manquante, toute application traitant le fichier LDIF peut supposer que le fichier est de version 0. Il est aussi possible que le fichier LDIF soit rejeté comme étant syntaxiquement incorrect. Les utilitaires NetIQ traitant les fichiers LDIF considèrent que le fichier est de la version 0 en cas d'absence de la ligne de version. |
|
Spécificateur de nom distinctif |
La première ligne de chaque enregistrement de contenu (lignes 2, 6, 11 et 16 de l'exemple précédent) spécifie le DN de l'entrée qu'il représente. Le spécificateur de DN doit revêtir l'une des deux formes suivantes :
|
|
Séparateurs de lignes |
Le séparateur de ligne peut être un saut de ligne ou une paire retour chariot/saut de ligne. Cela permet de résoudre une incompatibilité fréquente entre fichiers texte Linux et Solaris, qui utilisent un saut de ligne comme séparateur de ligne, et fichiers texte MS-DOS* et Windows, qui pour ce faire utilisent une paire retour chariot/saut de ligne. |
|
Séparateurs d'enregistrements |
Les lignes vides (lignes 5, 10, 15 et 26 de l'exemple précédent) sont utilisées comme séparateurs d'enregistrements. Chaque enregistrement d'un fichier LDIF, y compris le dernier, doit se terminer par un séparateur d'enregistrement (une ou plusieurs lignes vides). Si certaines implémentations acceptent un fichier LDIF sans séparateur d'enregistrement final, il est impératif pour la spécification LDIF. |
|
Spécificateur de valeur d'attribut |
Toutes les autres lignes d'un enregistrement de contenu sont des spécificateurs de valeurs. Les spécificateurs de valeurs doivent revêtir l'une des trois formes suivantes :
|
Les enregistrements de changement LDIF comportent les modifications à apporter à un répertoire. Toutes les opérations de mise à jour LDAP (add, delete, modify et modify DN) peuvent être représentées dans un enregistrement de changement LDIF.
Les enregistrements de changement LDIF utilisent pour le spécificateur de nom distinctif, le spécificateur de valeur d'attribut et le séparateur d'enregistrement le même format que les enregistrements de contenu LDIF. (Reportez-vous à l'Enregistrements de contenu LDIF pour plus d'informations.) La présence d'un champ changetype est ce qui différencie un enregistrement de changement LDIF d'un enregistrement de contenu LDIF. Le champ changetype identifie l'opération spécifiée par l'enregistrement de changement.
Le champ changetype peut revêtir l'une des cinq formes suivantes :
|
Formulaire |
Description |
|---|---|
|
changetype:ajout |
Mot-clé indiquant que l'enregistrement de changement spécifie une opération LDAP d'ajout. |
|
changetype:suppression |
Mot-clé indiquant que l'enregistrement de changement spécifie une opération LDAP de suppression. |
|
changetype: moddn |
Mot‑clé indiquant que l'enregistrement de changement spécifie une opération LDAP de modification du DN si le processeur LDIF est lié au serveur LDAP en tant que client version 3 ou une opération de modification du RDN si le processeur LDIF est lié au serveur LDAP en tant que client version 2. |
|
changetype: modrdn |
Synonyme du type de changement moddn. |
|
changetype:modification |
Mot-clé indiquant que l'enregistrement de changement spécifie une opération LDAP de modification. |
Un enregistrement de changement de type add ressemble à un enregistrement de changement de contenu (voir Enregistrements de contenu LDIF) ; le champ changetype: add figure immédiatement avant les champs de valeur d'attribut.
Tous les enregistrements doivent être de même type. Vous ne pouvez pas mélanger des enregistrements de contenu et des enregistrements de changement.
1 version: 1 2 dn: c=US 3 changetype: add 4 objectClass: top 5 objectClass: country 6 7 dn: l=San Francisco, c=US 8 changetype: add 9 objectClass: top 10 objectClass: locality 11 st: San Francisco 12 14 dn: ou=Artists, l=San Francisco, c=US 15 changetype: add 16 objectClass: top 17 objectClass: organizationalUnit 18 telephoneNumber: +1 415 555 0000 19 20 dn: cn=Peter Michaels, ou=Artists, l=San Francisco, c=US 21 changetype: add 22 sn: Michaels 23 givenname: Peter 24 objectClass: top 25 objectClass: person 26 objectClass: organizationalPerson 27 objectClass: iNetOrgPerson 28 telephonenumber: +1 415 555 0001 29 mail: Peter.Michaels@aaa.com 30 userpassword: Peter123 31
Étant donné qu'un enregistrement de changement de type delete indique la suppression d'une entrée, les seuls champs nécessaires à ce type d'enregistrement sont le spécificateur de nom distinctif et le changement de type delete.
L'exemple de fichier LDIF suivant est utilisé pour supprimer les quatre entrées créées par le fichier LDIF présenté dans Changement de type add.
IMPORTANT :Pour supprimer des entrées précédemment ajoutées, inversez l'ordre des entrées. Si vous n'effectuez pas cette opération, la suppression échoue, car les entrées de conteneur ne sont pas vides.
1 version: 1 2 dn: cn=Peter Michaels, ou=Artists, l=San Francisco, c=US 3 changetype: delete 4 5 dn: ou=Artists, l=San Francisco, c=US 8 changetype: delete 9 10 dn: l=San Francisco, c=US 11 changetype: delete 12 13 dn: c=US 14 changetype: delete 15
Le changement de type modify permet de spécifier l'ajout, la suppression et le remplacement de valeurs d'attribut pour une entrée déjà existante. Les modifications revêtent l'une des trois formes suivantes :
|
Élément |
Description |
|---|---|
|
add: type d'attribut |
Mot-clé indiquant que les spécificateurs de valeur d'attribut suivants correspondant au type d'attribut doivent être ajoutés à l'entrée. |
|
delete: attribute type |
Mot-clé indiquant que les valeurs correspondant au type d'attribut doivent être supprimées. Si des spécificateurs de valeur d'attribut suivent le champ delete, les valeurs correspondantes sont supprimées. Si aucun spécificateur de valeur d'attribut ne suit le champ delete, toutes les valeurs sont supprimées. Si aucune valeur n'est associée à l'attribut, cette opération échoue, mais l'effet désiré est quand même obtenu, étant donné que l'attribut n'est associé à aucune valeur à supprimer. |
|
replace: attribute type |
Mot-clé indiquant que les valeurs correspondant au type d'attribut doivent être remplacées. Tous les spécificateurs de valeur d'attribut qui suivent le champ replace deviennent les nouvelles valeurs de ce type d'attribut. Si aucun spécificateur de valeur d'attribut ne suit le champ replace, le jeu de valeurs actuel est remplacé par un jeu de valeurs vide (ce qui entraîne le retrait de l'attribut). À la différence du spécificateur de modification delete, si aucune valeur n'est associée à l'attribut, le remplacement réussira tout de même. L'effet net est le même dans les deux cas. |
L'exemple suivant illustre un changement de type modify qui permet d'ajouter un numéro de téléphone supplémentaire à l'entrée cn=Peter Michaels.
1 version: 1 2 dn: cn=Peter Michaels, ou=Artists, l=San Francisco, c=US 3 changetype: modify 4 # add the telephone number to cn=Peter Michaels 4 add: telephonenumber 5 telephonenumber: +1 415 555 0002 6
De même que vous pouvez combiner un mélange de modifications dans une requête de modification LDAP unique, vous pouvez spécifier plusieurs modifications dans un enregistrement LDIF unique. Une ligne contenant uniquement le caractère tiret (-) est utilisée pour marquer la fin des indications de valeur d'attribut pour chaque spécificateur de modification.
Le fichier LDIF exemple suivant comprend un mélange de modifications :
1 version: 1 2 3 # An empty line to demonstrate that one or more 4 # line separators between the version identifier 5 # and the first record is legal. 6 7 dn: cn=Peter Michaels, ou=Artists, l=San Francisco, c=US 8 changetype: modify 9 # Add an additional telephone number value. 10 add: telephonenumber 11 telephonenumber: +1 415 555 0002 12 - 13 # Delete the entire fascimiletelephonenumber attribute. 14 delete: facsimileTelephoneNumber 15 - 16 # Replace the existing description (if any exists) 17 # with two new values. 18 replace: description 19 description: guitar player 20 description: solo performer 21 - 22 # Delete a specific value from the telephonenumber 23 # attribute. 24 delete: telephonenumber 25 telephonenumber: +1 415 555 0001 26 - 27 # Replace the existing title attribute with an empty 28 # set of values, thereby causing the title attribute to 29 # be removed. 30 replace: title 31 - 32
Le changement de type modify DN permet de renommer une entrée, de la déplacer, ou d'effectuer les deux opérations. Ce type de changement se compose de deux champs obligatoires et d'un champ facultatif.
|
Champ |
Description |
|---|---|
|
newrdn (obligatoire) |
Indique le nouveau nom de l'entrée qui sera assignée lors du traitement de cet enregistrement. Le spécificateur « new RDN » doit revêtir l'une des deux formes suivantes :
Le spécificateur « new RDN » est obligatoire dans tous les enregistrements LDIF comportant un changement de type modify DN. |
|
deleteoldrdn (obligatoire) |
Le spécificateur delete « old RDN » spécifie si l'ancien RDN doit être remplacé par la valeur newrdn ou s'il doit être conservé. Il revêt l'une des deux formes suivantes :
|
|
newsuperior (facultatif) |
Le spécificateur « new superior » indique le nom du nouveau parent qui sera assigné à l'entrée lors du traitement de l'enregistrement modify DN. Le spécificateur new « superior » doit revêtir l'une des deux formes suivantes :
Le spécificateur « new superior » est facultatif dans les enregistrements LDIF comportant un changement de type modify DN. Il n'est fourni que si vous souhaitez attribuer un autre parent à l'entrée. |
L'exemple suivant illustre un changement de type modify DN et montre comment renommer une entrée :
1 version: 1 2 3 # Rename ou=Artists to ou=West Coast Artists, and leave 4 # its old RDN value. 5 dn: ou=Artists,l=San Francisco,c=US 6 changetype: moddn 7 newrdn: ou=West Coast Artists 8 deleteoldrdn: 1 9
L'exemple suivant illustre un changement de type modify DN et montre comment déplacer une entrée :
1 version: 1 2 3 # Move cn=Peter Michaels from 4 # ou=Artists,l=San Francisco,c=US to 5 # ou=Promotion,l=New York,c=US and delete the old RDN. 5 dn: cn=Peter Michaels,ou=Artists,l=San Francisco,c=US 6 changetype: moddn 7 newrdn: cn=Peter Michaels 8 deleteoldrdn: 1 9 newsuperior: ou=Promotion,l=New York,c=US 10
L'exemple suivant illustre un changement de type modify DN et montre comment déplacer une entrée et la renommer en même temps :
1 version: 1 2 3 # Move ou=Promotion from l=New York,c=US to 4 # l=San Francisco,c=US and rename it to 5 # ou=National Promotion. 5 dn: ou=Promotion,l=New York,c=US 6 changetype: moddn 7 newrdn: ou=National Promotion 8 deleteoldrdn: 1 9 newsuperior: l=San Francisco,c=US 10
IMPORTANT :L'opération de modification RDN de LDAP 2 ne prend pas en charge le déplacement des entrées. Si vous tentez de déplacer une entrée en utilisant la syntaxe LDIF newsuperior avec un client LDAP 2, la requête échoue.
Pour retourner à la ligne dans un fichier LDIF, il suffit d'insérer un séparateur de ligne (saut de ligne ou paire retour chariot/saut de ligne), suivi d'un espace à l'emplacement auquel vous souhaitez retourner à la ligne. Lorsque l'analyseur syntaxique LDIF rencontre un espace en début de ligne, il sait concaténer le reste des données de la ligne avec les données de la ligne précédente. Il supprime alors l'espace en tête.
Vous ne devez pas aller à la ligne au milieu d'un caractère multi-octets UTF-8.
L'exemple de fichier LDIF suivant illustre une ligne avec retour à la ligne (voir lignes 13 et 14) :
1 version: 1 2 dn: cn=Peter Michaels, ou=Artists, l=San Francisco, c=US 3 sn: Michaels 4 givenname: Peter 5 objectClass: top 6 objectClass: person 7 objectClass: organizationalPerson 8 objectClass: iNetOrgPerson 9 telephonenumber: +1 415 555 0001 10 mail: Peter.Michaels@aaa.com 11 userpassword: Peter123 12 description: Peter is one of the most popular music 13 ians recording on our label. He’s a big concert dr 14 aw, and his fans adore him. 15
Un mot de passe codé est représenté sous la forme de données au format base64 dans le fichier LDIF. Le nom d'attribut userpassword doit être suivi du nom du codage utilisé pour le hachage du mot de passe. Ce nom doit être précédé et suivi d'accolades (« { » et « } »), comme l'illustrent les exemples suivants :
Pour les mots de passe codés SHA :
1 version: 1 2 dn: cn=Peter Michaels, ou=Artists, l=San Francisco, c=US 3 sn: Michaels 4 userpassword: {SHA}xcbdh46ngh37jsd0naSFDedjAS30dm5 objectclass: inetOrgPerson
Pour les mots de passe codés SSHA :
1 version: 1 2 dn: cn=Peter Michaels, ou=Artists, l=San Francisco, c=US 3 sn: Michaels 4 userpassword: {SSHA}sGs948DFGkakdfkasdDF34DF4dS3skl5DFS5 objectclass: inetOrgPerson
Pour les mots de passe codés Digest MD5 :
1 version: 1 2 dn: cn=Peter Michaels, ou=Artists, l=San Francisco, c=US 3 sn: Michaels 4 userpassword: {MD5}a45lkSDF234SDFG62dsfsf2DG2QEvgdmnk4305 objectclass: inetOrgPerson