Identity and Access Management
Suite à l'ajout de rôles dynamiques sur une instance ITIM, on note un comportement curieux d'ITIM à chaque modification d'un utilisateur ; la modification échoue, avec le message de retour :
CTGIMO019E The following LDAP error occurred. Error: Unbalanced parenthesis.
En regardant les logs ITIM (trace.log), on identifie une stack dump java :
Lorsqu'on charge un adaptateur ITIM (via Configure system > Manage Service Types) on récupère la description de l'adaptateur.
Par défaut, celui-ci n'est pas versionné, il s'agit juste d'une description :
La suppression d'un membre dans un groupe (uniqueMember) est très longue par défaut, sur un groupe qui contient plus de 66 000 entrées :
time ldapmodify -x D bindn -w password-f delMember.ldif delete uniqueMember: uid=USER1,ou=employees,ou=users,ou=example,o=com modifying entry "cn=InternalUsers,ou=groups,ou=example,o=com" modify complete real 6m17.845s user 0m0.088s sys 0m0.112s
Le fichier LDIF utilisé étant le suivant :
Sur un serveur Linux, la configuration OpenLDAP se trouve dans /etc/openldap, et plus précisément dans /etc/openldap/slapd.d.
Les données, quant à elles, se trouvent... où on leur a dit de se mettre, puisque ceci est défini pour chaque rootSuffix.
Par exemple, si pour notre rootSuffix, nous définissons dans le fichier /etc/openldap/slapd.d/cn=config/olcDatabase={2}bdb.ldif les informations suivantes (extrait) :
Dans ITIM, un service est placé dans une "Business Unit". Une fois défini, il n'est pas possible de le bouger via la console ITIM (ce serait possible en modifiant son attribut erparent dans l'annuaire, mais pas supporté ni conseillé par IBM).
Le placement d'un service ITIM permet de le positionner par rapport à des règles de provisionnement ou encore des règles de sélection de service. Si on bouge un service, est peut donc potentiellement être en dehors du périmètre de ces règles.
OpenLDAP est souvent un peu chatouilleux sur le respect de la syntaxe LDAP, nous l'avons déjà vu par ailleurs (cf . http://www.vincentliefooghe.net/node/45).
J'ai eu récemment des problèmes dans le provisionnement d'un annuaire OpenLDAP par ITIM, avec dans les traces ITIM (le fichier trace.log), les lignes :
Avant de pouvoir lancer des rapports d'activité, audit et autres dans ITIM, il faut auparavant lancer une "Data Synchronization".
Cette étape peut parfois être très longue, en fonction des données à traiter. Sur notre plate-forme de production, tout récemment initialisée, l'opération a duré 47 minutes pour 70 000 personnes (et aucun compte externe à ITIM).
Suite à un crash disque sur un serveur mutualisé de base de données de développement - non sauvegardé, nous avons du recréer la partie base de données.
La base Oracle a été créée par les DBA, conformément aux recommandations avec les tablespaces ENROLE_DATA et ENROLE_INDEXES.
Le paramètre nls_length_semantics doit avoir pour valeur BYTE. Dans le cas contraire, oracle ne peut pas créer certains index, trop longs.
Il faut ensuite :
Gros problème ces temps-ci, alors qu'on voulait démarrer en production : lors de certaines opérations dans ITIM, l'annuaire ITDS crash sans message dans ses logs. J'avais déjà remarqué des soucis relativement similaires sur notre plate-forme de développement, que j'avais mis sur le compte de mises à jour nombreuses et pas forcément très carrées...
Lorsque l'annuaire s'arrête, on n'a aucun message dans son fichier ibmslapd.log. Par contre, on constate dans le fichier /var/log/messages :
Comme tout logiciel complexe ITIM est parfois la source de problèmes, plus ou moins graves.
Cette section recense les soucis que l'ai pu avoir sur le produit et son environnement (Websphere, ITDS)