Principe de l'authentification MySQL via libnss-mysql-bg

Les données d'authentification (à savoir UID, login, mot de passe, répertoire personnel, date d'expiration, GID, groupes, etc.) sont stockées sur un serveur MySQL. Ce serveur MySQL est accessible par tous les postes clients.

Lorsqu'un utilisateur veut se connecter sur un poste client, ce dernier vérifie l'authenticité de la personne et la validité du compte (non-expiration) en utilisant les informations du serveur MySQL.

Mise en place

Sur le serveur

1. Mettre en place un serveur MySQL, accessible en IP depuis tous les postes clients qui utilisent l'authentification centralisée. A noter qu'il est conseillé de bien vérifier que le serveur MySQL est configuré dès le départ en utf-8 (voir Etude/Unicode).

2. Créer une base qui contiendra les données d'authentification, nommée par exemple nss. Voici les schémas des tables que nous utilisons à l'AUF :

   • la table users contient la description de chaque compte. Il s'agit des données de /etc/passwd et de /etc/shadow regroupées dans un seul enregistrement. A l'AUF, on y ajoute trois champs supplémentaires (sources, creation, modification) pour savoir d'où vient le compte, à quel moment il a été crée et la date de sa dernière modification.

     • CREATE TABLE `users` (
           `username` varchar(128) NOT NULL PRIMARY KEY,
           `password` varchar(64) NOT NULL,
           `uid` integer NOT NULL UNIQUE,
           `gid` integer NOT NULL,
           `gecos` varchar(128) NOT NULL,
           `homedir` varchar(255) NOT NULL UNIQUE,
           `shell` varchar(64) NOT NULL,
           `lstchg` integer NOT NULL,
           `min` integer NOT NULL,
           `warn` integer NOT NULL,
           `max` integer NOT NULL,
           `inact` integer NOT NULL,
           `expire` integer NOT NULL,
           `flag` integer NOT NULL,
           `source` varchar(10) NOT NULL,
           `creation` datetime NOT NULL,
           `modification` datetime NOT NULL
       );

   • la table groups décrit les groupes systèmes. Il s'agit des données de /etc/groups :

     • CREATE TABLE `groups` (
           `name` varchar(32) NOT NULL UNIQUE,
           `password` varchar(64) NOT NULL,
           `gid` integer AUTO_INCREMENT NOT NULL PRIMARY KEY
       );

   • la table grouplist fait le lien entre les utilisateurs et leur groupes secondaires :

     • CREATE TABLE `grouplist` (
           `id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,
           `gid` integer NOT NULL,
           `username` varchar(128) NOT NULL,
           UNIQUE (`gid`, `username`)
       );

3. Vous pouvez également ajouter des contraintes reliant les tables. Ce n'est pas obligatoire, mais cela fera en sorte que les données resteront cohérentes. Par exemple, un utilisateur ne pourra pas avoir un groupe qui n'existe pas. Voici les quelques contraintes conseillées :

   • ALTER TABLE `users` ADD CONSTRAINT gid_refs_gid_60c371b8 FOREIGN KEY (`gid`) REFERENCES `groups` (`gid`);
     ALTER TABLE `grouplist` ADD CONSTRAINT username_refs_username_5efc4794 FOREIGN KEY (`username`) REFERENCES `users` (`username`);
     ALTER TABLE `grouplist` ADD CONSTRAINT gid_refs_gid_6d7c9cff FOREIGN KEY (`gid`) REFERENCES `groups` (`gid`);

4. Créer des utilisateurs MySQL pour l'accès en lecture à cette base :

   • un utilisateur MySQL pour la lecture des données publiques, c'est-a-dire tout sauf les mots de passe (plus exactement : tout sauf les données correspondantes à /etc/shadow)

   • un autre utilisateur MySQL pour la lecture des données d'authentification, c'est-à-dire toutes les données.

5. Mettre en place les données dans la base. Pour ce faire, tout dépend de votre organisation actuelle :
   • Si vous utilisez déjà un MySQL, adaptez le schéma de votre base actuelle ;
   • Si vous utilisez déjà un autre SGBD, passez à MySQL avec le schéma proposé en 2;
   • Si vous êtes déjà en NIS ou LDAP ou autre, vous pouvez soit migrer les données, soit programmer un script de synchronisations qui sera lancé lors de l'ajout, de la modification ou de la suppression d'un utilisateur.
6. Adaptez vos outils de gestion des comptes à cette base MySQL :

   • installez l'outil AUF de gestion auf-django-users

   • si vous avez déjà un outil plus efficace chez vous, programmez un synchronisateur de ce système vers MySQL (par exemple si vous avez une authentification NIS, laisser le système ajouter l'utilisateur "comme avant" et lancez la synchro juste après)

à ajouter : le script de synchro NIS->MySQL de Jérôme, le script de synchro "pgsql->MySQL" de Montréal (et Paris ?), etc.

Sur les clients

Utilisation du paquet auf-poste-client-fixe

Installez le paquet auf-poste-client-fixe disponible pour Ubuntu (Jaunty et suivantes) dans le dépôt AUF. Il suffit de modifier les données de connexion dans /etc/libnss-mysql.conf et /etc/libnss-mysql-root.conf pour que ça fonctionne.

A la main

1. Installer le paquet libnss-mysql-bg pour que la bibliothèque de résolution de nom (nss = name service switch) sache interroger MySQL.

2. Configurer libnss-mysql-bg dans les deux fichiers /etc/libnss-mysql.cfg et /etc/libnss-mysql-root.cfg. Vous trouverez la documentation et beaucoup d'exemples dans /usr/share/doc/libnss-mysql-bg/. Voici un exemple qui fonctionne avec la base au format AUF décrit ci-dessus :

   # Exemple de fichier /etc/libnss-mysql.cfg 
   # Pour chaque type de donnée on écrit la requete SQL correspondante... Facile. Souple. Efficace.
   getpwnam    SELECT username,'x',uid,gid,gecos,homedir,'/bin/bash' \
               FROM users \
               WHERE username= binary '%1$s' \
               LIMIT 1
   getpwuid    SELECT username,'x',uid,gid,gecos,homedir,'/bin/bash' \
               FROM users \
               WHERE uid='%1$u' \
               LIMIT 1
   getspnam    SELECT username,password,lstchg,min,max,warn,inact,expire,flag \
               FROM users \
               WHERE username= binary '%1$s' \
               LIMIT 1
   getpwent    SELECT username,'x',uid,gid,gecos,homedir,'/bin/bash' \
               FROM users
   getspent    SELECT username,password,lstchg,min,max,warn,inact,expire,flag \
               FROM users
   getgrnam    SELECT name,password,gid \
               FROM groups \
               WHERE name='%1$s' \
               LIMIT 1
   getgrgid    SELECT name,password,gid \
               FROM groups \
               WHERE gid='%1$u' \
               LIMIT 1
   getgrent    SELECT name,password,gid \
               FROM groups
   memsbygid   SELECT username \
               FROM grouplist \
               WHERE gid='%1$u'
   gidsbymem   SELECT gid \
               FROM grouplist \
               WHERE username= binary '%1$s'
   
   host        123.45.67.89    <-- mettre une IP et pas un nom de machine
   database    authnss
   username    nsslire         <-- utilisateur ayant les accès en lecture sur les données publiques
   password    fautpasrever
   timeout     3
   compress    0

   # Exemple de fichier /etc/libnss-mysql-root.cfg
   # on indique uniquement l'utilisateur ayant accès aux données d'authentification
   # (en gros le mot de passe, l'expiration, etc : comme pour /etc/shadow)
   username    nssroot
   password    ktchrootuut

3. Activer le module mysql de NSS :

   # (... extrait de /etc/nsswitch.conf pour y ajouter mysql ...)
   passwd:         files mysql
   group:          files mysql
   shadow:         files mysql

4. Installer nscd (nscd = name service cache daemon) pour que le système garde en mémoire les données de connexion, afin d'éviter de faire des requêtes MySQL sans arrêt... et fasse tout planter !

5. Petit bug avec le déverrouillage d'écran : faire un sudo chmod u+s /sbin/unix_chkpwd pour autoriser la vérification des mots de passe pour le déverrouillage de l'écran.

6. Et à partir de là, ça doit marcher...

Note : les groupes peuvent être indiqués dans la base MySQL centrale, mais cela peut vite être fastidieux. Vous préférerez sans doute la technique indiquée sur la page GestionDesGroupes, plus souple dans le cadre des postes clients.

Que faire lorsque « ça ne marche pas »

Attention !! Il ne faut pas confondre la phase d'authentification (libnss) avec l'accés aux fichiers (NFS). Si l'erreur se produit aprés l'authentification, et se présente sous quelquechose de la forme d'une petite fenêtre «Votre dossier personnel est censé être "/home/xxxx" mais il semble ne pas exister», c'est plutôt sur l'infrastructure NFS qu'il faudra se pencher.

Est-ce que le problème se pose pour tous les comptes ou pour quelques comptes seulement ?

• pour tous les comptes : vérifier l'infrastructure d'authentification en général (voir plus bas)

• pour tous les comptes, mais pas systématiquement : sans doute une saturation du nombre de processus MySQL

• certains comptes seulement : vérifier la configuration de ces comptes en particulier, dans la base MySQL

Sur le serveur, vérifier les points suivants

• Le serveur MySQL fonctionne-t-il ?

• La base/table d'authentification contient-elle un nombre d'entrées réaliste par rapport aux valeurs habituelles ?

  • nfs-dakar:~# mysql authnss -Be "select count(*) from users"
    count(*)
    1508

• Combien de processus actuellement utilisés sur le serveur, et est-ce cohérent avec la variable max_connections définie dans /etc/mysql/my.cnf ?

  • nfs-dakar:~# mysql -B -e "show processlist" | wc -l
    35
    nfs-dakar:~# mysql -B -e "show processlist" | grep authnss | wc -l
    33
    nfs-dakar:~# mysql -B -e "show variables" | grep max_connections
    max_connections 300

Sur le poste client, vérifier les points suivants

• Rappel : les logs de connexions sont dans /var/log/auth.log`

• L'utilisation du système de cache nscd peu géner les tests, car il conserve quelques minutes les informations au lieu de reposer la question à MySQL. Vous pouvez éventuellement arrêter nscd, uniquement le temps des tests.

• Les commandes getent donnent-elles des informations réalistes ? getent passwd | wc -l devrait donner une valeur du même ordre de grandeur que celle données par le select count(*) sur le serveur. Bien faire la vérification pour les tables passwd, shadow et group

• Le système de cache nscd fonctionne-t-il ?

• Les fichiers de configurations sont-ils bien présents et bien configurés (/etc/libnss-mysql.cfg et /etc/libnss-mysql-root.cfg) ? Vérifiez bien les deux.

• Est-il effectivement possible de se connecter au serveur MySQL depuis le client, en ligne de commande, avec les paramétres donnés dans les fichiers de configuration ? Essayer en faisant des copier/coller des hostname/login/password des fichiers /etc/libnss-mysql* : il faut toujours se méfier de fautes de frappes. Vérifiez bien avec les comptes MySQL des deux fichiers.

• /etc/nsswitch.conf est-il comme il devrait être, avec mysql juste après files pour les données password, group et shadow ?

• Est-ce que le /etc/init.d/nscd restart a bien été lancé avant de faire les premiers tests ?

• Pas de messages alarmant lors d'une analyse des logs ? Que donne un grep libnss-mysql /var/log/daemon.log ?

Autres utilisations

Le fait de posséder une base MySQL contenant les informations d'authentification vous simplifiera la vie sur vos autres soucis d'authentification. En effet cette base peut être utilisée :

• par libnss-mysql-bg, comme nous venons de le voir ;

• par toutes les applications qui savent directement faire une authentification MySQL (lorsque la requête d'authentification est configurable) ;

• par des systèmes qui savent utiliser PAM, via le module libpam-mysql ;

• peut-être un jour en LDAP via une interrogation en perl et le backend slapd-perl (un exemple ici)

• par toutes les applications dont l'authentification est «scriptable», car il est en général très simple de faire une interrogation MySQL, quel que soit le langage de l'application (Perl, Python, PHP, shell : nous savons faire).