DEBIAN 6 - Authentification centralisée users en base mysql

Version imprimable

31/01/2013, 08h22
VILLARICA

DEBIAN 6 - Authentification centralisée users en base mysql

Bonjour à tous,

J'espère être dans la bonne partie du forum ...

Je vous explique le soucis qui me fait m'arracher les cheveux :calim2: depuis quelque jours :

Mon boss m'a demandé de mettre en place un système d'authentification des utilisateurs centralisée, avec pour contrainte la non utilisation de OpenLDAP ou autre système d'annuaire. La solution retenue est donc le stockage des utilisateurs dans une base mysql.

Après recherches sur mon ami google, j'a suivi les instructions sur ce tuto, assez bien fait :

Config du serveur mysql : http://www.ixany.org/docs/NSS-PAM_My...nfig_Base.html

Config du serveur client sur lequel les utilisateurs vont se connecter :
http://www.ixany.org/docs/NSS-PAM_My...ig_Client.html

Aucun problème particulier pour suivre les tutos et installer les serveurs.

Là ou cela se gate :

+ je tente une connexion ssh en tant que root sur le serveur (client) => OK, cela fonctionne, root est localement connu sur le système.

+ Je tente une connexion avec un utilisateur stocké dans la base MySql => je me fais jetter par le serveur.

Persévérant, je me reconnecte en root sur le serveur client, et je tente un
su seb (seb étant mon utilisateur de test stocké dans le bdd mysql), et là, le serveur me répond :

Votre compte a expiré, contactez votre administrateur système.
su : echec d'authentification (ignoré)
seb@ssosrv:/root$

Je bloque sur ce problème, je ne sais plus ou chercher pour trouver une solution en rapport avec cette histoire de compte expiré.

Merci de votre aide.

Sébastien.

Salut,

Et bien vu que tes utilisateurs sont stockés en DB, j'irais d'abord voir à ce niveau là dans la table user.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
  CREATE TABLE user (
      user_id int(11) NOT NULL auto_increment primary key,
      user_name varchar(50) DEFAULT '' NOT NULL,
      realname varchar(32) DEFAULT '' NOT NULL,
      shell varchar(20) DEFAULT '/bin/sh' NOT NULL,
      password varchar(40) DEFAULT '' NOT NULL,
      status char(1) DEFAULT 'N' NOT NULL,
      uid int(11) NOT NULL,
      gid int(11) DEFAULT '65534' NOT NULL,
      homedir varchar(32) DEFAULT '/bin/sh' NOT NULL,
      lastchange varchar(50) NOT NULL default '',
      min int(11) NOT NULL default '0',
      max int(11) NOT NULL default '0',
      warn int(11) NOT NULL default '7',
      inact int(11) NOT NULL default '-1',
      expire int(11) NOT NULL default '-1'
     );

31/01/2013, 11h57
VILLARICA

Bonjour Mygale 1978,

Merci pour ta réponse, j'ai tenté différentes valeurs, mais rien ne change.

Peut-être une autre idée ?

Merci.
31/01/2013, 12h23
Invité

Activer le debugging et voir ce qu'il se passe dans les logs.

Citation:

Debugging et mode verbeux

Même si la configuration de PAM est prise en compte rapidement (il faut généralement tout de même redémarrer les services tournant sur la machine après modification de la configuration PAM), mieux vaut redémarrer le serveur pour s’assurer que tout fonctionne encore correctement (attention à pouvoir toujours vous connecter).

En cas de problème, il est possible d’activer le mode verbeux des différents types de services en passant l’argument verbose à 1. Les logs sont alors visibles dans le fichier /var/log/auth.log.

Exemple de fichier de configuration /etc/pam-mysql.conf :

Citation:

## décommenter pour activer les logs (vers auth.log)
# verbose = 1
31/01/2013, 12h35
VILLARICA

Les logs étaient déjà actives, j'avais effectivement décommenté la ligne Verbose
du fichier.

Dans les logs, je trouve :

Jan 31 11:55:37 ssosrv su[1317]: pam_unix(su:account): account seb has expired (account expired)
Jan 31 11:55:37 ssosrv su[1317]: Successful su for seb by root
Jan 31 11:55:37 ssosrv su[1317]: + /dev/tty1 root:seb
Jan 31 11:55:37 ssosrv su[1317]: pam_unix(su:session): session opened for user seb by root(uid=0)

Mais là, ça ne me parle pas du tout ....
01/03/2013, 18h07
Sourezo

Salut,

Ton problème n'est peut-être plus d'actualité, mais tant pis, ma réponse pourra peut-être servir quand même à quelqu'un.

La ligne « pam_unix(su:account): account seb has expired (account expired) » indique que le compte a expiré, comme le dit Mygale1978, probablement à cause de la valeur du champ expire de la table users. Ce champ fournit la date d'expiration du compte en nombre de jours depuis le 1er janvier 1970.

Tu peux vérifier les valeurs retournées sur ton serveur par le système NSS pour cet utilisateur avec la commande (à lancer par root):

Citation:

getent shadow seb

Dans ton cas, tu dois avoir une valeur comprise entre 0 et 15765 (pour aujourd'hui), puisque le système considère ton compte comme expiré. Si ce n'est pas la même valeur que celle de la base de données, alors c'est qu'il y a un problème avec les requêtes que tu as mises dans /etc/libnss-mysql.cfg, en particulier pour les fonctions getspnam et getspent qui fournissent une valeur pour le champ expire. Si c'est bien la même valeur, alors changes-en: une valeur de -1 devrait a priori débloquer le compte et résoudre ton problème.

Note que lorsque la valeur est -1 dans la base (c'est la valeur fournie par défaut pour ce champ dans l'exemple donné par les auteurs de nss-mysql), alors le champ renvoyé par getent est vide, ce qui indique que le compte n'est jamais considéré comme expiré.