5

I have setup SSH - single sign on using kerberos V5. When a user password has expired , it returns 'Warning: password has expired.' and allows the user to login! I even made changes in the /etc/pam.d/password-auth such that pam_krb5.so comes above pam_unix.so:

Auth stack:

auth        requisite     pam_krb5.so uid >= 500

#Google authentication configuration module
auth        [success=1 default=ignore] pam_access.so accessfile=/etc/security/access-local.conf
auth        requisite  pam_google_authenticator.so


auth        [success=1 default=ignore]  pam_unix.so nullok try_first_pass
auth        required      pam_deny.so
auth        requisite     pam_succeed_if.so uid >= 0 quiet

Account stack:

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 uid >= 500
account required pam_permit.so

Please suggest any changes to prevent users with expired passwords from login.

LOG :

krb5kdc.log

Jun 03 11:34:29 <HOST-NAME> krb5kdc[1752](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.181.40: CLIENT KEY EXPIRED: [email protected] for krbtgt/[email protected], Password has expired
Jun 03 11:34:47 <HOST-NAME> krb5kdc[1752](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.181.40: ISSUE: authtime 1464933887, etypes {rep=18 tkt=18 ses=18}, [email protected] for kadmin/[email protected]

/var/log/auth.log

/var/log/auth.log : /var/log/auth.log : pam_krb5[24516]: authentication succeeds for 'testyoga' ([email protected]) –
12
  • Can you show us the logs? I understand the warning excerpt that you're showing us, but it would be helpful if you showed us what is logged starting from the client connection message. (i.e. when their IP first connects)
    – Andrew B
    Jun 2, 2016 at 15:16
  • krb5kdc.log : Jun 03 11:34:29 <HOST-NAME> krb5kdc[1752](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.181.40: CLIENT KEY EXPIRED: [email protected] for krbtgt/[email protected], Password has expired Jun 03 11:34:47 <HOST-NAME> krb5kdc[1752](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.181.40: ISSUE: authtime 1464933887, etypes {rep=18 tkt=18 ses=18}, [email protected] for kadmin/[email protected] Jun 3, 2016 at 6:06
  • /var/log/auth.log : /var/log/auth.log : pam_krb5[24516]: authentication succeeds for 'testyoga' ([email protected]) Jun 3, 2016 at 6:09
  • Please edit those details into the question. Thanks!
    – Andrew B
    Jun 3, 2016 at 6:09
  • One last item: please add your account stack to the question. I'm going to tentatively answer the question based on the log messages, but your account stack will confirm the problem.
    – Andrew B
    Jun 3, 2016 at 20:04

1 Answer 1

3

Edit:

Based on the contents of the provided account stack, it looks like pam_krb5.so will be skipped if pam_localuser.so succeeds. This is the most likely cause of the password aging restrictions not being applied.


Here's what we know so far:

  • The logged messages confirm that the user's password has expired.
  • pam_krb5 succeeds in authentication despite this.

I suspect your problem is that you don't have the account stack properly configured. There are a few different implementations of pam_krb5 out there, and not all of them implement the password aging check inside of the auth stack:

http://linux.die.net/man/8/pam_krb5

When a user logs in, the module's authentication function performs a simple password check and, if possible, obtains Kerberos 5 credentials, caching them for later use. When the application requests initialization of credentials (or opens a session), the usual ticket files are created. When the application subsequently requests deletion of credentials or closing of the session, the module deletes the ticket files. When the application requests account management, if the module did not participate in authenticating the user, it will signal libpam to ignore the module. If the module did participate in authenticating the user, it will check for an expired user password and verify the user's authorization using the .k5login file of the user being authenticated, which is expected to be accessible to the module.

The job of the account stack is to enforce access policies, regardless of whether the authentication was successful. This is important, as the auth stack is frequently bypassed when using key based authentication. It is up to individual developers to decide whether password aging should also result in a failure when calling the module in the auth context.

Conversely, the pam_krb5 implementation maintained by Russ Allbery (my preferred one) would have caught this in the auth stack.

https://www.eyrie.org/~eagle/software/pam-krb5/pam-krb5.html

account

Provides an implementation of pam_acct_mgmt(). All it does is do the same authorization check as performed by the pam_authenticate() implementation described above.

You must log in to answer this question.

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