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 :
Je suis intervenu récemment chez un client dont le certificat https expirait dans les quinze jours, mais dont le serveur webmail est un Lotus Domino, dans une version qui n'est pas compatible avec des certiifcats encodés en autre chose que SHA1.
Leur prestataire ne pouvant générer que des certiicats en SHA256 leur a proposé 2 options :
Abstract : in some cases, it is interesting to have multiples instances of OpenLDAP running on the same machine. This could be used to separate data, test replication on the same server, or whatever you want.
This note will explain how to do this.
In a standard GNU/Linux OpenLDAP install (Red Hat or Debian based), there are several files or directories used to set up OpenLDAP instance and data :