Identity and Access Management
Les droits d'accès sur les objets du DIT OpenLDAP sont contrôlés par des ACL (Access Control List), qui sont stockés au niveau du rootSuffix.
Par exemple, on peut récupérer les règles via une requête telle que :
Par défaut, les attributs d'un annuaire OpenLDAP ne sont pas indexés. Comme dans une base de données, ceci peut impacter les performances de l'annuaire, en introduisant des full scan qui balaient toutes les entrées. Il est possible, comme sur une base de données, de créer des index sur certains attributs, pour améliorer la vitesse de recherche.
Toutefois, les index ont également un inconvénient : lors des mises à jour, l'index doit être recalculé, et ceci peut être pénalisant, notamment lors de modifications en masse.
Dans un environnement ITIM, qui utilise une base Oracle, on a parfois des messages d'erreurs dans le fichier WebSphere SystemOut.log :
Par défaut, ITIM utilise la time-zone de WebSphere, qui n'étant pas définie, peut être différente de l'heure du serveur.
Nous avons eu le souci sur une installation en Russie : le paramétrage des réconciliations utilisait l'heure française :
Dans la série des overlays pour OpenLDAP, après le Password Policy, regardons l'accesslog.
L'overlay Accesslog peut être utile pour récupérer dans une branche séparée de l'annuaire un ensemble d'opérations appliquée sur une database.
Le paramétrage distingue 4 sortes d'opérations :
Par défaut, OpenLDAP implémente strictement les RFC du protocole LDAP, et ne dispose que de (relativement) peu de fonctionnalités par rapport à ses concurrents.
Il existe cependant un mécanisme d'overlays, qui permet de modifier et enrichir le comportement de cet annuaire.
On y trouve notamment (cf. http://www.openldap.org/doc/admin24/overlays.html) :
Dans certaines règles de provisionnement (Provisioning Policies), il est parfois nécessaire de construire le DN du manager, par exemple pour alimenter un champ manager dans un annuaire LDAP ou Active Directory, qui sont des DN.
Inutile donc, dans ce cas, de mettre uniquement le matricule ou le nom du manager, il faut soit construire, soit récupérer la valeur du DN du manager dans le service distant.
Voyons comment ceci peut être réalisé dans une PP ITIM, selon les cas.
Depuis la version 2.4, le moteur de stockage recommandé par défaut pour OpenLDAP est MDB ou LMDB (Lightning Memory-Mapped Database). Dans les distributions Red Hat par contre, c'est toujours le moteur BDB (Berkeley DataBase), ou son évolution HDB (Hierarchical Database) qui est recommandé et utilisable, vu la version ancienne utilisé : 2.4.23.
HDB est une variante du backend BDB. HDB utilise un modèle hiérarchique, qui supporte notamment le renommage d'un sous-arbre. Etant basé sur BDB, les mêmes options de configurations sont présentes.
Lors du lancement d'un traitement sur un annuaire IBM Tivoli Directory Server (ITDS), on remarque ceci dans les logs (ibmslapd.log) :
07/11/2013 03:26:23 PM GLPRDB069E Attribute IIRUSERATTRIB8 has a maximum value length of 240. Current attribute value is of length 242.
Voyons ce que dit le schéma de l'annuaire :
Ce post de blog explique les étapes suivies et les écueils rencontrés lors de l'installation de ISIM6 (ex ITIM) sur une plate-forme Linux RedHat 64bits.
Depuis la version 6, IBM a renommé ITIM (IBM Tivoli Identity Manager) en ISIM (IBM Security Identity Manager).
L'environnement technique est le suivant :