Distribution EOLE » Modules » Scribe » eole-saslauthd

Parmi les éléments de configuration apportés dans le scénario https://dev-eole.ac-dijon.fr/issues/28777#note-5, certains impliquent des choix d’implémentation.

Configuration apparmor¶

Le paquet slapd créé, en postinst, le fichier vide /etc/apparmor.d/local/usr.sbin.slapd. Ce fichier doit être modifié, écrasé, par creole. Le contenu de ce fichier dépendra des options activées. Je vois deux options d’implémentation.

Inclusion au moment du templating¶

Le template apporté par eole-annuaire servirait à inclure les fragments apportés par d’autres paquets (en l’occurrence eole-saslauthd) :

# local usr.sbin.slapd apparmor configuration generated by creole.
%import os
%import re
%set %%slapd_re = re.compile(r'.*usr\.sbin\.slapd.*')
%set %%confdir = '/etc/eole/apparmor.local.d/'
%set %%files = [f for f in %%os.listdir(%%confdir) if %%slapd_re.match(f)]
%%files.sort()
%for file in %%files
%include raw %%confdir + file
%end for

• création du répertoire accueillant les fragments (vraisemblablement dans le packaging d’eole-server, en ajoutant ce répertoire à eole-server.dirs) ;
• chaque paquet apportant un fragment doit se conformer un un nom de fichier spécifique.

Conditions d’inclusion dans le template¶

À chaque ajout de composant, il faut ajouter une condition dans le template apporté par le projet eole-annuaire.

Compte utilisé pour la recherche de DN dans l’annuaire¶

Le compte indiqué dans la configuration de saslauthd n’est utilisé que pour faire l’équivalent d’un ldapsearch. Il ne semble pas judicieux d’utiliser le compte Administrator pour cela étant donné la problématique du mot de passe accessible.

Un compte dédié peut être créé et un système de renouvellement automatisé de son mot de passe, à l’instar de ce qui se fait pour les bases de données, pourrait être un plus (le compte est uniquement utilisé localement et on n’a pas d’impératif de propagation comme ça peut être le cas pour les comptes utilisés par veyon et autres utilitaires sur les clients).

Gestion du compte d’authentification¶

Dans le cadre d’utilisation de saslauthd avec LDAP, il serait très intéressant d’avoir un compte dédié.

Une autre option est de configurer saslauthd pour faire une authentification kerberos5 et non pas LDAP, dans ce cas, il ne faut que le keytab de la machine.

J’ai testé sur un etb1.scribe

1. Installation du paquet
   

   apt install sasl2-bin
   

2. Configuration du service (contrairement à la méthode LDAP il n’y a pas l’option -r)
   

   sed -i -e 's,^START=.*,START=yes,' \
          -e 's,^MECHANISMS=.*,MECHANISMS="kerberos5",' \
          /etc/default/saslauthd
   

3. Forcer la route vers addc.dompedago.etb1.lan car la communication scribe → addc ne fonctionne pas directement
   

   ip route add $(CreoleGet ad_public_address) via $(CreoleGet ad_address)
   

4. Configurer les méthodes kerberos pour Samba
   

   sed -i '/security = ADS/a \\tkerberos method = secrets and keytab' /etc/samba/smb.conf
   

5. Extraire le ketab machine
   

   KRB5_KTNAME=FILE:/etc/krb5.keytab net ads keytab create -P
   

6. Démarrer le service saslauthd
   

   systemctl start saslauthd.service
   

7. Tester l’authentification avec testsaslauthd
   

   testsaslauthd -u admin@DOMPEDAGO.ETB1.LAN -p eole
   0: OK "Success." 
   

8. Adapter la configuration OpenLDAP
   1. Configuration SASL
      

      cat > /etc/ldap/sasl2/slapd.conf <<EOF
      pwcheck_method: saslauthd
      saslauthd_path: /var/run/saslauthd/mux
      EOF
      

   2. L’utilisateur openldap doit faire partie du groupe sasl
      

      adduser openldap sasl
      

   3. Configurer apparmor pour l’accès slapd au socket saslauthd
      

      cat > /etc/apparmor.d/local/usr.sbin.slapd <<EOF
      /{,var/}run/saslauthd/mux rw,
      EOF
      

   4. Redémarrer le service apparmor
      

      systemctl restart apparmor.service
      

   5. Redémarrer le service slapd
      

      systemctl restart slapd.service
      

   6. Modifier le mot de passe du compte admin (attention, les majuscules pour le REALM sont indispensables)
      

      cat > admin.ldif <<EOF
      dn: uid=admin,ou=local,ou=personnels,ou=utilisateurs,ou=00000001,ou=ac-test,ou=education,o=gouv,c=fr
      changetype: modify
      replace: userPassword
      userPassword: {SASL}admin@DOMPEDAGO.ETB1.LAN
      -
      EOF
      

   7. Tester l’authentification en affichant le champs mot de passe
      

      ldapsearch -LLL -x -D uid=admin,ou=local,ou=personnels,ou=utilisateurs,ou=00000001,ou=ac-test,ou=education,o=gouv,c=fr -w eole '(uid=admin)' userPassword | awk '/^userPassword/ {print $2}' | base64 -d; echo
      

Conclusion personnelle¶

• La délégation SASL par kerberos me semble plus facile à gérer pour les machines membres du domaine Active Directory grâce à l’utilisation du keytab de la machine
• Il faut ajouter un script postservice pour tenir le fichier /etc/krb5.keytab à jour
• Pour Scribe, en plus de la configuration spécifique SASL, il faut :
  • Forcer la route vers le conteneur addc pour passer par le bridge (la commande net ads keytab create fait une résolution DNS et ne tient pas compte de /etc/hosts)

=> les éléments laissés en suspend sont repris dans le nouveau scénario : #30106