Bug 1652984

Summary:	Subtree password policy overrides a user-defined password policy.
Product:	Red Hat Enterprise Linux 7	Reporter:	Têko Mihinto <tmihinto>
Component:	389-ds-base	Assignee:	thierry bordaz <tbordaz>
Status:	CLOSED ERRATA	QA Contact:	RHDS QE <ds-qe-bugs>
Severity:	medium	Docs Contact:	Marc Muehlfeld <mmuehlfe>
Priority:	high
Version:	7.5	CC:	aadhikar, bugzilla-redhat, cpelland, gbabiano, lkrispen, mreynolds, nkinder, pasik, rbeyel, rmeggins, spichugi, tbordaz, vashirov
Target Milestone:	rc
Target Release:	7.7
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	389-ds-base-1.3.9.1-5.el7	Doc Type:	Bug Fix
Doc Text:	.Directory Server no longer uses the CoS attribute with a higher priority than the real attribute Previously, Directory Server used the `operational-default` Class of Service (CoS) attribute with a higher priority than the real attribute. As a consequence, the server overwrote the attribute set in a local password with the CoS policy defined in a subtree. This update fixes the problem. As a result, CoS-defined password policies work as expected.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-08-06 12:59:10 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Têko Mihinto 2018-11-23 20:22:50 UTC

Description of problem:

The subtree password policy is always returned even if the attribute "pwdpolicysubentry" is present in the entry.


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

# rpm -qa | grep 389-ds-base-1
389-ds-base-1.3.7.5-25.el7_5.x86_64
#
# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.5 (Maipo)
#


How reproducible:

Always


Steps to Reproduce:
 
1. Define a subtree-level password policy on a given subtree  using the Console or ns-newpwpolicy.pl

2. Create a user in the subtree and assign him a user-level password policy

3. Create a user in the subtree and assign directly a password policy in the entry:

# ldapmodify  -D "cn=Directory Manager" -W -p <PORT> -h localhost -x -a
Enter LDAP Password:
dn: uid=tmihinto,ou=TestPWP,o=test
uid: tmihinto
objectClass: top
objectClass: organizationalPerson
objectClass: inetorgperson
sn: Mihinto
cn: Teko
pwdpolicysubentry: cn=Teko_PWP,ou=TestPWP,o=test

adding new entry "uid=tmihinto,ou=TestPWP,o=test"

#

4. Search for the attribute pwdpolicysubentry.
The returned value is the one from the subtree password policy for the 3 users:

# ldapsearch -o ldif-wrap=no -xLLL -D "cn=Directory Manager" -W -b "o=test"  -h localhost -p <PORT> uid=* \* + nscpEntryWSI | egrep "^dn:|pwdpolicysubentry"
Enter LDAP Password:
dn: uid=tmorris,ou=TestPWP,o=test
pwdpolicysubentry: cn=cn\3DnsPwPolicyEntry\2Cou\3DTestPWP\2Co\3Dtest,cn=nsPwPolicyContainer,ou=TestPWP,o=test
dn: uid=scarter,ou=TestPWP,o=test
pwdpolicysubentry: cn=cn\3DnsPwPolicyEntry\2Cou\3DTestPWP\2Co\3Dtest,cn=nsPwPolicyContainer,ou=TestPWP,o=test
nscpEntryWSI: pwdpolicysubentry: cn=cn\3DnsPwPolicyEntry\2Cuid\3Dscarter\2Cou\3DTestPWP\2Co\3Dtest,cn=nsPwPolicyContainer,ou=TestPWP,o=test
dn: uid=tmihinto,ou=TestPWP,o=test
pwdpolicysubentry: cn=cn\3DnsPwPolicyEntry\2Cou\3DTestPWP\2Co\3Dtest,cn=nsPwPolicyContainer,ou=TestPWP,o=test
nscpEntryWSI: pwdpolicysubentry: cn=Teko_PWP,ou=TestPWP,o=test
#



Actual results:

The returned value is from the subtree password policy.


Expected results:

Based on the CoS qualifiers [1] used by the subtree password policy ( "default" and  "operational-default" ), one would expect the value in the user entry to take precedence.


Additional info:

[1] https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/advanced_entry_management-assigning_class_of_service#cos-qualifiers

Comment 3 thierry bordaz 2018-11-26 11:37:31 UTC

Regarding "operational-default" definition.

This bug is a regression introduced during https://fedorahosted.org/389/ticket/142 ([RFE] Default password syntax settings don't work with fine-grained policies).

Reading the fix #142, it looks the change that introduced the regression was not related to the RFE and may be a kind of typo.

The bug is that that cos definition applied although it exists a attribute value in the entry. In such case "operational-default" definition should not apply.

Next is to check if the same pb applies for 'default' definition

Comment 4 thierry bordaz 2018-11-26 14:58:56 UTC

ns-newpwpolicy.pl creates a cos template with 'operational-default'.
The processing of 'operational-default' is broken since #142 so since 1.3.5.

The behavior with 'default' keyword is conform to the documentation: it returns the virtual attribute value at the condition the real attribute does not exist

Working on a fix

Comment 6 thierry bordaz 2018-11-27 15:04:32 UTC

Upstream ticket:
https://pagure.io/389-ds-base/issue/50053

Comment 7 thierry bordaz 2018-11-28 09:38:22 UTC

Upstream ticket pushed -> POST

Comment 9 Akshay Adhikari 2019-04-08 07:28:53 UTC

Build tested: 389-ds-base-1.3.9.1-4.el7.x86_64

Changes are not backported, also the test: dirsrvtests/tests/suites/plugins/cos_test.py is failing.

Marking as FailedQA.

Comment 14 Akshay Adhikari 2019-04-30 12:02:30 UTC

============================================================================ test session starts ============================================================================
platform linux -- Python 3.6.3, pytest-4.4.0, py-1.8.0, pluggy-0.9.0
389-ds-base: 1.3.9.1-5.el7
nss: 3.43.0-6.el7
nspr: 4.21.0-1.el7
openldap: 2.4.44-21.el7_6
cyrus-sasl: 2.1.26-23.el7
FIPS: disabled
rootdir: /root/389-ds-base/dirsrvtests
plugins: metadata-1.8.0, html-1.20.0
collected 2 items                                                                                                                                                           

tests/tickets/ticket50232_test.py ..                                                                                                                                  [100%]

================================================================== 1 passed 22.71 seconds 
===================================================================

Marking this as VERIFIED.

Comment 15 Akshay Adhikari 2019-04-30 12:09:45 UTC

(In reply to Akshay Adhikari from comment #14)
> ============================================================================
> test session starts
> ============================================================================
> platform linux -- Python 3.6.3, pytest-4.4.0, py-1.8.0, pluggy-0.9.0
> 389-ds-base: 1.3.9.1-5.el7
> nss: 3.43.0-6.el7
> nspr: 4.21.0-1.el7
> openldap: 2.4.44-21.el7_6
> cyrus-sasl: 2.1.26-23.el7
> FIPS: disabled
> rootdir: /root/389-ds-base/dirsrvtests
> plugins: metadata-1.8.0, html-1.20.0
> collected 2 items                                                           
> 
> 
> tests/tickets/ticket50232_test.py ..                                        
> [100%]
> 
> ================================================================== 1 passed
> 22.71 seconds 
> ===================================================================
> 
> Marking this as VERIFIED.

This is a wrong automation correct verification would be:

============================================================================ test session starts ============================================================================
platform linux -- Python 3.6.3, pytest-4.4.0, py-1.8.0, pluggy-0.9.0
389-ds-base: 1.3.9.1-5.el7
nss: 3.43.0-6.el7
nspr: 4.21.0-1.el7
openldap: 2.4.44-21.el7_6
cyrus-sasl: 2.1.26-23.el7
FIPS: disabled
rootdir: /root/389-ds-base/dirsrvtests
plugins: metadata-1.8.0, html-1.20.0
collected 1 item                                                                                                                                                            

tests/suites/plugins/cos_test.py .                                                                                                                                    [100%]
================================================================== 1 passed in 22.71 seconds 
===================================================================

Comment 16 thierry bordaz 2019-05-17 07:53:08 UTC

Hi Pasi,

I am unsure of your last update. This bug was successfully verified. 
Did you discover a failure, then please give some details.

If you need to update a BZ with QA keywords please double check with Dev-QA people.
thanks

Comment 21 errata-xmlrpc 2019-08-06 12:59:10 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://access.redhat.com/errata/RHBA-2019:2152