LDAP Synchronization Connector, LSC, est un logiciel libre (avec des restrictions sur l'usage du nom), programmé en Java et qui mange une configuration en XML, qui permet de synchroniser (créer, modifier, supprimer) le contenu d'un annuaire LDAP (OpenLDAP, Samba 4 AD DC, etc.) depuis tout un tas de sources : un fichier CSV, une base de données, un autre annuaire LDAP, etc.
LSC peut fonctionner selon 3 modes :
lsc -f /etc/lsc -s all
) permet de créer un ou des objets / identités à un instant T en étant sûr qu'ils seront créés sans délai (dans le lsc.xml que l'on mettra dans /etc/lsc, il faut créer autant de tâches qu'il y a de comptes utilisateurs à créer) ;lsc -a all
), LSC synchronise tous les attributs qu'on lui demande de tous les objets qu'on lui demande de surveiller. LSC fait une comparaison complète de l'annuaire (ou d'une branche) puis, si la source est un LDAP, toutes les 5 secondes, il fait une recherche avec le filtre LDAP « (modifyTimestamp>=<maintenant - 5 secondes>) ». Si des objets ont été modifiés dans la source ces 5 dernières secondes, il synchronise les objets correspondants dans la destination ;lsc -c all
) supprime de la destination tout les objets qui ne sont plus dans la source. Oui, même si tu précises « delete » = « true » dans « conditions » dans « propertiesBasedSyncOptions » dans la définition d'une tâche, LSC ne supprimera pas l'objet tant qu'il tournera en mode démon / asynchrone.Nous utilisons LSC pour synchroniser un Samba 4 AD DC (implémentation libre d'un contrôleur de domaine winwin) à partir d'un OpenLDAP. Nous avons besoin d'un contrôleur de domaine, notamment pour intégrer les versions récentes de Windows (Samba 3 / domaine NT 4, c'est mort depuis 10 à 15 ans) et pour intégrer pleinement les NAS modernes (CIFS, NFSv4 authentifié, possibilité pour l'utilisateur de restaurer lui-même ses données ‒ onglet « versions précédentes » dans les propriétés d'un fichier/dossier sous winwin ‒, etc.), mais nous n'avons pas encore envie que Samba 4 devienne le cœur de notre système d'information, on veut qu'il reste en périphérie, qu'il s'occupe uniquement des stations de travail winwin. Une comparaison complète, par un seul thread, entre notre OpenLDAP et notre Samba 4 prend environ 7 minutes pour environ 10 000 objets / identités utilisateur.
Info importante : dans l'Active Directory de Microsoft, et Samba 4 respecte cela, le mot de passe d'un utilisateur est en écriture seule quand on y accède par le protocole LDAP. Autrement dit : le mot de passe étant impossible à lire, il est impossible, pour LSC, de le comparer afin de savoir s'il a changé par rapport à la source. Deux solutions : 1) lorsqu'un utilisateur change son mot de passe, on le change dans Samba 4 AD DC avec samba-tool user setpassword
; 2) lorsqu'un utilisateur change son mot de passe, on pourrait le chiffrer et le mettre dans l'attribut Samba 4 « userPasswordEncrypted » puis la synchronisation (mode démon) de LSC déchiffrerait le mot de passe et le mettrait dans le bon attribut Samba 4 (voir la doc' LSC à ce sujet).
Merci à Seb' d'avoir intégré LSC et d'avoir appuyé le choix Samba 4 AD DC (ça m'aurait bien fait chier de payer M$ pour un contrôleur de domaine). :)