IAM

Identity and Access Management

IBM Directory Server : gestion des mots de passe

L'installation par défaut de l'annuaire ISDS ne semble pas "terminée" en ce qui concerne la gestion des mots de passe : pas de politique de mot de passe par défaut, pas d'activation non plus. Et une modification par ldapmodify stocke le mot de passe en clair (tout au moins, il ressort en clair dans un ldapsearch).

Autoriser le changement de mot de passe par l'utilisateur

Par défaut, l'utilisateur ne peut pas modifier lui-même son mot de passe. Par exemple, en utilisant la commande ldapchangepwd renvoie une erreur :

Connexion OpenIDM / AD SSL

De l'importance d'utiliser un nom de serveur correspondant au CN du certificat...

Contexte

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 :

  • un serveur OpenIDM sous CentOS
  • un serveur AD sous Windows 2008R2

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

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 :

Evaluation des ACI LDAP dans les annuaires Sun / Oracle / Ping / Forgerock

Beaucoup d'annuaires ont des ACI compatibles avec celles de l'annuaire Sun (issu des sources de Netscape) :
  • Sun / Oracle DSEE
  • 389DS / Red Hat Directory Server
  • Oracle OUD
  • Sun OpenDS / Wren DS
  • Forgerock OpenDJ
  • Ping Directory.
Dans ces annuaires, les ACI peuvent être positionnées directement sur les objets eux-mêmes ou sur des objets plus proches de la racine.Le mécanisme d'évaluation est globalement le suivant :
  • On traverse le DIT depuis la racine de l'annuaire jusqu'à l'entrée que l'on tente d'accéder
  • On collecte toutes les

LDAP : les types de groupes

Les annuaires LDAP sont principalement utilisés pour gérer 2 types d'objets :

  • les comptes utilisateurs (qui vont permettre une authentification centralisée)
  • des groupes d'utilisateurs (qui vont permettre une gestion de droits).

D'autres objets annexes sont souvent ajoutés, qui ont un rôle de "listes de valeurs".

Nous allons voir dans cet article les différents types de groupes qui peuvent être utilisés, sachant que selon les RFC LDAP 4519, seuls les premiers sont vraiment standardisés.

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.

Sauvegarde et restauration Ping Directory dans une topologie répliquée

Contexte

Lors d'une formation sur PingDirectory, le 'lab' sur la sauvegarde / restauration est très simple : on lance une sauvegarde avec l'utilitaire backup, puis une sauvegarde avec restore, sans avoir modifié les données. Trouvant l'exercice peut représentatif, j'ai testé la restauration en ayant au préalable supprimé des entrées. Et, ô surprise, les données n'ont pas été restaurées.

Il ne s'agit pas d'un problème sur le produit, mais d'un problème de processus.