Les groupes diffèrent des groupes locaux lors de la connexion à distance

14

Nous stockons nos utilisateurs dans LDAP, aux côtés de certains groupes qui ont un sens sur différents systèmes (rôles organisationnels notamment wheel). Il existe également des groupes locaux sur les postes de travail, par exemple audioou videoqui ne sont pas souhaitables pour être placés dans LDAP. Maintenant, si je me connecte localement, j'obtiens ces groupes locaux, mais si je me connecte via SSH sur la même machine, je n'en ai pas. Ils reviennent bien sûr, si j'utilise sujuste après. Je me trompe peut-être, mais je soupçonne PAM.

Entrées pertinentes de nsswitch.conf

passwd:      compat ldap
shadow:      compat ldap
group:       compat ldap

Quant à pam, toujours la ligne d'authentification, mais les autres lignes sont les mêmes

/etc/pam.d/sshd

auth            include         system-remote-login

/etc/pam.d/system-remote-login(identique à system-local-loginje pourrais ajouter)

auth            include         system-login

/etc/pam.d/system-login

auth            required        pam_tally2.so onerr=succeed
auth            required        pam_shells.so 
auth            required        pam_nologin.so 
auth            include         system-auth
auth            optional        pam_gnome_keyring.so

account         required        pam_access.so 
account         required        pam_nologin.so 
account         include         system-auth
account         required        pam_tally2.so onerr=succeed 

password        include         system-auth
password        optional        pam_gnome_keyring.so

session         optional        pam_loginuid.so
session         required        pam_env.so 
session         optional        pam_lastlog.so 
session         include         system-auth
session         optional        pam_gnome_keyring.so auto_start
session         optional        pam_motd.so motd=/etc/motd
session         optional        pam_mail.so

/etc/pam.d/su 

auth       sufficient   pam_rootok.so
auth       required     pam_wheel.so use_uid
auth       include              system-auth

account    include              system-auth

password   include              system-auth

session    include              system-auth
session    required     pam_env.so
session    optional             pam_xauth.so

/etc/pam.d/common-auth:

auth    required     pam_group.so use_first_pass

Quel pourrait être le problème et comment pourrais-je le résoudre? Je suis heureux de fournir d'autres informations nécessaires.

ssh group authentication pam ldap Max
la source
A quoi /etc/nsswitch.confressemble votre look group? Quelle est la sortie de getent YOURUSERNAME? Votre /etc/pam.d/sshd@include commun {session, authentification, mot de passe, compte}?
eppesuig
quel processus / étapes vous configurez côté client?
Rahul Patil
1
@Aurelien, quand vous avez "shadow ldap", alors pam_unix fait l'authentification en récupérant les informations de mot de passe de nss.
Stéphane Chazelas
1
Je pense que vous êtes hors de piste en soupçonnant PAM. Plus probablement un problème NIS. PAM n'a aucune idée des groupes; tout est fait via libc lorsque sshd appelle initgroups.
Nicholas Wilson
1
En fait, je modifie légèrement cela: apparemment, certains modules accrochent l'appel pam_setcred pour établir des groupes d'utilisateurs, c'est pourquoi sshd appelle initgroups avant pam_setcred. Hmmm.
Nicholas Wilson

Réponses:

3

J'ai pris courage aujourd'hui et l'ai finalement résolu. La chaîne pam fonctionne comme ceci

  • /etc/pam.d/sshd comprend:
    • /etc/pam.d/system-remote-login qui comprend:
      • /etc/pam.d/system-login qui comprend:
        • /etc/pam.d/system-auth qui a une exigence facultative

Apparemment, le dernier inclus ne fonctionne pas pour une raison quelconque. La raison pour laquelle j'étais si perplexe jusqu'à présent était que j'avais confiance que ces inclusions fonctionneraient, ce qui n'était pas le cas. Si quelqu'un peut expliquer pourquoi je serais très reconnaissant. Je le sais parce que si j'ajoute la ligne

auth    optional  pam_group.so

dans le /etc/pam.d/system-loginpuis ça fonctionne.

Max
la source
1

Le programme de connexion (qui configure votre environnement, y compris l'UID, le GID et les groupes supplémentaires) obtient des données sur le nom d'utilisateur <--> UID, GID et les groupes supplémentaires auxquels appartient le nom d'utilisateur, à partir d'une sorte de base de données. Traditionnellement à partir des fichiers / etc / passwd et / etc / groups, aujourd'hui également à partir de LDAP. Selon la source de données, les groupes qui vous sont attribués peuvent varier.

Attention, si différentes sources sont mélangées, vous pouvez très bien vous retrouver avec un compte du même nom mais avec des UID différents (le système utilise vraiment UID en interne), ou différents ensembles de groupes. Le résultat est normalement très divertissant pour le spectateur occasionnel, tout en conduisant à une calvitie prématurée en raison de la coupe de cheveux importante pour les parties en charge. (Été là.)

vonbrand
la source
0

Dans nsswitch.conf: 

    groupe: compat ldap

afaik cela appelle getgrent, qui obtient les groupes (entrées de groupe)

EDIT: une autre chose est d'ajouter ce qui suit à /etc/pam.d/common-auth: 

auth requis pam_group.so use_first_pass

pour plus d'informations jetez un œil ici: Assignez des groupes locaux aux utilisateurs et peut-être ce newgrp-and-groups-assigned-via-pam-group-so

xx4h
la source
Cette ligne est déjà présente comme ça.
Max
peut-être l'ajouter à "Entrées pertinentes de nsswitch.conf" dans votre question.
xx4h
fait et l'édition n'a pas aidé malheureusement.
Max
avez-vous fait pam-auth-updateet un redémarrage nscd?
xx4h
0

J'ai eu un problème presque similaire: lors de la connexion à l'aide de ssh, certains groupes manquaient. Il a été résolu en changeant /etc/nsswitch.conf:

group:      compat  -> group:      files nis
Jean-Francois Bocquet
la source