RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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-09-13 22:16 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:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 3112 0 None closed Subtree password policy overrides a user-defined password policy. 2020-12-10 09:21:05 UTC
Red Hat Product Errata RHBA-2019:2152 0 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.