Sur notre instance ITIM, nous avons mis en place la "corbeille", ce qui permet de pouvoir récupérer des objets supprimés pendant plusieurs jours.
Cependant suite à la "restauration" d'un utilisateur à partir de la corbeille, il était impossible de modifier ou supprimer l'objet.
La procédure de récupération dans la corbeille était la suivante :
Cet article explique les actions à mener pour identifier puis indexer des attributs sur l'annuaire LDAP IBM Directory Server (ITDS / ISDS / IVDS, selon l'époque et le branding IBM).
On peut récupérer les informations dans le fichier ibmslapd.log :
Sur un annuaire Sun/Oracle DSEE (ancien annuaire, encore pas mal répandu), nous avons activé le retroChangelog, afin de pouvoir identifier quelles opérations de modifications sont faites.
Pour rappel, ceci est fait via une commande dsconf :
dsconf set-server-prop -h localhost -p 389 retro-cl-enabled:on
Le paramétrage a été fait en sorte de ne garder que 30 jours de modifications :
Ce site fonctionne avec un CMS Drupal, Drupal 7 lors de sa création (en 2012!). Depuis, il a été migré en Drupal 8, cette migration ayant été la plus complexe, puisque le produit passait d'un code 100% spécifique à une architecture basée sur Symfony.
La migration Drupal8 vers Drupal9 s'est passée beaucoup plus facilement, en modifiant essentiellement les paramètres du composer.
Drupal 10 a été mise à disposition du grand public en décembre 2022.
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.
Cet article traite en parallèle de 2 problématiques :
Dans le cadre d'une migration d'annuaire, si on ne veut pas procéder au changement de produit en mode "big bang", il est généralement obligatoire de mettre en place un mécanisme de synchronisation entre l'ancienne et la nouvelle infrastructure.
Sachant que la réplication est propre à chaque produit, il est fort probable qu'il ne soit pas possible d'utiliser la réplication native des annuaires en tant que telle.
J'ai été confronté à un problème curieux d'accès à un serveur AD LDS à partir d'un container de type Forgerock DS.
Côté réseau, tout était OK, les ports ouverts d'un côté comme de l'autre.
Par contre une commande ldapsearch tombait en erreur :
/opt/opendj/bin/ldapsearch --hostname 10.1.2.3 --port 389 -D "CN=admin,CN=Admin-Users,dc=example,dc=fr" -w admin2003 \ -b "CN=Applications,DC=example,DC=fr" "(objectclass=exApplications)" Unable to connect to the server: 91 (Connect Error) Additional Information: Remote close
Pas très parlant.
Dans un projet de migration d'un annuaire AD LDS vers un Forgerock DS, le principal problème est de pouvoir récupérer les mots de passe.
En effet, AD LDS (et AD DS) ne permettent pas d'exporter le hash du mot de passe en LDIF, et il n'est pas possible non plus simplement de les récupérer, même en passant par des outils tels que creddump , ntdsextract ou autre.
Il arrive des cas où l'utilisation des attributs "simples", qu'ils soient mono ou multi-valués, n'est pas satisfaisante par rapport aux besoins des utilisateurs.
Prenons le cas suivant : on veut gérer des délégations pour X types de profils et chacun avec des rôles spécifiques.
Soit :