J'ai eu récemment le cas d'un client qui voulait, lors de la suppression d'un objet user, mettre à jour l'annuaire LDAP sur lequel l'utilisateur avait un compte, plutôt que supprimer ce compte.

Pour cela, il faut tout d'abord modifier l'action liée à la situation SOURCE_MISSING, pour utiliser Unlink plutôt que Delete (en fait, si on garde l'opération Delete, on peut lancer un script, mais l'objet cible sera quand même supprimé par la suite).

Dans une architecture de type intranet, il est intéressant d'avoir une base de comptes commune, partagée entre plusieurs applications.
Ceci permet dans un premier temps d'avoir un seul couple login / mot de passe, et supprime la nécessite de créer manuellement des comptes dans chaque application.

OpenIDM est prévu pour s'installer et fonctionner en mode cluster, de manière assez facile.

Chaque instance partage le même repository, ce qui leur permet de disposer des mêmes données, la configuration étant alors partagée. Seul le repository est utilisé pour le cluster, sans autre mécanisme (pas de test de lien réseau par exemple).

Cet article explique comment démarrer deux instances OpenIDM qui vont partager le même repository et utiliser une ressource LDAP commune (OpenDJ dans notre exemple).

Il est d'usage courant de personnaliser le schéma de données, en ajoutant des attributs et des classes d'objets spécifiques au client.

OpenDJ permet bien évidemment de définir son propre schéma de données. La déclaration des attributs et classes d'objets est faite dans différents fichiers LDIF, chargés au démarrage de l'instance, et qui se trouvent dans $DJHOME/config/schema.
Par défaut, après l'installation, on y trouve une quinzaine de fichiers: