J'ai observé un comportement curieux sur un annuaire OpenLDAP, suite à la mise en place de nouveaux serveurs dans une topologie de réplication.
En parcourant l'annuaire avec un browser LDAP, le container / OU qui contient les comptes de services n'est plus visible... Alors qu'on peut toujours faire une requête LDAP pour trouver les comptes de services situés dans ce container.
Au départ, je pensais à une ACI, mais je n'arrivais pas à l'identifier. Et même en utilisant le compte administrateur (qui ne prend pas en compte les ACI), l'objet est toujours invisible.
Pour en avoir le coeur net, je récupère un export LDIF, réalisé avec la commande slapcat, donc directement sur les objets de la base de données.
Le détail de cet objet est le suivant :
dn: ou=servicesaccounts,dc=example,dc=com
creatorsName: cn=ldapadmin,dc=example,dc=com
entryUUID: 3f5fe91c-fa15-103c-895e-9d61df2575cf
createTimestamp: 20221116161244Z
entryCSN: 20221116161244.214664Z#000000#280#000000
modifiersName: cn=ldapadmin,dc=example,dc=com
modifyTimestamp: 20221116161244Z
objectClass: top
objectClass: glue
structuralObjectClass: glue
On remarque la classe d'objet : objectClass: glue. Curieux, il n'y a pas de classe organizationalUnit, comme on devrait l'avoir.
Sur notre annuaire de qualification, l'objet existe, et il est bien correct :
dn: ou=servicesaccounts,dc=example,dc=com
objectClass: organizationalUnit
ou: servicesaccounts
description: Container for service accounts
structuralObjectClass: organizationalUnit
entryUUID: 2276ea16-dcec-1033-829e-3bedbb455876
creatorsName: cn=ldapadmin,dc=example,dc=com
createTimestamp: 20140930125043Z
pwdFailureTime: 20221007122244Z
entryCSN: 20221008035001.807937Z#000000#002#000000
modifiersName: cn=SVCA3D,ou=servicesaccounts,dc=example,dc=com
modifyTimestamp: 20221008035001Z
entryDN: ou=servicesaccounts,dc=example,dc=com
subschemaSubentry: cn=Subschema
hasSubordinates: TRUE
Si on essaie de modifier l'entrée, par exemple pour ajouter la bonne classe d'objet, le serveur répond avec une erreur de type : ldap_modify: No such object (32).
.
D'après les informations trouvées, ceci arrive lors d'un problème de réplication. Si OpenLDAP voit passer un objet "fils", sans avoir l'objet parent, il crée un objet avec la classe "glue", pour respecter l'arborescence.
Le souci, c'est qu'on n'arrive pas à requêter cette entrée, mais qu'on peut "passer au travers", et donc avoir accès aux objets fils.
La solution : faire un fichier LDIF de modification, dans lequel on met tous les attributs, et lancer la modification avec l'option "-M" sur ldapmodify. Dans notre cas, le fichier ldif est le suivant :
dn: ou=servicesaccounts,dc=example,dc=com
changetype: modify
add: objectClass
objectClass: organizationalUnit
-
add: description
description: Container pour les comptes de service
-
add: ou
ou: servicesaccounts
-
delete: objectClass
objectClass: glue
On passe ensuite la commande lpdamodify :
ldapmodify -x -M -H ldap://localhost:389 -D "cn=ldapadmin,dc=example,dc=com" -w MonSecret4Admin -f /path/to/fichier.ldif
L'option "-M" permet de forcer la synchronisation (Enable manage DSA IT control).
L'entrée est bien modifiée, et on retrouve un comportement normal.
En conclusion
Si on ajoute un serveur dans une topologie de réplication, il est prudent de charger l'annuaire via un import LDIF avant d'activer la réplication. Dans mon cas, je pense (hypothèse à vérifier) que le souci est venu du fait que j'ai voulu utiliser un compte de service pour me connecter à l'annuaire et en voir le contenu, alors que j'avais activé le mécanisme de last login time. Du coup, le serveur a voulu mettre à jour une entrée dont le parent n'existait pas encore, et a créé un objet avec la classe d'objet 'glue'.
Il faut savoir que cette classe d'objet est utilisée par les annuaires de type OpenLDAP, mais aussi Sun DSEE, Oracle DSEE ou encore les Forgerock DS.
Ajouter un commentaire