Surveillance d'un annuaire OpenLDAP

Surveiller le service LDAP

1. Le processus "slapd"

Afin de s’assurer du fonctionnement de l’annuaire OpenLDAP, il faudra contrôler que le service "slapd" est en cours d’exécution. Pour ce faire, il est conseillé d’utiliser une architecture de monitoring comme "Nagios" qui par l’intermédiaire d’un agent de surveillance installé sur le serveur OpenLDAP pourra détecter lorsque celui-ci est arrêté. Certains agents de surveillance ont même la possibilité de redémarrer automatiquement un service arrêté. Il existe également des solutions au niveau des systèmes d’exploitation avec, par exemple sous Linux, le fichier /etc/inittab qui permet de spécifier les processus à redémarrer en cas de plantage par l’intermédiaire du paramètre respawn.

2. Les systèmes de fichiers

Par ailleurs, il faut aussi s’assurer que l’espace disponible sur (le ou) les systèmes de fichiers contenant les données de l’annuaire (ex. /var/lib/ldap) est suffisant car, dans le cas contraire, cela pourrait entraîner un dysfonctionnement du service LDAP.

Surveiller la réplication

Afin de vérifier le bon fonctionnement de la réplication entre deux annuaires, il faudra surveiller le numéro de séquence de modification contenu dans le cookie de synchronisation (SyncCookie) mis à jour par le provider à la fin de chaque connexion de réplication. Ce numéro se trouve dans la valeur de l’attribut contextCSN de chaque entrée de l’annuaire répliqué.

Ainsi, la méthode de surveillance de la réplication consistera, dans une architecture de réplication "Peer-to-Peer", à consulter les valeurs de l’attribut contextCSN sur chacun des annuaires. L’exemple de la figure 16-1 illustre un cas où la réplication fonctionne correctement, car les valeurs sont identiques pour les deux annuaires.


[root@ldap01 ~]# ldapsearch -h ldap01 -D  
"cn=root,dc=exemple,dc=com" -W -b "dc=exemple,dc=com" -s base 
'contextCSN' -LLL ; ldapsearch -h ldap02 -D  
"cn=root,dc=exemple,dc=com" -W -b "dc=exemple,dc=com" -s base 
'contextCSN' -LLL 
 
Enter LDAP Password:  
dn: dc=exemple,dc=com 
contextCSN: 20160810133053.733199Z#000000#001#000000 
contextCSN: 20160810133115.876608Z#000000#002#000000 
 
Enter LDAP Password:  
dn: dc=exemple,dc=com 
contextCSN: 20160810133053.733199Z#000000#001#000000 ...

Surveiller les connexions au serveur LDAP

Il peut être intéressant de savoir quels serveurs sont actuellement connectés à notre serveur LDAP et de disposer de quelques statistiques à propos des requêtes effectuées.

Pour cela, il faudra ajouter et configurer l’overlay "Monitor" en chargeant tout d’abord le module "back_monitor.la" puis créer sa branche spéciale où seront collectées les informations de connexion à l’annuaire (cf. chapitre Ajout de fonctionnalités appelées overlay pour l’installation de cet overlay).

Figure 16-2 : Module de l’overlay "Monitor"

Figure 16-3 : Branche de l’overlay "Monitor"


ldapsearch -h ldap01 -D "cn=root,dc=exemple,dc=com" -W -b 
"cn=Connections,cn=Monitor" -s sub  
'objectclass=monitorConnection' 'monitorConnectionAuthzDN'  
'monitorConnectionListener' 'monitorConnectionPeerAddress' -LLL 
 
# Connection 3982, Connections, Monitor 
dn: cn=Connection 3982,cn=Connections,cn=Monitor 
objectClass: monitorConnection 
structuralObjectClass: monitorConnection 
cn: Connection 3982 
creatorsName: 
modifiersName: 
createTimestamp: 20160718080720Z 
modifyTimestamp: 20160718080723Z 
monitorConnectionNumber: 3982 
monitorConnectionProtocol: 3 
monitorConnectionOpsReceived:...

Surveiller les modifications du contenu de l’annuaire

L’overlay "audit logging" ajouté lors du chapitre Ajout de fonctionnalités appelées overlay permet d’enregistrer toutes les modifications faites dans l’annuaire.

Ainsi, lors de l’ajout, la suppression ou bien même la modification d’une entrée, il est alors possible de visualiser par exemple les informations suivantes dans le fichier journal (cf. figure 16-5) :


[root@ldap01 tmp]# cat auditlog.log 
# add 1492170112 dc=exemple,dc=com cn=root,dc=exemple,dc=com 
IP=194.88.223.64:4945 conn=2124 
dn: uid=usertmp,ou=users,dc=exemple,dc=com 
changetype: add 
uid: usertmp 
uidNumber: 60012 
gecos: USERTMP 
homeDirectory: /home/ usertmp 
gidNumber: 60001 
cn: usertmp 
objectClass: account 
objectClass: top 
objectClass: posixAccount 
objectClass: shadowAccount 
loginShell: /bin/bash 
userPassword:: e1NBU0x9c3JvcGFyc0BnZW1hbHRvLmNvbQ== 
pwdChangedTime: 20170414114152Z 
structuralObjectClass: account 
entryUUID: 19193cfc-b553-1036-8391-3192ac3f20b3 
creatorsName: cn=root,dc=exemple,dc=com 
createTimestamp: 20170414114152Z 
entryCSN: 20170414114152.537277Z#000000#001#000000 
modifiersName: cn=root,dc=exemple,dc=com 
modifyTimestamp: 20170414114152Z 
# end add 1492170112 
 
# delete 1492170486 dc=exemple,dc=com cn=root,dc=exemple,
dc=com...