Dans un projet client qui utilise IDM 7 (après une montée de version OpenIDM 3.1 vers IDM 7 qui s'est plutôt bien passée), nous avons mis en place la gestion du cycle de vie et notamment la suppression automatique de comptes 30 jours après la fin de contrat, comme ce que l'on voit souvent.
Il a été décidé d'archiver quelques données des utilisateurs, histoire d'avoir un peu de traces.
De l'importance d'utiliser un nom de serveur correspondant au CN du certificat...
Afin de pouvoir tester la connexion d'un OpenIDM sur un serveur AD (et par la suite la mise en place du plugin de synchronisation de mot de passe) j'ai mis en place une maquette simple avec :
J'ai mis en place un certificat sur le serveur AD, qui est aussi le contrôleur de domaine principal, avec un certificat qu'il a généré.
Lors des interactions en LDAP avec Active Directory, certaines actions nécessitent l’utilisation de LDAPS (LDAP sur SSL) entre le client et Active Directory.
Ceci est notamment le cas si l’on veut modifier le mot de passe.
Ce document décrit comment activer le LDAPS sur un environnement Active Directory.
A priori il y a deux méthodes possibles pour activer LDAPS sur un contrôleur de domaine :
Dans un environnement client OpenIDM 3.1 en production depuis plusieurs mois, l'accès à l'écran d'administration des mappings met de plus en plus longtemps à s'afficher.
It may help : if the access time to mapping administration form in OpenIDM becomes very slow, then check the numbers of lines in auditrecon table, and delete old records.
Suite à une mise à jour sur un serveur Windows, le plug-in de synchronisation de mot de passe entre le serveur Active Directory et OpenIDM 2.1 ne fonctionnait plus.
La console d'événements Windows était remplie d'erreur, et dans le fichier de logs OPENIDM_HOME/logs/openidm0.log.0, on avait de nombreuses erreurs :
Dans les versions 2.1, 3.0 et 3.1, OpenIDM fournit un script shell qui permet de mettre en place la rotation des fichiers d'audit (OPENIDM_HOME/bin/create-openidm-logrotate.sh).
Par contre ce script a 2 inconvénients à mon sens :
Une fois n'est pas coutume, cet article ne sera pas (trop) orienté technique, mais fait plutôt suite à un retour d'expérience sur un projet qui se termine, et dans lequel la souplesse de OpenIDM et son côté "boîte à outils" ont permis de faire des choses qui auraient été compliquées à faire avec un autre outil (sachant que la principale solution avec laquelle je peux comparer est IBM ISIM).
La version 4 de OpenIDM est disponible depuis fin janvier 2016 (cf. les Release Notes).
Cette nouvelle version apporte son lot de changements, qui améliorent encore un peu le produit. On peut notamment citer des nouveautés du côté de l'interface d'administration :
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).