7.5 Fichiers LDIF

Format de fichier 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 :

Enregistrements de contenu 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 :

Enregistrements de changement LDIF

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 à la section 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 :

 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

 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

 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

 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

 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

 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

 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

Retour à la ligne dans les fichiers LDIF

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

Représentation du mot de passe haché dans les fichiers LDIF

Un mot de passe haché est représenté au format de données 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 :

Exemple 1

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

Exemple 2

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

Exemple 3

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

Activation des références en aval

Il peut arriver de rencontrer des fichiers LDIF dans lesquels un enregistrement permettant d'ajouter une entrée se trouve avant l'enregistrement permettant d'ajouter ses parents. Le cas échéant, une erreur est générée car le parent de la nouvelle entrée n'existe pas au moment où le serveur LDAP tente d'ajouter l'entrée.

Pour résoudre ce problème, il suffit d'activer l'utilisation de références en aval. Lorsque vous activez la création de références en aval et qu'une entrée va être créée alors que son parent n'existe pas encore, une marque de réservation appelée référence en aval est créée pour le parent de l'entrée afin de permettre la création de l'entrée. Si une opération ultérieure crée le parent, la référence en aval se transforme en entrée normale.

Il est possible qu'il reste une ou plusieurs références en aval une fois l'importation LDIF terminée (si le fichier LDIF n'a, par exemple, jamais créé de parent pour cette entrée). Dans ce cas, la référence en aval apparaît en tant qu'objet Inconnu dans iManager. Vous pouvez certes effectuer une recherche sur une entrée de référence en aval, mais vous ne pouvez pas lire les attributs (à l'exception de l'attribut objectClass) depuis l'entrée de référence en aval car elle n'est associée à aucun attribut et à aucune valeur d'attribut. Cependant, toutes les opérations LDAP fonctionnent normalement sur les entrées d'objet situées sous la référence en aval.

Contrôle de la syntaxe des fichiers LDIF

Vous pouvez vérifier la syntaxe d'un fichier LDIF avant de traiter les enregistrements qu'il contient en utilisant l'option du gestionnaire source LDIF Afficher les opérations sans les exécuter.

Le gestionnaire de source LDIF vérifie systématiquement la syntaxe des enregistrements d'un fichier LDIF lorsqu'il les traite. Utilisez cette option pour désactiver le traitement des enregistrements et vérifier la syntaxe.

Utilisation du fichier d'erreurs LDIF

L'utilitaire d'importation/de conversion/d'exportation NetIQ crée automatiquement un fichier LDIF qui recense tous les enregistrements dont le traitement par le gestionnaire de destination a échoué. Vous pouvez éditer le fichier d'erreurs LDIF généré par l'utilitaire, corriger les erreurs et le réappliquer au serveur pour terminer une importation ou une migration de données contenant des enregistrements erronés.

Utilisation des indicateurs de débogage SDK LDAP

Pour comprendre certains problèmes LDIF, vous devez connaître le fonctionnement du client LDAP SDK. Vous pouvez définir les indicateurs de débogage suivants pour le gestionnaire de source LDAP, le gestionnaire de destination LDAP, ou les deux.

Pour activer cette fonction, utilisez l'option -e pour les gestionnaires de source et de destination LDAP. Le nombre entier correspondant à l'option -e est un masque binaire qui active différents types d'informations de débogage dans le SDK LDAP.

Pour plus d'informations, reportez-vous aux sections Options du gestionnaire source LDAP et Options du gestionnaire de destination LDAP du Guide d'administration de NetIQ eDirectory.

Ajout d'une nouvelle classe d'objet

Pour ajouter une classe, il suffit d'ajouter une valeur d'attribut correspondant à la spécification de NDSObjectClassDescription à l'attribut objectClasses de subschemaSubentry.

NDSObjectClassDescription = "(" whsp
   numericoid whsp
   [ "NAME" qdescrs ]
   [ "DESC" qdstring ]
   [ "OBSOLETE" whsp ]
   [ "SUP" oids ] 
   [ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ]
   [ "MUST" oids ]    
   [ "MAY" oids ]     
   [ "X-NDS_NOT_CONTAINER" qdstrings ]
   [ "X-NDS_NONREMOVABLE" qdstrings ]
   [ "X-NDS_CONTAINMENT" qdstrings ] 
   [ "X-NDS_NAMING" qdstrings ]
   [ "X-NDS_NAME" qdstrings ] 
   whsp ")"

L'exemple de fichier LDIF suivant ajoute la classe d'objet person (personne) au schéma :

 1 version: 1
 2 dn: cn=schema
 3 changetype: add
 4 objectClasses: ( 2.5.6.6 NAME 'person' DESC 'Standard
 5   ObjectClass' SUP ndsLoginProperties STRUCTURAL MUST
 6   (cn $ sn) MAY (description $ seeAlso $ telephoneNum
 7  ber $ fullName $ givenName $ initials $ uid $ userPa
 8  ssword) X-NDS_NAMING ('cn' 'uid') X-NDS_CONTAINMENT 
 9  ('organization' 'organizationalUnit' 'domain') X-NDS
10  _NAME 'Person' X-NDS_NOT_CONTAINER '1' X-NDS_NONREMO
11  VABLE '1')
12

Ajout d'un nouvel attribut

Pour ajouter un attribut, il suffit d'ajouter une valeur d'attribut qui correspond à la spécification de NDSAttributeTypeDescription sur l'attribut attributes de subschemaSubentry.

NDSAttributeTypeDescription = "(" whsp
  numericoid whsp  ; AttributeType identifier
  [ "NAME" qdescrs ]  ; name used in AttributeType
  [ "DESC" qdstring ]  ; description
  [ "OBSOLETE" whsp ]
  [ "SUP" woid ]  ; derived from this other AttributeType
  [ "EQUALITY" woid]  ; Matching Rule name
  [ "ORDERING" woid]  ; Matching Rule name
  [ "SUBSTR" woid ]  ; Matching Rule name
  [ "SYNTAX" whsp noidlen whsp ] ;  Syntax OID
  [ "SINGLE-VALUE" whsp ]  ; default multi-valued
  [ "COLLECTIVE" whsp ]  ; default not collective
  [ "NO-USER-MODIFICATION" whsp ] ;  default user modifiable
  [ "USAGE" whsp AttributeUsage ] ;  default userApplications
  [ "X-NDS_PUBLIC_READ" qdstrings ]
                             ; default not public read ('0')
  [ "X-NDS_SERVER_READ" qdstrings ]
                              ; default not server read ('0')
  [ "X-NDS_NEVER_SYNC" qdstrings ]
                               ; default not never sync ('0') 
  [ "X-NDS_NOT_SCHED_SYNC_IMMEDIATE" qdstrings ]
                            ;  default sched sync immediate ('0')
  [ "X-NDS_SCHED_SYNC_NEVER" qdstrings ]
                                  ;  default schedule sync ('0')
  [ "X-NDS_LOWER_BOUND" qdstrings ]
                              ;  default no lower bound('0')
                                    ;(upper is specified in SYNTAX)
  [ "X-NDS_NAME_VALUE_ACCESS" qdstrings ]
                         ; default not name value access ('0')
  [ "X-NDS_NAME" qdstrings ]  ; legacy NDS name 
  whsp ")"

L'exemple de fichier LDIF suivant ajoute le type d'attribut title au schéma :

 1 version: 1
 2 dn: cn=schema
 3 changetype: add
 4 attributeTypes: ( 2.5.4.12 NAME 'title' DESC 'Standa
 5  rd Attribute' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{
 6  64} X-NDS_NAME 'Title' X-NDS_NOT_SCHED_SYNC_IMMEDIA
 7  TE '1' X-NDS_LOWER_BOUND '1')
 8

 1 version: 1
 2 dn: cn=schema
 3 changetype: add
 4 attributeTypes: ( 2.5.4.12 NAME 'title' DESC 'Standa
 5  rd Attribute' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{
 6  64} SINGLE-VALUE X-NDS_NAME 'Title' X-NDS_NOT_SCHED
 7  _SYNC_IMMEDIATE '1' X-NDS_LOWER_BOUND '1')
 8

Ajout ou suppression de classes auxiliaires

L'exemple de fichier LDIF suivant crée deux nouveaux attributs, une classe auxiliaire à partir de ceux-ci, puis ajoute une entrée inetOrgPerson ayant comme classe d'objet la classe auxiliaire et fournit des valeurs pour les attributs de la classe auxiliaire.

version: 1
# Add an attribute to track a bear's hair. The attribute is 
# multi-valued, uses a case ignore string syntax, 
# and has public read rights 
# Values may include: long hair, short, curly, straight, 
# none, black, and brown 
# X-NDS_PUBLIC_READ '1' The 1 allows public read, 
# 0 denies public read 
dn: cn=schema 
changetype: modify 
add: attributeTypes
attributeTypes: ( 2.16.840.1.113719.1.186.4.10 NAME
'bearHair' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
X-NDS_PUBLIC_READ '1' )

# add an attribute to store a bear's picture 
dn: cn=schema 
changetype: modify 
add: attributeTypes 
attributeTypes: ( 2.16.840.1.113719.1.186.4.11 NAME
'bearPicture' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5
SINGLE-VALUE )

# create an Auxiliary class for the bearfeatures 
dn: cn=schema 
changetype: modify 
add: objectclasses 
objectclasses: (2.16.840.1.113719.1.186.6.101 NAME
'bearFeatures' MAY (bearHair $ bearPicture) AUXILIARY)

# now create a user named bobby
dn: cn=bobby,o=bearcave 
changetype: add 
cn: bobby 
sn: bear 
givenName: bobby 
bearHair: Short 
bearHair: Brown 
bearHair: Curly 
bearPicture:< file:///c:/tmp/alien.jpg 
objectClass: top 
objectClass: person 
objectClass: inetOrgPerson 
objectClass: bearFeatures 

# now create a person named john that will later be changed
# into a bear when bearFeatures is added to its objectClass
# list
dn: cn=john,o=bearcave
changetype: add
cn: John
sn: bear
givenName: john
objectClass: top
objectClass: person
objectClass: inetOrgPerson

# now morph john into a bear by adding bearFeatures
dn: cn=john,o=bearcave
changetype: modify
add: objectClass
objectClass: bearFeatures
-
add: bearHair
bearHair: long
bearHair: black
#bearPicture:< file:///c:/tmp/john.jpg>
-

# to morph john back to a person, simply delete the
# objectClass bearFeatures
dn: cn=john,o=bearcave
changetype: modify
delete: objectClass
objectClass: bearFeatures

Lorsque vous supprimez une classe auxiliaire de la liste objectClass, il n'est pas nécessaire de supprimer toutes les valeurs qui y sont associées. eDirectory effectue cette opération automatiquement.

Si la classe auxiliaire possédait des attributs MUST, ils doivent tous être spécifiés dans l'opération de modification qui ajoute la classe auxiliaire à la liste objectClass. Dans le cas contraire, la modification échoue.

Problèmes connus lors de l'analyse XML

Le traitement XML de tout enregistrement LDIF (format LDIF ou enregistrements générés à partir du serveur LDAP) échoue si des enregistrements ne satisfont pas à toutes les règles XML définies dans le fichier XML.

Mot de passe simple et LDIF

Sous Windows, lors du téléchargement de LDIF avec un mot de passe simple, ldif2dib risque d'échouer si les clés NICI des dossiers system et administrator ne sont pas synchronisées.

Pour éviter ce problème, accédez aux clés dans le dossier nici/system comme suit :

Schéma

Le fichier LDIF doit mentionner toutes les classes d'objet auxquelles appartient une entrée. Vous devez également inclure les classes auxquelles une entrée appartient en raison d'un héritage. Par exemple, une entrée du type inetOrgPerson a la syntaxe suivante dans le fichier LDIF :

Modèles ACL

Les objets chargés en bloc à l'aide de l'utilitaire ldif2dib ne sont pas ajoutés aux listes de contrôle d'accès spécifiées dans les modèles ACL de la classe de l'objet.

Gestionnaire de signal

Vous pouvez suspendre provisoirement l'opération de chargement en bloc hors ligne en appuyant sur la touche s ou S. Vous pouvez utiliser la touche d'échappement (Échap) pour arrêter l'opération de chargement en bloc.