Principe

Les données d'authentification (à savoir UID, login, mot de passe, répertoire personnel, date d'expiration, GID et groupes) sont stockées sur un serveur MySQL.

Lorsqu'un utilisateur veut se connecter sur un poste client, celui-ci ira vérifier l'authenticité de la personne, en vérifiera l'activation (non-expiration) et si tout va bien connectera la personne avec les bons UID, GID, homedir, etc.

parler de guia et Projet/GUIA/Greffons/NssMySQL

Mise en place

Sur le serveur

1. Mettre en place un serveur MySQL accessible depuis tous les postes clients qui utiliseront l'authentification centralisée.

2. Créer une base qui contiendra les données d'authentification (par exemple authnss). Nous conseillons fortement l'utilisation du schéma prévu par le projet GUIA, disponible ici : http://trac.sn.auf.org/guia/browser/trunk/guia/noyau/greffons/NSSMySQL/bases/auth.sql

   CREATE TABLE `users` (
     `username` varchar(64) NOT NULL,
     `uid` int(11) NOT NULL auto_increment,
     `gid` int(11) NOT NULL default '5000',
     `gecos` varchar(128) NOT NULL default '',
     `homedir` varchar(255) NOT NULL default '',
     `shell` varchar(64) NOT NULL default '/bin/bash',
     `password` varchar(34) NOT NULL default 'x',
     `lstchg` bigint(20) NOT NULL default '1',
     `min` bigint(20) NOT NULL default '0',
     `max` bigint(20) NOT NULL default '99999',
     `warn` bigint(20) NOT NULL default '0',
     `inact` bigint(20) NOT NULL default '0',
     `expire` bigint(20) NOT NULL default '-1',
     `flag` bigint(20) unsigned NOT NULL default '0',
     `id_noyau` int(11) NOT NULL,  # pour le futur (défini la source de provenance du compte : système, GUIA, autre implantation, etc)
     PRIMARY KEY  (`uid`),
     UNIQUE KEY `username` (`username`),
     KEY `uid` (`uid`)
   );
   
   CREATE TABLE `groups` (
     `name` varchar(16) NOT NULL default '',
     `password` varchar(34) NOT NULL default 'x',
     `gid` int(11) NOT NULL auto_increment,
     PRIMARY KEY  (`gid`)
   );
   
   CREATE TABLE `grouplist` (
     `rowid` int(11) NOT NULL auto_increment,
     `gid` int(11) NOT NULL default '0',
     `username` char(16) NOT NULL default '',
     `date_fin` datetime default NULL,
     `date_debut` datetime default NULL,
     `suspendu` tinyint(1) default NULL,
     PRIMARY KEY  (`rowid`)
   );

3. Créer des utilisateurs MySQL pour l'accès en lecture à cette base :
   • un utilisateur MySQL pour la lecture des données publiques, genre /etc/passwd et /etc/group ;
   • un autre utilisateur MySQL pour la lecture des données d'authentification (/etc/shadow) ;
   • si vous voulez aller vite et ne pas trop vous casser la tête, dans un premier temps vous pouvez créer un seul utilisateur ayant accès à toutes les données... vous pourrez affiner les droits par la suite.
4. 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, étudiez l'adaptation du schéma de votre base actuelle ;
   • Si vous utilisez déjà un autre SGBD, regardez si vous ne pouvez pas en changer et passer à MySQL avec le schéma proposé ;

   • Si vous êtes déjà en NIS ou LDAP ou autre, étudier l'écriture d'un script de synchronisation que vous pourrez lancer soit de façon générale de temps en temps (via cron), soit plus finement lors de l'ajout, de la modification ou de la suppression d'un utilisateur.

5. Adaptez vos outils de gestion des comptes à cette base MySQL. Eventuellement vous pouvez là aussi utiliser un synchronisateur (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

voir http://trac.sn.auf.org/auf-desktop/browser/trunk/auf-desktop/debian/postinst et le contenu de racine-gutsy/etc/

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 colle avec la base au schéma GUIA :

   # 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. et à partir de là, ça doit marcher... non ?

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.

Points à vérifier

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 :

• 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 dans le /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 client, vérifier les points suivants :

• Les commandes getent donnent-elles des informations réalistes ? gentent 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 passwd, shadow et group

• nscd fonctionne-t-il ?

• Les fichiers de configurations sont-ils bien présents ? /etc/libnss-mysql.cfg et /etc/libnss-mysql-root.cfg ?

• 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 au besoin, pour se méfier de fautes de frappes un peu traîtres

• /etc/nsswitch.conf est-il comme il devrait être ?

• Est-ce que le /etc/init.d/nscd restart n'as pas été un peu oublié 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 ;

• bientôt en LDAP si, si via une interrogation en perl et le backend slapd-perl (exemple)

• 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).

Notes de bas de page :