Hi,
I have 389 DS (1.2.10.7 version) I am getting confusing ldapsearch results when I use two classic CoS entries defined under the same subtree in order to have the subtree accounts assigned with one of two different values of a shared/generated attribute - in my case pwdpolicysubentry attribute.
I want to point out that a mechanism of generating shared attributes by both CoS entries work as expected and that I defined them via bash script and not over 389 Management Console or ns-newpwdpolicy.pl script(they both work with pointer CoS and I needed classic CoS). Also, all generated attributes are visible in the Console. This is also ok.
In the first test, I had in both CoS's definition entries (I will mark them here as 1) and 2) ) the "operational-default" qualifier: cosattribute: pwdpolicysubentry operational-default.
Hence, I expected that the below search would not return any of the entries with generated attributes... but it did -all of them. (Entries were returned without generated attributes: this is OK as pwdpolicysubentry is an operational attribute)
# ldapsearch -x -ZZ -h localhost -D "cn=directory manager" -b "ou=people,dc=example,dc=com" -w secret -s sub "(pwdpolicysubentry=*)" "*"
I got the same result when in both 1) and 2) a qualifier was just cosattribute: pwdpolicysubentry operational that I consider as correct.
When I modified 1) and 2) CoS definition entries to be: cosattribute: pwdpolicysubentry the ldapsearch returned none of them, but only an entry that has pwdpolicysubentry of its own. Nothing changed when I put "default" qualifier explicitly. What I expected was to return all entries - those with their own pwdpolicysubentry and the others (with the generated one). (In my example, entries with generated attributes do not have their own attributes).
Finally, and the most confusing case:
1) cosattribute: pwdpolicysubentry while in
2) cosattribute: pwdpolicysubentry operational returned them all as if the qualifier in 2) have impact on CoS 1) qualifier (?!)
Do you know if my version(1.2.10.7) of the server has any bug related to CoS definitions or I am something wrong? If you need more information, please ask.
Thank you, Jovan Vukotic
On 03/26/2013 11:14 AM, Jovan.VUKOTIC@sungard.com wrote:
Hi,
I have 389 DS (1.2.10.7 version)
I am getting confusing ldapsearch results when I use two classic CoS entries defined under the same subtree in order to have the subtree accounts assigned with one of two different values of a shared/generated attribute – in my case pwdpolicysubentry attribute.
I want to point out that a mechanism of generating shared attributes by both CoS entries work as expected and that I defined them via bash script and not over 389 Management Console or ns-newpwdpolicy.pl script(they both work with pointer CoS and I needed classic CoS).
Also, all generated attributes are visible in the Console. This is also ok.
In the first test, I had in both CoS’s definition entries (I will mark them here as 1) and 2) ) the “operational-default” qualifier:
cosattribute: pwdpolicysubentry operational-default.
Hence, I expected that the below search would not return any of the entries with generated attributes… but it did –all of them.
(Entries were returned without generated attributes: this is OK as pwdpolicysubentry is an operational attribute)
# ldapsearch —x —ZZ —h localhost —D “cn=directory manager” —b “ou=people,dc=example,dc=com” —w secret -s
sub “(pwdpolicysubentry=*)” “*”
I got the same result when in both 1) and 2) a qualifier was just
cosattribute: pwdpolicysubentry operational
that I consider as correct.
When I modified 1) and 2) CoS definition entries to be:
cosattribute: pwdpolicysubentry
the ldapsearch returned none of them, but only an entry that has pwdpolicysubentry of its own.
Nothing changed when I put “default” qualifier explicitly.
What I expected was to return all entries – those with their own pwdpolicysubentry and the others (with the generated one). (In my example, entries with generated attributes do not have their own attributes).
Finally, and the most confusing case:
- cosattribute: pwdpolicysubentry
while in
2)cosattribute: pwdpolicysubentry operational
returned them all as if the qualifier in 2) have impact on CoS 1) qualifier (?!)
Do you know if my version(1.2.10.7) of the server has any bug related to CoS definitions or I am something wrong?
If you need more information, please ask.
I don't know, but why are you using 1.2.10.7? If you can reproduce this issue with 1.2.11 or later, please file a ticket at https://fedorahosted.org/389/newticket
Thank you,
Jovan Vukotic
**
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
389-users@lists.fedoraproject.org