web-dev-qa-db-fra.com

pam_mount a cessé de fonctionner

Voici comment cela fonctionnait: mes postes de travail Ubuntu s'authentifient auprès d'Active Directory et pam_mount monte certains répertoires CIFS lors de la connexion de l'utilisateur. Maintenant, pour une raison quelconque, pam_mount a cessé de fonctionner et aucun répertoire n'est monté. J'ai donc activé le débogage de pam_mount et vois ce qui suit:

(rdconf1.c:744): path to luserconf set to
/home/DOMAIN/username/Documents/.pam_mount.conf.xml
(pam_mount.c:365): pam_mount 2.14: entering auth stage
(rdconf1.c:744): path to luserconf set to
/home/DOMAIN/username/Documents/.pam_mount.conf.xml
(pam_mount.c:568): pam_mount 2.14: entering session stage
(pam_mount.c:629): no volumes to mount
command: 'pmvarrun' '-u' 'username' '-o' '1'
(pmvarrun.c:258): parsed count value 0
(pam_mount.c:441): pmvarrun says login count is 1
(pam_mount.c:660): done opening session (ret=0)

Donc, pas de volumes à monter? Mon pam_mount.conf.xml ressemble à ceci:

<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE pam_mount SYSTEM "pam_mount.conf.xml.dtd">
<pam_mount>

<debug enable="1" />
<luserconf name="Documents/.pam_mount.conf.xml" />
<volume user="*" sgrp="residents" fstype="cifs" server="dfs.namespace.com" path="data/users/%(USER)/documents" mountpoint="~/Documents" options="uid=%(USER),gid=100,dir_mode=0700" />
<volume user="*" sgrp="residents" fstype="cifs" server="dfs.namespace.com" path="data/public" mountpoint="~/mount/Public" options="uid=%(USER),gid=100,dir_mode=0700" />

<mntoptions allow="nosuid,nodev,loop,encryption,fsck,nonempty,allow_root,allow_other,uid,gid,dir_mode" />
<mntoptions require="nosuid,nodev,uid,gid,dir_mode" />
<logout wait="0" hup="0" term="0" kill="0" />
<mkmountpoint enable="1" remove="true" />

</pam_mount>

et cette configuration a fonctionné pendant des mois, jusqu'à maintenant. Je ne me souviens pas d’avoir apporté de changement de configuration récemment. Je soupçonne qu'une mise à niveau l'a gâché, car un jour, j'ai remarqué que cela s'était produit sur tous mes postes de travail. Et je ne sais pas où regarder ensuite :( Google n'a pas été vraiment utile.

Dans /var/log/syslog il est écrit:

Apr 23 11:25:54 hostname nslcd[1261]: [86d4c7] <authz="username"> ldap_result() failed: Operations error: 000004DC: LdapErr: DSID-0C0906E8, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db1

mais honnêtement, je vois ces erreurs dans syslog depuis toujours, et comme l'authentification LDAP a bien fonctionné (et le fonctionne toujours), je n'y ai pas prêté beaucoup d'attention. La connexion semble fonctionner correctement dans /var/log/auth.log:

Apr 23 11:43:48 hostname su[10409]: pam_winbind(su:auth): getting password (0x00000388)
Apr 23 11:43:48 hostname su[10409]: pam_winbind(su:auth): pam_get_item returned a password
Apr 23 11:43:49 hostname su[10409]: pam_winbind(su:auth): user 'username' granted access

À part cela, je ne vois rien de pertinent dans /var/log/syslog ou /var/log/auth.log. J'ai Ubuntu 14.04. Je suis assez nouveau sur Linux et j'apprécierais si quelqu'un avait des idées ce que j'essaierais ensuite :)

14.04mountautomountcifspam
1
Aleksiv95

J'ai eu le même problème après quelques mises à jour aujourd'hui. J'ai effectué des tests et constaté que la suppression du paramètre sgrp = "..." du volume leur permettait de monter. Il semble qu'il n'y ait pas de volumes à monter car l'utilisateur ne faisait pas partie du groupe répertorié.

Cela me porte à croire que le problème découle de ce bogue déposé pour la dernière mise à jour de winbind qui affecte les groupes: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1573526

J'ai temporairement supprimé sgrp de mes volumes et ils semblent être en train de monter. Espérons que ce bogue sera résolu et qu'il corrigera correctement ce problème. J'espère que cela t'aides.

UPDATE: Le bogue lié ci-dessus a été corrigé et une mise à jour publiée, mais j'avais toujours le même problème. Winbind ne renvoyait pas les membres du groupe pour un groupe donné (c.-à-d. "Groupe getent" ne renvoyait aucun membre). L'ajout de "winbind expand groupes = 1" à smb.conf a résolu ce problème. Je ne sais pas si cela concerne la nouvelle mise à jour de Winbind ou non, mais mes groupes fonctionnent à nouveau dans pam_mount.conf.xml.

1
chtaylor

Grâce à @chtaylor, j'ai pu résoudre ce problème à l'origine en supprimant l'attribut sgrp de toutes les entrées de pam_mount.conf.xml. Plus tard, j'ai réalisé que l'attribut sgrp ne fonctionne que si le groupe est le groupe principal de l'utilisateur. Ainsi, changer sgrp="residents" en sgrp="domain users" m'a rendu les volumes disponibles à nouveau car domain users est par défaut le groupe principal de tous les utilisateurs AD. Une autre solution serait de changer le groupe principal d'utilisateurs souhaités dans Active Directory afin qu'il corresponde à la configuration pam_mount:

Utilisateurs et ordinateurs Active Directory> allez dans les propriétés de l'utilisateur> Membre de> Définir le groupe principal

0
Aleksiv95