[opensuse] Locked out by PAM
Hi We have a client where only students in group year11 should be able to login. I keep getting locked out with this: account required pam_succeed_if.so user ingroup year11 getent group year11 lists members correctly. I've tried this: http://serverfault.com/questions/483643/linux-pam-pam-succeed-if-so But it fails. I think because we're using sssd and I don't know the correct order. The position in the stack seems to matter. Here is ours: account requisite pam_unix.so try_first_pass account sufficient pam_localuser.so account required pam_sss.so use_first_pass auth required pam_env.so auth optional pam_gnome_keyring.so auth sufficient pam_unix.so try_first_pass auth required pam_sss.so use_first_pass session required pam_limits.so session required pam_unix.so try_first_pass session optional pam_sss.so session optional pam_umask.so session optional pam_systemd.so session optional pam_gnome_keyring.so auto_start only_if=gdm,gdm-password,lxdm,lightdm session optional pam_env.so If I try and authenticate, I do not even get a password prompt: 2013-09-01T11:22:14.438159+02:00 hh16 su: pam_xauth(su:session): error creating temporary file `/home/users/lynn2/.xauthXPkISk': No such file or directory This leads me to believe that it must come after the pam_sss.so line since I can see that sssd has (correctly) identified me as it knows my home directory. I have to remove the line I'm testing in a second root shell, whereupon I can login normally: 2013-09-01T11:43:34.642148+02:00 hh16 su: pam_unix(su:auth): authentication failure; logname=lynn uid=1000 euid=0 tty=pts/2 ruser=lynn rhost= user=lynn2 2013-09-01T11:43:35.371140+02:00 hh16 su: pam_sss(su:auth): authentication success; logname=lynn uid=1000 euid=0 tty=pts/2 ruser=lynn rhost= user=lynn2 2013-09-01T11:43:35.373290+02:00 hh16 su: (to lynn2) lynn on /dev/pts/2 2013-09-01T11:43:35.431413+02:00 hh16 su: pam_unix(su:session): session opened for user lynn2 by lynn(uid=1000) It's the same if I try logging in on another tty rather than su. Is there a pam-config way of adding this? Anyone? Thanks L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
some comments (some maybe irrelevant, but some that might be...) lynn wrote:
auth required pam_env.so <--- 1st access to your net when login vector is available auth optional pam_gnome_keyring.so auth sufficient pam_unix.so try_first_pass auth required pam_sss.so use_first_pass session required pam_limits.so session required pam_unix.so try_first_pass session optional pam_sss.so session optional pam_umask.so session optional pam_systemd.so session optional pam_gnome_keyring.so auto_start only_if=gdm,gdm-password,lxdm,lightdm session optional pam_env.so <---- sessions: can be many, but login vector is no longer available
A few Q's I had: 1: what do you use pam_env for? The examples that are included show it being used for setting REMOTEHOST (holding where you locked in from), and from that, setting DISPLAY to point to the real 'remotehost' that you want your display redirected to. CAUTION:, if your session is NOT over a private ethernet, then you likely want your DISPLAY traffic encrypted, and forwarding through ssh is advised, but if you are on a private net, not having 'X' go through ssh can give a 3-5X performance boost depending on the speed your net and cpu's. Given the above caution, if you want to keep your path to your original host open, calling pam_env.so as part of session (a bug as far as I'm concerned, -- added in 12.2 or .3, I believe). 2) Do you really want all that extra stuff to be "optional" in "session". Your "pam_sss" handles auth -- I have In my common auth, I have: auth optional pam_env.so auth sufficient pam_winbind.so auth required pam_unix.so try_first_pass in common session, I have session optional pam_umask.so #session optional pam_env.so debug #from debugging losing my DISPLAY... session required pam_limits.so session sufficient pam_winbind.so ### might pam_sss be sufficient session required pam_unix.so try_first_pass ## (and before pam_unix) Is systemd optional for your sessions to work? Should it be listed as "required" or "requisite". As for the ordering on the lines in your "auth" section... You have the opposite of what I have -- i.e. pam_unix you have as sufficient (should it be? it might not process or get to your pam_sss -- i.e. it looks like your local accounts can override whatever "sss" says (which may be what you want, dunno). Justification for my choice: local access trumps a failing winbind, so while winbind (or sss in your casE) is sufficient, if it isn't there, it's like local-login. Whereas in yourcase, it looks like if local-login works, then don't require or bother with network lookups Don't know about the other details, but thought I'd point out mine, as I can see similarities... Good luck! -linda -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, 2013-09-04 at 23:43 -0700, Linda Walsh wrote:
some comments (some maybe irrelevant, but some that might be...)
lynn wrote:
auth required pam_env.so <--- 1st access to your net when login vector is available auth optional pam_gnome_keyring.so auth sufficient pam_unix.so try_first_pass auth required pam_sss.so use_first_pass session required pam_limits.so session required pam_unix.so try_first_pass session optional pam_sss.so session optional pam_umask.so session optional pam_systemd.so session optional pam_gnome_keyring.so auto_start only_if=gdm,gdm-password,lxdm,lightdm session optional pam_env.so <---- sessions: can be many, but login vector is no longer available
A few Q's I had: 1: what do you use pam_env for?
Geez. That's a tough one. I've no idea I'm afraid. This pam config has evolved since installation. I've not changed anything so it must be what openSUSE has decided is good.
The examples that are included show it being used for setting REMOTEHOST (holding where you locked in from), and from that, setting DISPLAY to point to the real 'remotehost' that you want your display redirected to. CAUTION:, if your session is NOT over a private ethernet, then you likely want your DISPLAY traffic encrypted, and forwarding through ssh is advised, but if you are on a private net, not having 'X' go through ssh can give a 3-5X performance boost depending on the speed your net and cpu's.
Given the above caution, if you want to keep your path to your original host open, calling pam_env.so as part of session (a bug as far as I'm concerned, -- added in 12.2 or .3, I believe).
2) Do you really want all that extra stuff to be "optional" in "session".
Your "pam_sss" handles auth -- I have In my common auth, I have: auth optional pam_env.so auth sufficient pam_winbind.so auth required pam_unix.so try_first_pass
in common session, I have
session optional pam_umask.so #session optional pam_env.so debug #from debugging losing my DISPLAY... session required pam_limits.so session sufficient pam_winbind.so ### might pam_sss be sufficient session required pam_unix.so try_first_pass ## (and before pam_unix)
Is systemd optional for your sessions to work? Should it be listed as "required" or "requisite".
As for the ordering on the lines in your "auth" section...
You have the opposite of what I have -- i.e.
Again, it's what evolved. Interestingly, sssd is our replacement for winbind. It really helps on old hardware.
pam_unix you have as sufficient (should it be? it might not process or get to your pam_sss -- i.e. it looks like your local accounts can override whatever "sss" says (which may be what you want, dunno).
Justification for my choice: local access trumps a failing winbind, so while winbind (or sss in your casE) is sufficient, if it isn't there, it's like local-login.
Whereas in yourcase, it looks like if local-login works, then don't require or bother with network lookups
Yeah, that makes sense. We have: nsswitch.conf passwd: files sss If there's a local user by that name, she gets access first. For those users that need it, we have a local and a domain account e.g. lynn and lynn2. I think that in your config, lynn2 would take priority. I'm guessing you have passwd: winbind files? Come to think of it, we'd probably be better off your way around as most if not all logins on the clients are domain.
Don't know about the other details, but thought I'd point out mine, as I can see similarities...
Good luck! -linda
Thanks for the input. Helps keep me sane:) L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (2)
-
Linda Walsh -
lynn