forgerock

OpenIDM - Sécuriser un Connecteur Database Table

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.

Forgerock OpenDJ / DS - Supprimer les contrôles de syntaxe

Par défaut les nouveaux annuaires LDAP issus des sources OpenDS (tels que OpenDJ / DS chez Forgerock, mais aussi Ping Directory) renforcent les contrôles sur la syntaxe des attributs, le schéma, etc.

Ceci empêche par exemple d'avoir un objet avec de multiples classes structurelles non hiérarchiques (par exemple inetorgperson et country).

Par contre lorsqu'on importe des données d'un annuaire un peu moins strict (type Sun / Oracle DSEE), on se heurte souvent à des erreurs.

Upgrade Forgerock OpenDJ / DS

Deux scénarios de migration / upgrade seront étudiés :

  • upgrade "en place" d'un annuaire en version inférieure
  • ajout dans la topologie de réplication d'un annuaire en version supérieure.

Dans cet exemple, on va procéder à une migration de la version OpenDJ 3.5.1 à la version DS 6.5.

Environnement

L'environnement de test est le suivant :

3 serveurs : dj1.id-num.com, dj2.id-num.com, dj3.id-num.com.

Dans un premier temps, seuls les serveurs dj1 et dj2 sont installés, en mode multi-maîtres :

Création de comptes Administrateurs dans OpenDJ / Ping Directory

Lorsqu'on installe un annuaire LDAP, on crée un compte (souvent "cn=Directory Manager" par défaut) qui a tous les privilèges, qui n'est pas soumis aux ACI, bref, un superAdmin avec tous les privilèges.

Il vaut donc mieux éviter d'utiliser ce compte pour des opérations. On peut toujours utiliser des comptes "utilisateurs", mais dans ce cas, le DN du compte change selon le baseDN.

Si on veut industrialiser le monitoring de l'annuaire, par exemple, il est intéressant d'avoir toujours le même compte, quel que soit l'instance et donc le baseDN.

OpenDJ : mise en place du suivi des connexions

Par défaut, il n'est pas possible de déterminer la date de dernière connexion réussie sur un annuaire LDAP (last login time). Seules les erreurs de connexion peuvent être détectées dans les politiques de mots de passe.

Parfois cependant, il est intéressant de connaître la date de dernière connexion, afin de pouvoir supprimer - ou bloquer - des comptes inutilisés depuis plusieurs mois.

OpenIDM : purge des tables audit

Contexte

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.

English Summary

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.

OpenIDM - les avantages et la souplesse de l'ouverture

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).