Bug 1414679

1). Installed 389-ds-base-1.3.5.10-15 build and configured password policy.
2). Created users with shadowAccount objectclass and waited till password expires.
3). Checked whether passwords expired
USR=testusrpw1 ; DN="uid=$USR,ou=people,dc=pwpolicy,dc=com" ; ldapsearch -x -p 1389 -h localhost -D "$DN" -w Secret123 -b "$DN"
ldap_bind: Invalid credentials (49)
	additional info: password expired!

4). Then, checked shadowExpire and other shadow attributes.
DN_DM="cn=Directory Manager" ; ldapsearch -x -p 1389 -h localhost -D "$DN_DM" -w Secret123 -b "$DN"
shadowLastChange: 17204
shadowMin: 0
shadowMax: 0
shadowWarning: 1
shadowExpire: 17204

5). Upgraded the instance to 389-ds-base-1.3.5.10-17 build. Then, checked the Shadow attributes. Only the shadowLastChange attribute is present.
shadowLastChange: 17204

6). I tried changing/adding shadowLastChange/shadowExpire attribute to the expired user, but no consequences to the behavior.

I guess, this proves that there is no influence of shadow attributes to the password policy.

[0 root@qeos-48 389ds-replica]# rpm -qa |grep -i 389-ds
389-ds-base-libs-1.3.5.10-17.el7_3.x86_64
389-ds-base-1.3.5.10-17.el7_3.x86_64

Hi Noriko, please confirm if the steps are good enough to mark the bug as Verified.

There is a test case added in lib389:./tickets/ticket548_test.py. Do I need to run this as well to verify the bugzilla?

I see the following comment in ticket548_test.py. So, I guess 1.3.5.x doesn't have this patch.
# Skip on older versions
pytestmark = pytest.mark.skipif(ds_is_older('1.3.6'), reason="Not implemented")

However, I ran ticket548_test.py on 1.3.5 and it PASSed.

[0 root@qeos-5 tickets]# py.test  -v ticket548_test.py 
======= test session starts ==========
platform linux2 -- Python 2.7.5 -- py-1.4.27 -- pytest-2.7.0 -- /usr/bin/python
rootdir: /mnt/tests/rhds/tests/upstream/ds/dirsrvtests/tests/tickets, inifile: 
plugins: html, cov, beakerlib
DS build: 1.3.5.10 B2017.031.2344
389-ds-base: 1.3.5.10-17.el7_3
nss: 3.21.3-2.el7_3
nspr: 4.11.0-1.el7_2
openldap: 2.4.44-1.el7
svrcore: 4.1.2-1.el7

collected 3 items 

ticket548_test.py::test_ticket548_test_with_no_policy PASSED
ticket548_test.py::test_ticket548_test_global_policy PASSED
ticket548_test.py::test_ticket548_test_subtree_policy PASSED

======== 3 passed in 25.06 seconds ========

(In reply to Sankar Ramalingam from comment #4)
> 
> 5). Upgraded the instance to 389-ds-base-1.3.5.10-17 build. Then, checked
> the Shadow attributes. Only the shadowLastChange attribute is present.
> shadowLastChange: 17204

All of the following should be true with the bug fixes in place:

1: shadowExpire should not be present unless it is manually set.
2: When shadowExpire has been set, it should not change when the password policy changes (specifically the max password age).
3: When shadowExpire has been set, it should not change when the user changes their password.

2 & 3 must be true because the shadowExpire flag is not a password expiration, it is an account expiration date, and unrelated to password policies.  The account should not be allowed to log in if shadowExpire is set to a date in the past, but if that control fails to lock the user out, that is a bug in a different system component.

The following will also be true because of a related change, but are not strictly required in order to fix the security bug:

1: shadowMin will only be auto-filled when the password policy is enabled and the minimum time between changes is > 0.
2: shadowMax will only be auto-filled when the password policy is enabled and the maximum password age is > 0.
2: shadowWarning will only be auto-filled when the password policy is enabled and the warning period is > 0.

(In reply to Sankar Ramalingam from comment #5)
> I see the following comment in ticket548_test.py. So, I guess 1.3.5.x
> doesn't have this patch.
> # Skip on older versions
> pytestmark = pytest.mark.skipif(ds_is_older('1.3.6'), reason="Not
> implemented")

The version 1.3.6 is wrong.  It should be 1.3.5.

Thank you for your clear instructions, Gordon.

Sankar, please follow his input for verification.

Also, I adjusted ticket548_test.py to work with this fix.

(In reply to Gordon Messmer from comment #7)
> (In reply to Sankar Ramalingam from comment #4)
> > 
> > 5). Upgraded the instance to 389-ds-base-1.3.5.10-17 build. Then, checked
> > the Shadow attributes. Only the shadowLastChange attribute is present.
> > shadowLastChange: 17204
> 
> All of the following should be true with the bug fixes in place:
> 
> 1: shadowExpire should not be present unless it is manually set.
> 2: When shadowExpire has been set, it should not change when the password
> policy changes (specifically the max password age).
> 3: When shadowExpire has been set, it should not change when the user
> changes their password.
I verified this already in comment #4. Additionally, I checked changing the password for users with ShadowExpire value set and not set. It works fine for all the above cases. 
> 
> 2 & 3 must be true because the shadowExpire flag is not a password
> expiration, it is an account expiration date, and unrelated to password
> policies.  The account should not be allowed to log in if shadowExpire is
> set to a date in the past, but if that control fails to lock the user out,
> that is a bug in a different system component.
> 
> The following will also be true because of a related change, but are not
> strictly required in order to fix the security bug:
> 
> 1: shadowMin will only be auto-filled when the password policy is enabled
> and the minimum time between changes is > 0.
> 2: shadowMax will only be auto-filled when the password policy is enabled
> and the maximum password age is > 0.
> 2: shadowWarning will only be auto-filled when the password policy is
> enabled and the warning period is > 0.

Attributes shadowMin, shadowMax and shadowWarning are verified by ticket548_test.py tests.

Hence, marking the bug as Verified.

I finished upgrade testing as well from 389-ds-base-1.3.5.10-15 to 389-ds-base-1.3.5.10-17.
1. Configured pwpolicy with pwexp, minage, maxage and pwwarning.
2. Created users with shadowAccount objectclass.
3. Modified shadowExpire attribute to past date.
4. Upgraded the instance to the latest 389-ds-base-1.3.5.10-17
5. Tested by modifying and deleting shadowExpire attribute
6. Account expiry not affected by any of the shadowExpire attribute changes.

So, no problems observed with the upgrade tests as well.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2017-0385.html