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 :
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.
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 :
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 :
Afin d'améliorer les performances de OpenLDAP, il est recommandé de pouvoir utiliser le plus de cache possible pour monter en mémoire les données OpenLDAP.
Ceci se fait via les réglagles du fichier DB_CONFIG, qui se trouve dans le répertoire contenant les données de l'annuaire, et qui permet de paramétrer la base de données Berkeley, utilisée comme back-end de stockage par OpenLDAP.
Par défaut, il n'y a pas de fichier DB_CONFIG créé. Par contre on peut trouver un exemple dans /usr/share/openldap-servers/DB_CONFIG.example :
Par défaut, le schéma de données de ITDS (IBM Tivoli Directory Server) est chargé au démarrage, à partir du fichier V3.modifiedschema, présent dans le répertoire /etc de l'instance d'annuaire.
Par exemple, pour une instance nommé idsldap, le fichier sera dans le répertoire /product/ldap/idsslapd-idsldap/etc.
Si on veut ajouter un attribut ou une classe d'objet à notre schéma, il est évidemment possible d'arrêter le serveur, modifier le fichier V3.modifiedschema, puis redémarrer ITDS.
Dans une architecture de type intranet, il est intéressant d'avoir une base de comptes commune, partagée entre plusieurs applications.
Ceci permet dans un premier temps d'avoir un seul couple login / mot de passe, et supprime la nécessite de créer manuellement des comptes dans chaque application.