1

I'm using pam_access and /etc/security/access.conf to restrict who can login to my Rhel 6.5 hosts.

I have an LDAP server with a diverse user base, and the security people would like a list of who can login to what.

I need a sciptable way to check if an account will be able to login to the host. getent passwd, id, finger, groups and every other tool I've tried return the same output if an account is restricted from logging in or not. passwd -S doesn't seem to work with LDAP accounts at all.

Is there a way to check if a given account has login permissions? On Solaris if the user or netgroup isn't in /etc/passwd none of the tools can identify a restricted account, but it seems to be completely the opposite on Linux.

Thanks!

Edit: This is the account section of /etc/pam.d/system-auth: account required pam_access.so account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_krb5.so account required pam_permit.so

My puppet config only does the following that could change the pam setup. /usr/sbin/authconfig --enablemkhomedir --updateall /usr/sbin/authconfig --enablekrb5 --updateall /usr/sbin/authconfig --enablepamaccess --updateall /usr/sbin/authconfig --enablesssd --updateall /usr/sbin/authconfig --nisdomain=domainname.corp --updateall my /etc/security/access.conf + : root : ALL .... all system accounts + : @ngunix_admins : ALL - : ALL : ALL My netgroup getent netgroup ngunix_admins ngunix_admins ( ,danw,domainname.corp) I'm in the ngunix_admins netgroup so this makes sense % id danw uid=355400001(danw) gid=355400001(danw) groups=355400001(danw) % getent passwd danw danw:*:355400001:355400001:unixadmin:/home/danw:/bin/bash But this other user is not in the ngunix_admins netgroup so I need some way to identify that he cannot log in id testuser uid=355400003(testuser) gid=355400003(testuser) groups=355400003(testuser) getent passwd testuser testuser:*:355400003:355400003:first last:/home/testuser:/bin/bash 2nd Edit: Clarify that I'm not tuning login permissions, but trying to report on access for auditing.

3
  • We're going to need an example of your PAM stack. As worded I'm not sure I understand what you're trying to accomplish. If the account component of pam_unix were to reject the user (let's say the shadow attributes have locked the account), your pam_access module may not even be called if it's further down the stack. (and if it's higher in the stack, my question would be "why?")
    – Andrew B
    Mar 17, 2015 at 21:05
  • Thanks for the edit. I'm still not understanding the problem though. It looks like your pam_access rule is already deny by default. Any attempt to authenticate by someone who was not explicitly allowed by you is going to fail. This will not exclude those users from being resolvable by NSS (i.e. getent passwd testuser will still work), but attempts to authenticate with PAM enabled programs will still fail for those users. (if the PAM and NSS thing is confusing, this Q&A may help.)
    – Andrew B
    Mar 17, 2015 at 21:38
  • I'm trying to document who can login. On each host I just want to run a daily cron job to check all LDAP account to list accounts that can login. Solaris has a nifty tool /bin/dispuid that list only those accounts that can login, and I'm running it daily so the auditors can see any changes, I need something similar for RedHat.
    – danw
    Mar 17, 2015 at 22:16

1 Answer 1

2

I recently had to perform a PCI audit of a very similar nature (who can log in to these systems and what are their permissions), so have a good feel for what you're trying to accomplish here. The methodology varies from environment to environment depending on how PAM and LDAP are configured.

The following factors seem to apply to your environment:

  • The enumerated passwd database (getent passwd) contains users who should never be allowed to access the system.
  • shadow restrictions must be considered. Sometimes, anyway. You have broken_shadow enabled.
  • PAM restrictions must be considered. (including pam_access restrictions, which greatly decreases the likeliness of finding an all-in-one tool that will do this without actually performing a call against pam_acct_mgmt)
  • KRB5 restrictions must be considered, for users who have accounts.

I would rate the complexity of this assignment as "high and time consuming" without a utility that tests PAM stacks. pamtester looks like it will do the job. You'll need to loop through every user in getent passwd and perform a post-authentication accounting check:

pamtester sshd $user acct_mgmt

This assumes that you only need to test access via ssh. If you need to test more than that, do so. Review /etc/pam.d for the services that you have configured and audit whatever is necessary.

(I apologize for the initial answer, my last effort was more focused on sudo audits than PAM audits and I was in too much of a "do everything by hand" mindset.)

1
  • Thank you! This is exactly what I was looking for. I was too focused on the pam_access part and not enough on pam in general. I owe you a beverage!
    – danw
    Mar 18, 2015 at 17:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .