Sun / Oracle DSEE - Indexation d'attributs
Petit rappel pour l'ajout d'index sur Sun DSEE
Symptômes
Machine très lente. Dans le log errors :
Identity and Access Management
Petit rappel pour l'ajout d'index sur Sun DSEE
Machine très lente. Dans le log errors :
Lors d'une formation sur PingDirectory, le 'lab' sur la sauvegarde / restauration est très simple : on lance une sauvegarde avec l'utilitaire backup, puis une sauvegarde avec restore, sans avoir modifié les données. Trouvant l'exercice peut représentatif, j'ai testé la restauration en ayant au préalable supprimé des entrées. Et, ô surprise, les données n'ont pas été restaurées.
Il ne s'agit pas d'un problème sur le produit, mais d'un problème de processus.
Note : Le problème arrive dans un cas bien particulier, uniquement si on veut faire du multi-instances avec OpenLDAP sur une machine, qui tourne avec un O.S. Ubuntu (testé à partir de 16.04).
Les mêmes actions sur un serveur sous Debian se passent correctement.
La configuration et les données sont dans une arborescence :
Par défaut, il n'est pas possible de déterminer la date de dernière connexion réussie sur un annuaire LDAP (last login time). Seules les erreurs de connexion peuvent être détectées dans les politiques de mots de passe.
Parfois cependant, il est intéressant de connaître la date de dernière connexion, afin de pouvoir supprimer - ou bloquer - des comptes inutilisés depuis plusieurs mois.
Installer sur une distribution Red Hat Enterprise Server 6.x (6.8 dans notre cas). Mode Basic Server
Attention : même sur un système 64 bits, Sun DSEE fonctionne en mode 32 bits. Il faut donc s'assurer d'avoir installé les librairies compatibles.
Installer les paquets :
On utilise yum pour installer tout cela :
La plupart du temps, les annuaires LDAP sont paramétrés avec une réplication entre deux serveurs, afin d'apporter une meilleure disponibilité ou permettre une montée en charge horizontale, via la mise en place d'un répartiteur de charge en frontal.
Un serveur installé en tant que master : openldap1.arciam.fr. Il écoute sur le port 389. L'overlay syncprov a été chargé en tant que module , via la configuration :
Dans une architecture LDAP de production, on met généralement en place plusieurs instances d'annuaires, qui sont répliquées entre elles. L'inconvénient dans ce cas est que les logs sont répartis sur chaque serveur, et qu'il devient difficile d'avoir une vue d'ensemble des opérations.
Il existe cependant des solutions de centralisation, aggrégation et visualisation de données. Les plus connues étant Splunk et ELK.
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 :