Bug 670115

Have you set 'ldap_access_order = expire' ? If not please try with this option. If this still fails or if you have already set it, can you please send sanitized versions of your config and log files, preferably with log level 9 ?

(In reply to comment #1)
> Have you set 'ldap_access_order = expire' ? If not please try with this option.
> If this still fails or if you have already set it, can you please send
> sanitized versions of your config and log files, preferably with log level 9 ?

To amend Sumit's comment, this requires two lines in the sssd.conf:

access_provider = ldap
ldap_access_order = expire

Yes, I should have posted more of the configuration. This is the relevant section of sssd.conf:
[domain/LDAP]
id_provider = ldap
access_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ...
ldap_schema = rfc2307
ldap_search_base = ou=...
ldap_user_search_base = ou=...
ldap_group_search_base = ou=...
ldap_tls_reqcert = allow
cache_credentials = true
enumerate = true
min_id = 100
max_id = 19999
debug_level = 0
ldap_id_use_start_tls = true
ldap_tls_cacertdir = /etc/openldap/cacerts
ldap_pwd_policy = shadow
ldap_account_expire_policy = shadow
ldap_access_order = expire
(with ldap structure and server uri's removed)

Everything works, except that expiration takes place at the wrong date.

shadowInactive and shadowExpire are not used together. As you can see from 'man 3 shadow' shadowExpire is the day when the account will be disabled independent of any other events and there is no warning time. shadowInactive is the number of days after which the account is disabled after the password is expired. If the password is expired but still in the shadowInactive range the password can be renewed be the user, after shadowInactive only an admin can reset the account. So I'm a bit confused how all this matches with the issue you see.

Have you used authconfig to setup the pam configuration or have you done it manually? If manually, can you send you pam config? The sssd log files and the values of the shadow attributes of the user account would be helpful, too.

That explains things. So, shadowInactive belongs with the password expiration date. Which was identical to the account expiration date in the case where I discovered the problem. My mistake for not investigating the case with different expiration dates.
So the issue is slightly different, but it still stands: an expiration warning (for the password) was given shadowInactive days before expiration, but nothing got blocked until the same number of days after the expiration date has passed.
Completely reproducible: shadowMax=365 in our LDAP, if I set shadowLastChange to e.g. 18 Jan 2010, I get the warning that the password will expire in 1 day. If I set it to 16 Jan 2010, access is possible without warning. Only if shadowLastChange is 7 Jan 2010 or earlier (shadowInactive = 10), is the account denied access.
Other services, like dovecot on RHEL, or anything that doesn't go through sssd but uses LDAP directly, blocks access when the password has expired and not 10 days later.

Please not the the expiration warning is controlled by shadowWarning. shadowInactive only defines the grace period after the password is already expired where the old password is still accepted, but only to ask the user for a now password immediately before logging in. Other applications which cannot handle password changes during log in, might just deny access.

Sorry, I meant 'Please note that the expiration warning .,..'

I'll make the appropriate changes to add shadowWarning to our LDAP. Have done so for a test account, and now it almost works as expected.

The only problem which remains is, that there is no warning for accounts in the grace period, when the password has expired. 
If I ssh to a RHEL 5.6 machine with an account whose password has expired less than shadowWarning days ago, it allows me in, and prompts for a password change immediately.
If I do the same to a Fedora 14 machine, it allows me in without any message.

Is there some more sssd setup required here?

(In reply to comment #8)
> I'll make the appropriate changes to add shadowWarning to our LDAP. Have done
> so for a test account, and now it almost works as expected.
> 
> The only problem which remains is, that there is no warning for accounts in the
> grace period, when the password has expired. 
> If I ssh to a RHEL 5.6 machine with an account whose password has expired less
> than shadowWarning days ago, it allows me in, and prompts for a password change
> immediately.

I think you mean shadowInactive ?

> If I do the same to a Fedora 14 machine, it allows me in without any message.
> 
> Is there some more sssd setup required here?

I cannot reproduce this with ssh and F14. My settings are:

 - shadowLastChange: 14990 (2011-01-16)
 - shadowMax: 2 (password expired at 2011-01-18)
 - shadowInactive: 5 (user is force to change password before allowed to log in until 2011-01-23)

Can you send all sanitized user attributes of the test account ?

This ticket has been awaiting additional information for over a month. Closing as INSUFFICIENT_DATA.

If the requested information is provided, the ticket may be reopened.