ITIM : Paramétrage système
La grande majorité des paramètres "système" ITIM se trouvent dans des fichiers .properties, situés dans le répertoire [ITIM_HOME]/data.
On y trouve par exemple :
Identity and Access Management
La grande majorité des paramètres "système" ITIM se trouvent dans des fichiers .properties, situés dans le répertoire [ITIM_HOME]/data.
On y trouve par exemple :
Les paramètres liés au serveur de mail (sortant) pour ITIM se trouvent dans le fichier enRoleMail.properties
, lui-même situé dans le répertoire [ITIM_HOME]/data
, comme la plupart des fichiers de configuration.
Exemple de configuration :
Les logs OpenLDAP sont gérés par syslog. Il faut ajouter une ligne dans /etc/rsyslog.conf , sachant que openldap log sur la facility local4:
# Log Openldap local4.* -/product/openldap/log/slapd.log
Dans notre exemple, les logs seront situés dans le répertoire /product/openldap/log.
Note : l'ajout d'un tiret devant le nom du fichier permet à syslog d'écrire en mode asynchrone, ce qui améliore les performances.
Il faut ensuite redémarrer openldap et syslog :
IBM Tivoli Identity Manager permet de gérer une hiérarchie de rôles, qui peuvent être caractérisés (Business Role vs Application Role).
On peut donc avoir un rôle parent qui dispose de plusieurs rôles enfants, sachant qu'un rôle enfant peut avoir plusieurs parents (et pas que 2!).
Par contre, l'héritage marche un peu à l'envers : ce sont les rôles enfants qui doivent être des "Business Roles", et les rôles parents sont des rôles applicatifs "Application Role", qui sont utilisés dans les règles de provisionnement.
Exemple :
Par défaut dans OpenLDAP le mot de passe utilisateur (attribut usepassword) est stocké sans cryptage.
Si on modifie le mot de passe via un fichier LDIF, on aura donc le mot de passe en clair dans l'annuaire, ce qui n'est pas sécurisé.
On peut également appliquer un algorithme de cryptage en amont (dans l'application cliente) et le transmettre à OpenLDA, qui va le stocker tel quel.
Nous avons eu récemment le besoin de notifier par mail les administrateurs de domaine, sur un service situé en haut de l'organisation (service partagé), alors que les personnes sont rattachées à des sous-domaines.
Du coup, le type de participant DOMAIN_ADMIN ne fonctionne pas, car il est rattaché au service.
Il a donc fallu développer un javascript spécifique pour arriver à nos fins. Celui-ci est finalement assez simple (une fois qu'on a réussi à naviger dans la documentation IBM...)
Il arrive parfois que les requêtes ITIM restent en suspens, sans raison apparente.
En regardant le log tivoli/common/CTGIM/logs/msg.log
, on peut détecter des erreurs sur les files JMS :