ldap

Synchronisation d'annuaires avec LSC

Contexte

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.

Problème de connexion ldapsearch sur un AD LDS

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.

Utilisation de SLAMD pour les benchmarks LDAP

Lorsqu'on réalise des études comparatives sur les annuaires LDAP, il est fréquent que le client demande d'établir des tests de performances, pour s'assurer que la solution en place sera capable de répondre à ses exigences.

Pour faire cela, j'utilisais souvent les outils authrate ou searchrate présents dans les binaires des annuaires de Forgerock ou Ping.

Si ces outils permettent de tester de manière unitaire, et avec un certain nombre de paramètres, ils manquait certaines possibilités / fonctionnalités :

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.

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 :

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.

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.

Installation Sun DSEE sur Red Hat

Pré-requis

Installer sur une distribution Red Hat Enterprise Server 6.x (6.8 dans notre cas). Mode Basic Server

Attention : même sur un système 64 bits, Sun DSEE fonctionne en mode 32 bits. Il faut donc s'assurer d'avoir installé les librairies compatibles.

Pré-requis logiciels

Installer les paquets :

  • unzip
  • wget
  • compat-glibc
  • compat-gcc-32
  • compat-libstdc++
  • libstdc++
  • zlib.i686

On utilise yum pour installer tout cela :