3

We've got Winbind/Kerberos setup on RHEL for AD authentication. Working fine however I noticed that when a password has expired, we get a warning but shell access is still granted.

What's the proper way of handling this? Can we tell PAM to close the session once it sees the password has expired?

Example:

login as: ad-user
ad-user@server.domain.com's password:
Warning: password has expired.
[ad-user@server ~]$

Contents of /etc/pam.d/system-auth:

auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_krb5.so use_first_pass
auth        sufficient    pam_winbind.so use_first_pass
auth        required      pam_deny.so

account     [default=2 success=ignore] pam_succeed_if.so quiet uid >= 10000000
account     sufficient    pam_succeed_if.so user ingroup AD_Admins debug
account     requisite     pam_succeed_if.so user ingroup AD_Developers debug
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     [default=bad success=ok user_unknown=ignore] pam_winbind.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    sufficient    pam_krb5.so use_authtok
password    sufficient    pam_winbind.so use_authtok
password    required      pam_deny.so

session     [default=2 success=ignore] pam_succeed_if.so quiet uid >= 10000000
session     sufficient    pam_succeed_if.so user ingroup AD_Admins debug
session     requisite     pam_succeed_if.so user ingroup AD_Developers debug
session     optional      pam_mkhomedir.so umask=0077 skel=/etc/skel
session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     optional      pam_mkhomedir.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_krb5.so
kernelpanic
  • 1,276
  • 1
  • 10
  • 30

1 Answers1

0

We'll need to know the numerical uid of the user you're logging in as to know for sure. What follows is speculation.

Authorization lockouts generally happen within the account stack , so let's start by looking there. Entries that terminate the module stack are immediately suspect. I don't see done anywhere in here, so the lines with sufficient are the ones we need to focus on. That lets us focus on these lines at the top of the stack:

account     [default=2 success=ignore] pam_succeed_if.so quiet uid >= 10000000
account     sufficient    pam_succeed_if.so user ingroup AD_Admins debug
account     requisite     pam_succeed_if.so user ingroup AD_Developers debug
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
  • If numeric uid is <= 10000000 and a member of the AD_Admins group, the account stack will terminate with success line 2.
  • If the user has an entry in /etc/passwd in addition to LDAP, the account stack will terminate with success at line 6.
  • If the numeric uid is < 500, the account stack will terminate with success at line 7. (this is not likely the culprit due to your >= 500 check in the auth stack)

All of the above scenarios will result in the account stack terminating before the accounting checks of pam_krb5.so and pam_windbind.so.

Andrew B
  • 32,588
  • 12
  • 93
  • 131