Hello,

L’architecture OpenLDAP est en place depuis plus d’un mois, et voici les quelques retours que j’ai à faire dessus.

Tout d’abord, il me restait une tâche à réaliser, qui était la création d’un compte de service pour la connexion LDAP de chaque application pour remplacer l’utilisation de cn=readonly, mais cela demandais donc du travail supplémentaire à chaque nouvelle application qu’on souhaite utiliser, du coup j’ai décider de créer un seul compte de service avec les droits en lecture seule sur uniquement ou=users et fin de l’histoire :

# Restrict bot.auth to read ou=users
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {3}to dn.subtree="ou=groups,dc=mydom" by dn="cn=bot auth,ou=users,dc=mydom" read by * break
-
add: olcAccess
olcAccess: {3}to dn.subtree="ou=users,dc=mydom" by dn="cn=bot auth,ou=users,dc=mydom" read by * break

J’ai ensuite rencontré un problème sur l’utilisation de Service-Desk, je ne pouvais pas bloquer/débloquer un utilisateur. La cause étant l’absence de droit en écriture sur l’attribut pwdAccountLockedTime (article E03 OpenLDAP - Administration corrigé dans ce sens).

Lorsque j’ai ensuite souhaité retirer mon serveur OpenLDAP historique et migrer toutes les applications sur le nouveau, j’ai tout d’abord rencontré un véritable bug sur le conteneur OpenLDAP, en effet celui-ci cherchait de façon désespéré le certificat TLS sous le nom de ldap.crt (et visible uniquement en mode debug), malgré la présence de la variable d’environnement LDAP_TLS_CRT_FILENAME: custom-cert.crt. Impossible de bypass ce bug, impossible de le reproduire sur d’autres machines, mais reproductible a 100% sur la machine qui nous intérressais… J’ai fini par faire une copie du certificat nommé ldap.crt…

Concernant cette migration, j’ai souhaité que ce nouveau noeud ldap soit uniquement un réplica et non pas un noeud “Master”, pour ce faire, sur le noeud “réplica”, la variable d’environnement ne change pas (LDAP_REPLICATION_HOSTS: "#PYTHON2BASH:['ldap://mynewnode.mydomain.com','ldap://masternode.mydomain.com']", et le simple fait de ne pas rajouter ce nouveau noeud au niveau de cette même variable mais pour le noeud master, suffit à avoir un réplica, celui-ci récupère les changements réalisés sur le Master, mais pas l’inverse. Cette lecture m’a aidée sur le sujet : https://serverfault.com/questions/539432/openldap-recommended-way-to-add-a-new-server-to-a-replicated-multi-master-setup

Enfin, j’ai initié mes tests avec Nextcloud et la nouvelle architecture OpenLDAP. C’est très décevant. Tout d’abord, la connexion en startTLS à un noeud OpenLDAP avec Nextcloud ne fonctionne tout simplement pas. Et pourtant j’ai tout essayé, et pour avoir parcouru l’intégralitée de la documentation administrateur de Nextcloud, je suis certain de n’avoir rien raté. Par contre en LDAPS sur le port 636, cela fonctionne du premier coup, gé-ni-al (ironie hein). Ensuite, des performances scandaleuses, impossible de comprendre d’où vient le problème, et j’ai mis du temps à m’en rendre compte. Les connexions LDAP sans TLS se font sans aucun problème, mais dès qu’on passe en TLS, c’est juste catastrophique. Parfois les performances sont acceptables, et parfois il est carrément impossible de se connecter à Nextcloud… Je pense que l’utilisation d’un s3 en tant que stockage joue beaucoup sur la dégradation des performances, et j’ai de toutes façon décidé de changer cette partie-ci, donc à revoir ultérieurement.

Dernier point, les permissions de l’utilisateur utilisé pour se connecter au serveur OpenLDAP sont juste absurdes, l’application fait des requêtes dans tous les sens, autrement dit, si on n’utilise pas le cn=readonly, impossible de passer le setup LDAP tellement les permissions nécessaires sont élevées (sans que ce soit franchement justifiable). Une issue qui en discute : https://github.com/nextcloud/server/issues/12285

A+