Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

We store our users in LDAP, alongside some groups that have meaning across different systems (organizational roles including wheel). There are also groups local to workstations, e.g. audio or video that are not desirable to be put into LDAP. Now if I log in locally I get those local groups, but if I log in via SSH into the same machine I lack them. They of course come back, if I use su straight afterwards. I may be on the wrong track, but suspect PAM.

Relevant entries from nsswitch.conf

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

As for pam, always the auth line, but the other lines are the same

/etc/pam.d/sshd

auth            include         system-remote-login

/etc/pam.d/system-remote-login (identical to system-local-login I might add)

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

What could be the problem and how would I solve it? I'm happy to provide other information needed.

share|improve this question
    
What does your /etc/nsswitch.conf looks like for group? What is the output of getent YOURUSERNAME? Does your /etc/pam.d/sshd @include common-{session,auth,password,account}? –  eppesuig Jan 4 '13 at 13:23
    
which process/steps you setup at client end ? –  Rahul Patil Jan 4 '13 at 13:31
1  
@Aurelien, when you have "shadow ldap", then pam_unix does the authentication retrieving the password info from nss. –  Stéphane Chazelas Jan 17 '13 at 15:29
1  
I think you're off track suspecting PAM. More likely a NIS problem. PAM has no idea of groups at all; it's all done through libc when sshd calls initgroups. –  Nicholas Wilson Jan 19 '13 at 11:27
1  
Actually, I slightly modify that: apparently some modules hook the pam_setcred call to establish user groups, which is why sshd calls initgroups before pam_setcred. Hmmm. –  Nicholas Wilson Jan 19 '13 at 12:29

4 Answers 4

The login program (which sets up your environment, including UID, GID and supplemental groups) gets data on username <--> UID, GID and the supplementary groups to which username belongs, from some sort of database. Traditionally from the /etc/passwd and /etc/groups files, today also from LDAP. Depending on the data source, the groups you get assigned can vary.

Be careful, if different sources are mixed you can very well end up with an account with the same name but different UIDs (the system really uses UID internally), or different sets of groups. The result is normally very entertaining for the casual onlooker, while leading to premature baldness due to extensive hair-pulling for the parties in charge. (Been there.)

share|improve this answer

Into nsswitch.conf:

    group:          compat ldap

afaik this calls getgrent, which gets the groups (group entries)

EDIT: another thing is to add the following to /etc/pam.d/common-auth:

auth    required     pam_group.so use_first_pass

for more information have a look here: Assign local groups to users and maybe this newgrp-and-groups-assigned-via-pam-group-so

share|improve this answer
    
That line is already present just like that. –  Max Feb 14 '13 at 11:02
    
maybe add it to "Relevant entries from nsswitch.conf" in your question. –  xx4h Feb 14 '13 at 18:08
    
done and the edit didn't help unfortunately. –  Max Feb 14 '13 at 18:45
    
did you do pam-auth-update and a nscd restart? –  xx4h Feb 14 '13 at 19:14
up vote 0 down vote accepted

I took heart today and finally solved it. The pam chain works like this

/etc/pam.d/sshd includes
/etc/pam.d/system-remote-login includes
/etc/pam.d/system-login includes
/etc/pam.d/system-auth which has an optional requirement

Apparently the last include does not work for some reason. The reason why I was so puzzled so far was that I trusted that these includes would work, which wasn't the case. If someone can explain why I'd be very grateful. I know this because if i add the line

auth    optional  pam_group.so

into the /etc/pam.d/system-login then it works. I really hope this helps someone.

share|improve this answer

I had an almost similar problem: when logged in using ssh, some groups were missing. It has been solved by changing /etc/nsswitch.conf:

group:      compat  -> group:      files nis
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.