#48943 When fine-grained policy is applied, a sub-tree has a priority over a user while changing password
Closed: Fixed None Opened 2 years ago by spichugi.

Description of problem:
If we setup fine-grained policy for a subtree and for a user under it and set passwordChange attribute to 'on' for the user and 'off' for the subtree, we wouldn't be able to change password while binding as user.
But, by the feature logic (thanks to Noriko for the info), fine-grained pwdpolicy on the entry has a priority over fine-grained pwdpolicy on the subtree the entry belongs to.

Version-Release number of selected component:
389-ds-base-1.3.5.10-5.el7.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Install Directory Server instance
2. Add a user to 'ou=people,dc=example,dc=com'
3. Set up password policy for the user and the subtree
4. Set passwordChange on the user pwdPolicy entry to 'on'
5. Set passwordChange on the subtree pwdPolicy entry to 'off'
5. Try to change userPassword binding as the user

Actual results:
UNWILLING_TO_PERFORM: {'info': 'user is not allowed to change password', 'desc': 'Server is unwilling to perform'}

Expected results:
User should be able to change a password

Additional info:
Looks like a regression, because TET CI test runs show no issue on the 389-ds-base-1.3.4.0 build


While writing the reproducer, I've accidentally written a test suite for the Password Policy feature. But it is only a small part about passwordChange attribute and its behaviour in the fine-grained policy.

Looks good, but I think this should perhaps go into one of the password suite tests: ds/dirsrvtest/tests/suite/password/*. It's testing more core functionality than a single bug fix.

Either way you get my ack.

To ssh://git.fedorahosted.org/git/389/ds.git

Pushed to master:
17dc978..a20538f master -> master
commit a20538f
Author: Simon Pichugin spichugi@redhat.com
Date: Thu Jul 28 11:53:47 2016 +0200

Maybe this is me but I'm not seeing how this patch fixes the problem? The issue Simon describes is that if you have:

{{{
ou=People
pwdpolicysubentry: cn=policy_subtree

uid=user,ou=People
pwdpolicysebentry: cn=policy_user
}}}

That cn=policy_subtree is enforced when it should be cn=policy_user.

So I'm not 100% sure why your code "fixes" the problem. Do you mind explain to me what is happening?

The original code is just getting the virtual attribute values which "type" is "pwdpolicysubentry".
{{{
- rc = slapi_vattr_values_get(e, "pwdpolicysubentry", &values,
- &type_name_disposition, &actual_type_name,
- SLAPI_VIRTUALATTRS_REQUEST_POINTERS, &attr_free_flags);
}}}
As ldapsearch does not guarantee the order of the search results, this retrieving virtual attribute values would return the attribute values in any order. In this case, instead of cn=policy_user (expected), it returns cn=policy_subtree and 2 of the Simon's test cases failed.

As you see ns-newpwpolicy.pl, it adds the pwpolicysubentry for the user's policy to the user entry. So, I took the advantage.
{{{
id 10
rdn: uid=simplepaged_test
[...]
pwdpolicysubentry: cn=cn\3DnsPwPolicyEntry\2Cuid\3Dsimplepaged_test\2Cou\3Dpeo
ple\2Cdc\3Dexample\2Cdc\3Dcom,cn=nsPwPolicyContainer,ou=people,dc=example,dc=
com
}}}

If it does not exist, then we could consult CoS as we do before, which finds out the subtree policy.

Yep that makes sense. Ack from me.

Reviewed by William (Thanks!!)

Pushed to master:
a12dc36..802224f master -> master
commit 802224f

Metadata Update from @spichugi:
- Issue assigned to nhosoi
- Issue set to the milestone: 1.3.5.12

2 years ago

Login to comment on this ticket.

Metadata