#3597 sssd doesn't allow user with expired password to login when PasswordgraceLimit set
Closed: Fixed 5 years ago Opened 6 years ago by jhrozek.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1522928

Description of problem:

When a users password is expired and passwordGraceLimit is set to 3 , where
user is allowed to login 3 times before passowrd expiry is forced. In earlier
versions of 389-ds-base (i.e 389-ds-base-1.3.7.5-4.el7 and above), password
expired control was not sent and sssd would allow the expired user to attemp
Login till passwordGracelimit is 0

Following Messages are seen in sssd logs


(Wed Dec  6 23:35:36 2017) [sssd[be[EXAMPLE.TEST]]] [sdap_process_result]
(0x2000): Trace: sh[0x562ee6fec900], connected[1], ops[0x562ee70c15f0],
ldap[0x562ee70bf260]
(Wed Dec  6 23:35:36 2017) [sssd[be[EXAMPLE.TEST]]] [sdap_process_message]
(0x4000): Message type: [LDAP_RES_BIND]
(Wed Dec  6 23:35:36 2017) [sssd[be[EXAMPLE.TEST]]] [simple_bind_done]
(0x2000): Server returned control [1.3.6.1.4.1.42.2.27.8.5.1].
(Wed Dec  6 23:35:36 2017) [sssd[be[EXAMPLE.TEST]]] [simple_bind_done]
(0x1000): Password Policy Response: expire [-1] grace [4] error [No error].
(Wed Dec  6 23:35:36 2017) [sssd[be[EXAMPLE.TEST]]] [simple_bind_done]
(0x1000): Password expired. [4] grace logins remaining.
(Wed Dec  6 23:35:36 2017) [sssd[be[EXAMPLE.TEST]]] [simple_bind_done]
(0x0400): Bind result: Success(0), no errmsg set
(Wed Dec  6 23:35:36 2017) [sssd[be[EXAMPLE.TEST]]] [sdap_op_destructor]
(0x2000): Operation 3 finished
(Wed Dec  6 23:35:36 2017) [sssd[be[EXAMPLE.TEST]]] [auth_bind_user_done]
(0x4000): Found ppolicy data, assuming LDAP password policies are active.


After updating to 389-ds to 389-ds-base-1.3.7.5-10.el7 , now expired users with
Grace period sent, 389-ds now sends the password expired control , causing sssd
to not allow the user to login even though the GraceLimit is set and user is
allowed to make certain number of login attempts till GraceLimit expires. (0)

Version-Release number of selected component (if applicable):

sssd-1.16.0-9.el7.x86_64
389-ds-base-1.3.7.5-10.el7


How reproducible:


Steps to Reproduce:
1.Configure sssd to authenticate to ldap server
[sssd]
domains = EXAMPLE.TEST
config_file_version = 2
services = nss, pam, ifp

[domain/EXAMPLE.TEST]
enumerate = false
id_provider = ldap
ldap_uri = ldap://vm-idm-033.lab.eng.pnq.redhat.com
ldap_search_base = dc=example,dc=test
ldap_tls_cacert = /etc/openldap/cacerts/cacert.pem
auth_provider = ldap

[nss]
debug_level = 9

[pam]
debug_level = 9
offline_credentials_expiration = 0



2. Create a foo1 user on 389-ds

3. Set password policy with passwordMaxAge=1, passwordExp=on, and
passwordGracelimit=3

4. Login as foo1 user ,

Actual results:

user will be prompted to immediately change password
[root@vm-idm-033 ~]# ssh -o StrictHostKeyChecking=no -l foo1 localhost
foo1@localhost's password:
Password expired. Change your password now.
Last login: Wed Dec  6 22:02:57 2017 from localhost
WARNING: Your password has expired.
You must change your password now and login again!
Changing password for user foo1.
Current Password:


Expected results:

User should not be prompted for password change till gracelimit doesn't expire
(or becomes 0).



Additional info:

Metadata Update from @jhrozek:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1522928

6 years ago

Metadata Update from @jhrozek:
- Issue set to the milestone: SSSD 1.16.2

6 years ago

Metadata Update from @jhrozek:
- Issue priority set to: major

6 years ago

Since we are near the 1.16.2 release and this ticket has no PR yet, it will slip into 1.16.3.

Metadata Update from @jhrozek:
- Issue set to the milestone: SSSD 1.16.3 (was: SSSD 1.16.2)

6 years ago

Metadata Update from @fidencio:
- Issue assigned to fidencio

5 years ago

Metadata Update from @fidencio:
- Issue tagged with: PR

5 years ago

Metadata Update from @jhrozek:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

5 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4620

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Log in to comment on this ticket.

Metadata