Distribution EOLE » Outils Eole » SSO

• Problème
• Proposition
  • LemoLDAP::NG
• Pour tester

Problème¶

Sur Scribe, nous avons deux sources de données qui ne peuvent pas être utilisées ensemble simplement :

• L’annuaire OpenLDAP contient les attributs Envole nécessaires à leur fonctionnement
• L’Active Directory contient le mot de passe et les informations de changement de mot de passe.

Actuellement, eole-SSO et LemonLDAP::NG ne permettent pas une utilisation totalement fonctionnelle des deux sources :

• Soit nous utilisons OpenLDAP et nous n’avons pas les informations d’obligation de changement de mot de passe
• Soit nous utilisons l’Active Directory et nous n’avons pas les attributs Envole

La détection de l’obligation de changement de mot de passe vient du mécanisme des politiques de mot de passe LDAP qui ne peut pas facilement être émulé en synchronisant des attributs de l’active directory vers OpenLDAP (impossible d’ajouter l’attribut pwdLastSet qui n’est défini par aucun schéma LDAP).

Proposition¶

Les solutions SSO devraient, dans le cadre d’un fonctionnement mixte AD / OpenLDAP :

• Tenter d’authentifier l’utilisateur sur l’active directory et détecter le besoin de changement de mot de passe
• Procéder au changement de mot de passe sur l’active directory
• aller chercher les informations utilisateur dans l’OpenLDAP

LemoLDAP::NG¶

Cette solution de SSO permet de combinier des modules, il est ainsi possible de déclarer :

• le module AD pour l’authentification uniquement
• le module LDAP pour les informations utilisateurs
• le module AD pour la gestion du changement de mot de passe

L’inconvénient est que le module d’authentification AD ne fait pas lui même la recherche du DN de l’utilisateur qui est délégué à son parent ce qui ne permet pas d’avoir le même DN pour les deux bases

Un contournement pourrait être de déclarer un module d’authentification personnalisé, dérivé du module AD qui prendrait en charge cette résolution mais il faut vérifier les interactions entre ces modules qui semblent partager la même source de DN:

• https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/blob/master/lemonldap-ng-portal/lib/Lemonldap/NG/Portal/UserDB/LDAP.pm#L37
• https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/blob/master/lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Auth/LDAP.pm#L79

Il semble donc qu’il faille créer un dérivé du module d’authentification (Scribe.pm ?) afin de rechercher le DN de l’AD dans un attribut différent. Peut-être aussi un dérivé du module de changement de mot de passe qui utilise aussi le DN.

Pour tester¶

1. Déployer un aca.scribe-2.8.0-instance-AvecImport
2. Installer le paquet eole-lemonldap-ng-scribe
3. Activer LemonLDAP::NG : CreoleSet activerLemon oui
4. Reconfigurer le serveur
5. Regénérer les certificats pour prendre en compte les noms LemonLDAP::NG : /usr/share/creole/gen_certif.py -f
6. Reconfigurer le serveur
7. Forcer le changement de mot de passe à la prochaine connexion pour un utilisateur
   

   root@scribe:~# SSH_AUTH_SOCK= ssh -t -o IdentitiesOnly=yes addc samba-tool user setpassword --must-change-at-next-login prof1
   New Password: 
   Retype Password: 
   Changed password OK
   Connection to addc closed.
   

8. Depuis le poste du testeur, se connecter à l’adresse https://auth.domscribe.ac-test.fr
9. S’identifier avec le compte prof1 et le mot de passe défini précédemment