Bug 1414679 - Release 1.3.5 may allow expired accounts access to systems
Summary: Release 1.3.5 may allow expired accounts access to systems
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.3
Hardware: All
OS: Linux
urgent
urgent
Target Milestone: rc
: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
Marc Muehlfeld
URL:
Whiteboard:
Depends On: 1411944
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-19 08:50 UTC by Jaroslav Reznik
Modified: 2020-03-11 15:37 UTC (History)
8 users (show)

Fixed In Version: 389-ds-base-1.3.5.10-16.el7_3
Doc Type: Bug Fix
Doc Text:
Due to a bug, the "shadowExpire" attribute was incorrectly set. As a consequence, expired accounts were able to log in. A patch has been provided and Directory Server no longer incorrectly sets the "shadowExpire" attribute. As a result, expired accounts cannot log in. Additionally, this update now only sets the "shadow*" attributes if the password policy is enabled and the corresponding value is configured.
Clone Of: 1411944
Environment:
Last Closed: 2017-03-02 17:13:16 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:0385 normal SHIPPED_LIVE 389-ds-base bug fix update 2017-03-02 22:06:04 UTC

Description Jaroslav Reznik 2017-01-19 08:50:51 UTC
This bug has been copied from bug #1411944 and has been proposed
to be backported to 7.3 z-stream (EUS).

Comment 4 Sankar Ramalingam 2017-02-07 13:37:08 UTC
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?

Comment 5 Sankar Ramalingam 2017-02-07 13:43:13 UTC
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")

Comment 6 Sankar Ramalingam 2017-02-07 13:55:03 UTC
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 ========

Comment 7 Gordon Messmer 2017-02-07 15:22:50 UTC
(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.

Comment 8 Noriko Hosoi 2017-02-07 18:12:18 UTC
(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.

Comment 9 Sankar Ramalingam 2017-02-08 11:25:17 UTC
(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.

Comment 10 Sankar Ramalingam 2017-02-09 16:13:43 UTC
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.

Comment 12 errata-xmlrpc 2017-03-02 17:13:16 UTC
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


Note You need to log in before you can comment on or make changes to this bug.