SSSD/AD 2008 and Password Change

You need to use:

access_provider = ldap
ldap_access_order = expire
ldap_account_expire_policy = ad

From sssd-ldap(5):

       ldap_account_expire_policy (string)
           With this option a client side evaluation of access control attributes can be enabled.

           Please note that it is always recommended to use server side access control, i.e. the LDAP server should deny
           the bind request with a suitable error code even if the password is correct.

           The following values are allowed:

           shadow: use the value of ldap_user_shadow_expire to determine if the account is expired.

           ad: use the value of the 32bit field ldap_user_ad_user_account_control and allow access if the second bit is
           not set. If the attribute is missing access is granted. Also the expiration time of the account is checked.

           rhds, ipa, 389ds: use the value of ldap_ns_account_lock to check if access is allowed or not.

           nds: the values of ldap_user_nds_login_allowed_time_map, ldap_user_nds_login_disabled and
           ldap_user_nds_login_expiration_time are used to check if access is allowed. If both attributes are missing
           access is granted.
            This is an experimental feature, please use http://fedorahosted.org/sssd to report any issues.

           Default: Empty

       ldap_user_ad_account_expires (string)
           When using ldap_account_expire_policy=ad, this parameter contains the name of an LDAP attribute storing the
           expiration time of the account.

           Default: accountExpires

       ldap_user_ad_user_account_control (string)
           When using ldap_account_expire_policy=ad, this parameter contains the name of an LDAP attribute storing the
           user account control bit field.

           Default: userAccountControl

I have added these to my sssd.conf and I am still reciving "invalid password, please try again"

This is from the ubuntu man page for sssd.conf

It doesnt look like access_provider = ldap is valid

permit, deny, simple are the only options

       access_provider (string)
           The access control provider used for the domain. There are two
           built-in access providers (in addition to any included in installed
           backends) Internal special providers are:

           "permit" always allow access.

           "deny" always deny access.

           "simple" access control based on access or deny lists. See sssd-
           simple(5) for more information on configuring the simple access
           module.

           Default: "permit"

"(in addition to any included in installed backends)"

That list is just the internal special providers. The "installed backends" are those for "ldap" and "kerberos".

What do you see in /var/log/secure when doing that authentication that fails?

Is it showing just pam_sss.so:auth or is it also getting to pam_sss.so:acct?

If it's just doing 'auth', then the result 'invalid password' is probably just coming back from Active Directory.

One more thing to try: As a user who has been set "change password on next login", perform a kinit at the command line (with 'kinit user@REALM'. See if that user is prompted to change his/her password there, or if it's simply refused.

If it's refused, then the problem is with Active Directory. (If it's not returning KRB5KDC_ERR_KEY_EXP, then we can't tell the user they need to change the password).

aaahh ok I see what is meant by "in addition to any included installed backends"

I have changed it back

I don't have a /var/log/secure but i have /var/log/auth.log

This is just trying login from tty2

Jan 12 15:41:00 vut-precise01 login[781]: pam_krb5(login:auth): authentication failure; logname=jsharp_sa uid=0 euid=0 tty=/dev/tty2 ruser= rhost=
Jan 12 15:41:00 vut-precise01 login[781]: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=/dev/tty2 ruser= rhost= user=jsharp_sa
Jan 12 15:41:01 vut-precise01 login[781]: pam_sss(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=/dev/tty2 ruser= rhost= user=jsharp_sa
Jan 12 15:41:01 vut-precise01 login[781]: pam_sss(login:auth): received for user jsharp_sa: 4 (System error)
Jan 12 15:41:04 vut-precise01 login[781]: FAILED LOGIN (1) on '/dev/tty2' FOR 'jsharp_sa', Authentication failure

kinit results in an error that simply says 'generic preauthentication failure while getting initial credentials' which is leading me to believe its AD that returning a different value

'generic preauthentication failure' == KRB5KDC_ERR_PREAUTH_FAILED (Which is therefore different from KRB5KDC_ERR_KEY_EXP. So yeah, the Active Directory server is not sending the correct response from the KDC. We can't do anything about that (since KRB5KDC_ERR_PREAUTH_FAILED is the same error code used for an incorrect password).

File a bug with Microsoft. This isn't an issue in SSSD.

Thanks Stephen, closing the bug.

I actually do see a KRB5KDC_ERR_KEY_EXP when running wireshark and capturing packets

38 2.045309 10.8.35.22 10.12.2.94 KRB5 263 KRB Error: KRB5KDC_ERR_PREAUTH_REQUIRED
39 2.045323 10.12.2.94 10.8.35.22 TCP 66 53244 > kerberos [ACK] Seq=211 Ack=198 Win=15680 Len=0 TSval=23443430 TSecr=878789915
40 2.045436 10.12.2.94 10.8.35.22 TCP 66 53244 > kerberos [FIN, ACK] Seq=211 Ack=198 Win=15680 Len=0 TSval=23443430 TSecr=878789915
41 2.045628 10.8.35.22 10.12.2.94 TCP 66 kerberos > 53244 [ACK] Seq=198 Ack=212 Win=66560 Len=0 TSval=878789915 TSecr=23443430
42 2.045844 10.12.2.94 10.8.35.22 TCP 74 53245 > kerberos [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=23443430 TSecr=0 WS=16

accientally hit the post command....

43 2.046083 10.8.35.22 10.12.2.94 TCP 74 kerberos > 53245 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 TSval=878789915 TSecr=23443430
44 2.046095 10.12.2.94 10.8.35.22 TCP 66 53245 > kerberos [ACK] Seq=1 Ack=1 Win=14608 Len=0 TSval=23443430 TSecr=878789915
45 2.046161 10.12.2.94 10.8.35.22 KRB5 352 AS-REQ
46 2.046521 10.8.35.22 10.12.2.94 TCP 60 kerberos > 53244 [RST, ACK] Seq=198 Ack=212 Win=0 Len=0
47 2.047470 10.8.35.22 10.12.2.94 KRB5 207 KRB Error: KRB5KDC_ERR_KEY_EXP NT Status: STATUS_PASSWORD_MUST_CHANGE

the contents of packet 47 are...

NT Status: STATUS_PASSWORD_MUST_CHANGE

and then a few packets later it I see

56 2.048958 10.8.35.22 10.12.2.94 KRB5 253 KRB Error: KRB5KDC_ERR_PREAUTH_REQUIRED

then it says password invalid

I'm going to make a guess, because you didn't include the packets between KRB5KDC_ERR_KEY_EXP and KRB5KDC_ERR_PREAUTH_REQUIRED. I suspect that what happened is that AD returned the correct error that the key was expired, and the MIT libraries then went and tried to acquire a password-change token with the original password you presented. If that password was not valid, it throws an error.

Ok, so in Active Directory, I have disabled "Require Preauthentication" which has eliminated the KRB5KDC_ERR_PREAUTH_REQUIRED message

I'm still seeing the KRB5KDC_ERR_KEY_EXP

I can see the machine send the Kerberos AS-REQ and immediately get a KRB Error: KRB5KDC_ERR_KEY_EXP_KEY

It doesn't even appear to acknowledge that a password change is required

Can you please be more explicit?

Please describe if you're getting this behavior from SSSD or from using the 'kinit' command directly.

For now, let's investigate the problem using only kinit (that will narrow down the problem to Kerberos and Active Directory, thus eliminating SSSD for the time being).

So, please try the 'kinit user@REALM' test again while you have "Require Preauthentication" disabled in Active Directory and see what comes back.

(As an aside, you don't want to disable "Require Preauthentication" on a production system, as it provides additional security and significantly reduces the effectiveness of replay attacks. However, for the purposes of tracking down the source of this problem, let's experiment with the behavior while it's off).

Sorry I wasn't more explicity

Taking your suggestion, running kinit user@REALM i do recieve "Password Expired. You must change it now"
This is with preauthentication off

However, when I turn Pre-authentication on, I recieve a Generic Preauthetncation Failure

perhaps this is an issue with kinit/ktpass version in 12.04?

My appologies. I have tested kinit user@REALM in 11.10 WITHOUT disabling preauthentication and it works just fine

kinit user@REALM in 12.04 WITHOUT disabling preauthentication responds with "Generic preauthentication failure"

I will troubleshoot the kinit issue, and if sssd is still a problem after kinit gets fixed, I will reopen