Bug 1652984 - Subtree password policy overrides a user-defined password policy.
Summary: Subtree password policy overrides a user-defined password policy.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.5
Hardware: All
OS: Linux
high
medium
Target Milestone: rc
: 7.7
Assignee: thierry bordaz
QA Contact: RHDS QE
Marc Muehlfeld
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-23 20:22 UTC by Têko Mihinto
Modified: 2020-01-14 15:39 UTC (History)
13 users (show)

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.
Clone Of:
Environment:
Last Closed: 2019-08-06 12:59:10 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:2152 None None None 2019-08-06 12:59:32 UTC

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


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