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: testyoga@EXAMPLE.COM for krbtgt/EXAMPLE.COM@EXAMPLE.COM, 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}, testyoga@EXAMPLE.COM for kadmin/changepw@EXAMPLE.COM –

/var/log/auth.log

/var/log/auth.log : /var/log/auth.log : pam_krb5[24516]: authentication succeeds for 'testyoga' (testyoga@EXAMPLE.COM) –
Andrew B
  • 31,858
  • 12
  • 90
  • 128
Chandira Mouli
  • 51
  • 3
  • 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 02 '16 at 15:16
  • krb5kdc.log : Jun 03 11:34:29 krb5kdc[1752](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.181.40: CLIENT KEY EXPIRED: testyoga@EXAMPLE.COM for krbtgt/EXAMPLE.COM@EXAMPLE.COM, Password has expired Jun 03 11:34:47 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}, testyoga@EXAMPLE.COM for kadmin/changepw@EXAMPLE.COM – Chandira Mouli Jun 03 '16 at 06:06
  • /var/log/auth.log : /var/log/auth.log : pam_krb5[24516]: authentication succeeds for 'testyoga' (testyoga@EXAMPLE.COM) – Chandira Mouli Jun 03 '16 at 06:09
  • Please edit those details into the question. Thanks! – Andrew B Jun 03 '16 at 06: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 03 '16 at 20:04
  • `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` – Chandira Mouli Jun 08 '16 at 11:46
  • Friendly reminder - please put the output of config files and logs into your question, not the comments. – Andrew B Jun 08 '16 at 15:04
  • I have put pam_krb5.so above pam_localuser.so . But now it asks for new password from user even though I have made `fail_pwchange=true` in krb5.conf . Is there a way to return rather than asking for new password from user. – Chandira Mouli Jun 13 '16 at 07:30
  • I'm confused. Where did you see it documented that this option should go in `krb5.conf`? I believe that's an option for the PAM module, not the Kerberos stack itself. I'm also very confused as to which pam_krb5 module you're using at this point. When you type `man pam_krb5`, is the current maintener listed under `Author` Nalin Dahyabhai, Russ Allbery, or someone else? – Andrew B Jun 13 '16 at 07:58
  • AUTHOR - Nalin Dahyabhai ; Added the line in **krb5.conf** `[appdefaults] pam = { fail_pwchange = true }` – Chandira Mouli Jun 14 '16 at 06:20
  • `fail_pwchange` is an option to Russ Allbery's `pam_krb5` implementation, which you are not using. Please review `man pam_krb5` for valid configuration options, but be advised that I do not see an equivalent option. – Andrew B Jun 14 '16 at 07:33
  • Please open a new question if you would like assistance with a topic other than the one described in this subject line. I'm pretty sure I answered your original question and these comments are far too long as it is. :( – Andrew B Jun 14 '16 at 07:34

1 Answers1

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.

Andrew B
  • 31,858
  • 12
  • 90
  • 128