#50053 Subtree password policy overrides a user-defined password policy.
Closed: wontfix 5 years ago by mreynolds. Opened 5 years ago by tbordaz.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1652984

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=nsPwPol
icyContainer,ou=TestPWP,o=test
dn: uid=scarter,ou=TestPWP,o=test
pwdpolicysubentry: cn=cn\3DnsPwPolicyEntry\2Cou\3DTestPWP\2Co\3Dtest,cn=nsPwPol
icyContainer,ou=TestPWP,o=test
nscpEntryWSI: pwdpolicysubentry: cn=cn\3DnsPwPolicyEntry\2Cuid\3Dscarter\2Cou\3
DTestPWP\2Co\3Dtest,cn=nsPwPolicyContainer,ou=TestPWP,o=test
dn: uid=tmihinto,ou=TestPWP,o=test
pwdpolicysubentry: cn=cn\3DnsPwPolicyEntry\2Cou\3DTestPWP\2Co\3Dtest,cn=nsPwPol
icyContainer,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/h
tml/administration_guide/advanced_entry_management-assigning_class_of_service#c
os-qualifiers

Metadata Update from @tbordaz:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1652984

5 years ago

Metadata Update from @tbordaz:
- Issue assigned to tbordaz

5 years ago

Metadata Update from @tbordaz:
- Custom field component adjusted to None
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None
- Custom field type adjusted to None
- Custom field version adjusted to None

5 years ago

Fixing the testcase that contained an invalid test for 'merge-schemes' specifier
5d7b95c..f2ff28e master -> master

Metadata Update from @mreynolds:
- Issue set to the milestone: 1.3.9 (was: 0.0 NEEDS_TRIAGE)

5 years ago

please cherry-pick to 1.3.9

This fix was not cherry-picked to 1.3.9, can we please have it there.
Thanks!

2671222..4a01095 389-ds-base-1.3.9 -> 389-ds-base-1.3.9

Metadata Update from @mreynolds:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

5 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/3112

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)

3 years ago

Login to comment on this ticket.

Metadata