Suite à l'installation d'une instance OpenDS 2.3 sur une pré-production, sur RHEL 7 et java 1.6, un utilisateur se plaignait de ne plus pouvoir faire fonctionner son application.
Lorsqu'il lançait sa recherche, il n'avait aucun résultat, mais un message d'erreur :
Les ACL dans OpenLDAP peuvent se trouver à 2 niveaux, database ou backEnd, sachant qu'il est assez courant d'avoir un backend par database (ou vice-versa).
Les ACL sont donc généralement positionnées dans la configuration de la database.
La syntaxe globale est :
olcAccess: to [ressource] by [à qui] [type d'accès autorisé] by [à qui] [type d'accès autorisé] by [à qui] [type d'accès autorisé]
Un exemple de base, qui limite l'accès à l'attribut userPassword :
Comme vu précédemment (https://www.vincentliefooghe.net/content/migration-sun-dsee-vers-openld…) la migration Sun DSEE vers OpenLDAP nécessite une phase d'adaptation des schémas spécifiques.
Si on utilise des attributs ou classes d'objets propres à la structure (ce qui est bien souvent le cas) il faudra adapter la définition pour OpenLDAP.
Exemple d'un fichier 99user.ldif :
Lors des interactions en LDAP avec Active Directory, certaines actions nécessitent l’utilisation de LDAPS (LDAP sur SSL) entre le client et Active Directory.
Ceci est notamment le cas si l’on veut modifier le mot de passe.
Ce document décrit comment activer le LDAPS sur un environnement Active Directory.
A priori il y a deux méthodes possibles pour activer LDAPS sur un contrôleur de domaine :
Récemment, nous avons eu un souci lors du redémarrage d'une instance CA Identity Manager.
D'une part, l'annuaire UserStore ne veut pas se lancer. Lorsqu'on tente un démarrage avec la commande dxserver start, on a le message :
dxserver start userstore Message userstore does not exist
On vérifie bien que la configuration est là, que les fichiers de données sont également présents... Pas de processus en cours d'exécution.
Je suis tombé récemment sur un problème curieux, lors de l'installation d'une plate-forme de test de CA Identity Manager.
L'application tourne sous JBoss EAP 6, avec un Java 1.8, et une base Oracle 12C.
Après avoir installé la base et créé le listener, on observe un comportement curieux :
Dans un environnement client OpenIDM 3.1 en production depuis plusieurs mois, l'accès à l'écran d'administration des mappings met de plus en plus longtemps à s'afficher.
It may help : if the access time to mapping administration form in OpenIDM becomes very slow, then check the numbers of lines in auditrecon table, and delete old records.
Lors d'un précédent article sur chkconfig, j'avais décrit comment activer les services sous Red Hat, avec les scripts init.d (à la mode SysV).
Depuis, la majorité des distributions GNU/Linux est passée sous systemd, qui apporte son lot de changement.
LA commande à connaître est maintenant systemctl. C'est elle qui permet de gérer la grande majorité des interactions au niveau administrateur.
La syntaxe est la suivante :
Depuis quelques jours, je recevais des mails de monit, indiquant un load average trop élevé sur un serveur dont je m'occupe épisodiquement (serveur de l'association Down Up).
Cela m'a semblé curieux, car il s'agit d'un serveur dédié OVH, avec un Xeon 8 coeurs, et 64 Go de RAM, qui héberge uniquement quelques sites web.
Ayant eu dans le temps des problèmes de piratage de sites, j'ai regardé le nombre de messages dans la file postfix :
Chez un client, nous avons activé le niveau de log à INFO par défaut afin d'avoir des traces des opérations, notamment car on travaille sur la base d'un changelog depuis un annuaire LDAP Sun, avec un polling toutes les 10 secondes. Plusieurs providers sont ainsi déclenchés : l'un pour les utilisateurs du LDAP, un autre pour les groupes, et encore un pour les groupes AD.
Ceci a pour effet de bord de remplir les logs d'informations peu utiles, du genre :