Distribution EOLE » Modules » Scribe » eole-ad

L’infrastructure cible n’est pas suffisamment claire.
eole-ad était auparavant utilisé sur un scribe (2.5 et 2.6). En 2.7, le passage à samba 4 devait le rendre inutile pour les problèmes de synchronisation qui se ferait dorénavant d’annuaire AD à annuaire AD. Le scribe 2.7 utilise eole-lsc pour faire le lien entre un openldap, servant toujours de base de compte pour les outils web, et un annuaire AD placé dans un conteneur. C’est le cas fonctionnel d’après la description du scénario.

Quel est l’autre cas d’utilisation (quel module, comment reconstruire l’infrastructure) ?

• modèle ScribeAD : OpenLDAP -> AD (dans le conteneur addc, d'où l'ajout d'un code spécifique pour attendre le conteneur)
• modèle Eole-AD : OpenLDAP -> AD (Seth ou Microsoft, test d'accès uniquement)

En 2.7.2, le modèle Eole-AD est utilisable nativement sur ScribeAD grâce à la nouvelle variable ad_local (=> "non") #29860

Le test jenkins a été forké dans ce sens : https://dev-eole.ac-dijon.fr/jenkins/job/2.7.2/job/test-seth-eolead-aca-2.7.2-amd64/

Si eole-ad est la partie générique, qui doit fonctionner indépendamment de l’emplacement de l’annuaire AD, il semblerait plus logique de déplacer eole-wait-addc et le script waitaddc avec le dictionnaire 25_eolead_container.xml.
Ou alors rassembler la variable ad_local et le service eole-wait-addc, au moins.

De là, la variable ad_local permettrait d’activer ou non le service eole-wait-addc. Pour finir, une dépendance de type Wants plutôt que Requires permettrait de démarrer eole-lsc même si eole-wait-addc est masqué.

Testé sur un Scribe 2.7.2 avec le fichier de configuration proposé par Joël (ad_local à non, notamment).
Il faut également penser à intégrer le certificat racine servant à valider le certificat utilisé par samba pour le ldaps

ssh 192.168.0.5:/var/lib/samba/private/tls/ca.pem /usr/local/share/ca-certificates/dc1-samba_ca.crt
update-ca-certificates