On 03/26/2013 11:14 AM, Jovan.VUKOTIC(a)sungard.com wrote:
I have 389 DS (126.96.36.199 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
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:
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
Finally, and the most confusing case:
1) cosattribute: pwdpolicysubentry
2)cosattribute: pwdpolicysubentry operational
returned them all as if the qualifier in 2) have impact on CoS 1)
Do you know if my version(188.8.131.52) 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 184.108.40.206? If you can reproduce this
issue with 1.2.11 or later, please file a ticket at
389 users mailing list