Identity and Access Management
J'ai eu l'occasion ces derniers temps de travailler sur les deux produits phares de Sailpoint : Identity IQ (IIQ), la version "on premise" et IdentityNow (IDN), la version SaaS = Software As A Service.
L'éditeur semble mettre en avant la solution SaaS, mais même si celle-ci évolue rapidement (sans doute beaucoup plus vite que IdentityIQ), il y a encore quelques limitations.
La question qui se pose est : pourquoi mémoriser la date de dernière authentification ?
Le principal intérêt est de mettre en place un premier niveau de gouvernance : cette date permet d'identifier les comptes qui sont obsolètes dans l'annuaire, par exemple qui n'ont pas été utilisés pour s'authentifier depuis plusieurs mois.
Par défaut, cette information n'est pas disponible sur OpenLDAP (comme cela peut l'être dans un AD).
On peut analyser les logs systèmes (avec un niveau de log OpenLDAP à 256), mais ce n'est pas optimal.
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.
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.
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).
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 :
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é.
Dans notre environnement Sailpoint IIQ, notre intégrateur développe un ensemble de classes Java pour étendre la solution, en utilisant les nombreuses API.
Deux scénarios de migration / upgrade seront étudiés :
Dans cet exemple, on va procéder à une migration de la version OpenDJ 3.5.1 à la version DS 6.5.
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 :
Beaucoup d'annuaires ont des ACI compatibles avec celles de l'annuaire Sun (issu des sources de Netscape) :
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 :
Suite au rachat (déjà ancien) de Sun par Oracle, l'annuaire LDAP Sun DSEE, devenu Oracle DSEE depuis, arrive en fin de support. Ce produit a eu ses beaux jours en entreprise, à l'époque c'était probablement l'un des meilleurs, capable de gérer des centaines de milliers d'entrées, avec une architecture assez simple.