LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (http://www.linuxquestions.org/questions/linux-security-4/)
-   -   PAM and netgroups (http://www.linuxquestions.org/questions/linux-security-4/pam-and-netgroups-4175498784/)

mydogspot 03-19-2014 05:16 PM

PAM and netgroups
 
We are trying to use PAM and /etc/security/access.conf to lock down logins to our servers to specific netgroups and I think we have run into a bug. Our OS is OEL 6.5 and we are running the most recent PAM release, pam-1.1.1-17.el6.x86_64. When we first configured our servers to use netgroups they worked perfectly, but over several weeks users started getting locked out and now now one can login unless we completely disable access.conf. I had a clone of one of these servers with a VM snapshot and I rolled back to the snapshot and can now login to that server again - but I would assume I will eventually be locked out again. We have an OEL 5 server that we have set this up on as well and that has not encountered any problems. tcpdump on the OEL 5 server shows it querying our LDAP for the username, then querying for the allowed netgroups until it finds a match. But I don't see our OEL 6 servers ever querying for the netgroups. Is anyone here familiar with doing this type of authentication and/or encountered this situation?

thanks -
EJ

custangro 03-19-2014 07:26 PM

What's the output of

Code:

egrep -v '^#|^$' /etc/security/access.conf
Code:

egrep -v '^#|^$' /etc/nsswitch.conf
--C

mydogspot 03-20-2014 10:30 AM

# egrep -v '^#|^$' /etc/security/access.conf
+ : @sysadmin : ALL
+ : @UXorprd : ALL
- : ALL : ALL
# egrep -v '^#|^$' /etc/nsswitch.conf
passwd: files sss ldap
shadow: files sss ldap
group: files sss ldap
hosts: files dns
bootparams: nisplus [NOTFOUND=return] files
ethers: files
netmasks: files
networks: files
protocols: files ldap
rpc: files
services: files sss
netgroup: files sss ldap
publickey: nisplus
automount: files ldap
aliases: files nisplus

---------- Post added 03-20-14 at 09:31 AM ----------

we were using nslcd but switched it over to sssd yesterday to see if that would help, but it made no difference.

mydogspot 03-20-2014 10:59 AM

And this is our pam sssd file

# cat sshd
#%PAM-1.0
auth required pam_sepermit.so
auth include password-auth
account required pam_access.so debug
account required pam_nologin.so
account include password-auth
password include password-auth
# pam_selinux.so close should be the first session rule
session required pam_selinux.so close
session required pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session required pam_selinux.so open env_params
session optional pam_keyinit.so force revoke
session include password-auth


When netgroups checking is working properly, I can see in /var/log/secure

Mar 19 14:23:22 or-CLONE sshd[9633]: pam_access(sshd:account): line 122: + : @sysadmin : ALL
Mar 19 14:23:22 or-CLONE sshd[9633]: pam_access(sshd:account): list_match: list= @sysadmin , item=ej
Mar 19 14:23:22 or-CLONE sshd[9633]: pam_access(sshd:account): user_match: tok=@sysadmin, item=ej
Mar 19 14:23:22 or-CLONE sshd[9633]: pam_access(sshd:account): netgroup_match: 1 (netgroup=sysadmin, machine=NULL, user=ej, domain=)
Mar 19 14:23:22 or-CLONE sshd[9633]: pam_access(sshd:account): user_match=1, "ej"


When it stops working, it will report user_match=0 "ej", then proceed to check the next netgroup UXorprd, then it hits the - : ALL : ALL in access.conf and kicks me off.

I have another test user account that I set up to be in both sysadmin and UXorprd netgroups and that user is failing at every step - sysadmin check, UXorprd, and then kicked off.

Mar 19 14:23:34 or-CLONE sshd[9655]: pam_access(sshd:account): line 122: + : @sysadmin : ALL
Mar 19 14:23:34 or-CLONE sshd[9655]: pam_access(sshd:account): list_match: list= @sysadmin , item=ejtest10
Mar 19 14:23:34 or-CLONE sshd[9655]: pam_access(sshd:account): user_match: tok=@sysadmin, item=ejtest10
Mar 19 14:23:34 or-CLONE sshd[9655]: pam_access(sshd:account): netgroup_match: 0 (netgroup=sysadmin, machine=NULL, user=ejtest10, domain=)
Mar 19 14:23:34 or-CLONE sshd[9655]: pam_access(sshd:account): user_match=0, "ejtest10"
Mar 19 14:23:34 or-CLONE sshd[9655]: pam_access(sshd:account): line 123: + : @UXorprd : ALL
Mar 19 14:23:34 or-CLONE sshd[9655]: pam_access(sshd:account): list_match: list= @UXorprd , item=ejtest10
Mar 19 14:23:34 or-CLONE sshd[9655]: pam_access(sshd:account): user_match: tok=@UXorprd, item=ejtest10
Mar 19 14:23:34 or-CLONE sshd[9655]: pam_access(sshd:account): netgroup_match: 0 (netgroup=UXorprd, machine=NULL, user=ejtest10, domain=)
Mar 19 14:23:34 or-CLONE sshd[9655]: pam_access(sshd:account): user_match=0, "ejtest10"
Mar 19 14:23:34 or-CLONE sshd[9655]: pam_access(sshd:account): line 124: - : ALL : ALL
Mar 19 14:23:34 or-CLONE sshd[9655]: pam_access(sshd:account): list_match: list= ALL , item=ejtest10
Mar 19 14:23:34 or-CLONE sshd[9655]: pam_access(sshd:account): user_match: tok=ALL, item=ejtest10
Mar 19 14:23:34 or-CLONE sshd[9655]: pam_access(sshd:account): string_match: tok=ALL, item=ejtest10
Mar 19 14:23:34 or-CLONE sshd[9655]: pam_access(sshd:account): user_match=2, "ejtest10"
Mar 19 14:23:34 or-CLONE sshd[9655]: pam_access(sshd:account): list_match: list= ALL, item=ejtest10
Mar 19 14:23:34 or-CLONE sshd[9655]: pam_access(sshd:account): from_match: tok=ALL, item=10.0.12.11
Mar 19 14:23:34 or-CLONE sshd[9655]: pam_access(sshd:account): string_match: tok=ALL, item=10.0.12.11
Mar 19 14:23:34 or-CLONE sshd[9655]: pam_access(sshd:account): from_match=2, "10.0.12.11"
Mar 19 14:23:34 or-CLONE sshd[9655]: pam_access(sshd:account): access denied for user `ejtest10' from `10.0.12.11'
Mar 19 14:23:34 or-CLONE sshd[9656]: fatal: Access denied for user ejtest10 by PAM account configuration

custangro 03-20-2014 11:32 AM

Okay, unless I misunderstood, the "@" sign is only for NIS netgroups.

If you're using LDAP or IPA or Active Directory; you don't need the "@" sign...just the group name.


test without the @ sign and see if you get different results

mydogspot 03-20-2014 12:35 PM

This is an NIS netgroup that we are using, but this seems to be working now removing the @. I created a new user that has never had access to either of my allowed groups and that user is being blocked. However, I removed my other test user from both groups (it had previously been in both of my test groups) and that user is still able to login. I tried restarting nslcd but still can login. Could the user info for the old user be cached somehow?

custangro 03-20-2014 04:06 PM

Quote:

Originally Posted by mydogspot (Post 5138131)
This is an NIS netgroup that we are using, but this seems to be working now removing the @. I created a new user that has never had access to either of my allowed groups and that user is being blocked. However, I removed my other test user from both groups (it had previously been in both of my test groups) and that user is still able to login. I tried restarting nslcd but still can login. Could the user info for the old user be cached somehow?


Are you using sssd? If so then yes, the user may be cached


--C

dyurk 03-21-2014 06:13 PM

We had a similar issue. Try to invalidate the netgroup's cache.

Quote:

nscd -i netgroup


All times are GMT -5. The time now is 04:36 PM.