If you are modifying the pwdPolicySubentry attribute on your test user, but ldapsearch is not returning the data you expect, that's probably a bit puzzling. The only explanation I can think of offhand is that you may have a COS that's overriding the real values on your user. To see whether this might be the case fairly easily, look at an ldif export (not via ldapsearch but via db2ldif) and see if your expected value is sitting on the entry in the export file. Another way to check - which you'll have to do eventually anyway - is to look at all your COS definitions to see if you have one that's overriding the real value of pwdPolicySubentry with a computed value.
Note that the special objectclass LDAPSubEntry is needed in the filter, because without it these entries will remain hidden, despite matching the remaining components in the filter. This is a property of the LDAPSubEntry objectclass.
If you want to paste in your COS definitions, we can look them over.
And also i noticed that in oracle documentation *"If the CoS attribute is defined with the operational or override qualifiers, you cannot perform write operations on the “real” value of that attribute in any entry in the CoS scope"*
is this reason i am not able to override the value of pwdpolicysubentry? between i have also tried delete the present pwdpolicysubentry attribute value and add the new value..still its showing the same ..strange!!!
Roles can be assigned directly, via the real attribute nsroledn, by application of a filter on the role object, or by both via nested roles. The most flexible framework is to use three roles for each COS, one managed (which can be granted simply by writing the DN of the role into the nsroledn attibute on the user), one filtered (which assigns the filtered role by application of an LDAP filter), and one nested (which contains both the managed and filtered roles as members). That way you can capture large categories of users by filter and add singeltons as exceptions, and they will all have the nested role. The nested role would be used as the COS cn, so any user meeting either the filter or exception criteria would get the COS-assigned attribute.
Of course you may not have such a complex role implementation. If you want to paste your roles into the thread, we can look them over. They are similar to COS objects in that they also have objectclass LDAPSubEntry.
At this point you have several options:
1. Modify the existing COS template to point to your new password policy. This makes sense if you want to change the policy for all the users who have that role.
2. Create a new role and associated COS template. This makes sense if you have a distinct subset of users who can be conveniently specified in a role and should be getting the new password policy.
3. Remove all roles from the user so it is no longer in scope of any COS. Then you should be able to update the entry as usual. Take care with this because other features within and outside of the Directory may be interacting with the roles.
Since someone at your site took the time to set up a role based COS framework, I would also be looking for any documentation that explains the scope and rationale of the implementation.
description: filtered role for unix users
You said i have i have several options, but option 3 you have given seems not feasible since i had remove the user from role and option 1 also not going to work as i need to enable new pwd policy to only that user, so how can i do it without moving away from that role and assign new pwd policy only to him?
there are some users which are getting exception from thsi pwd polcies (UNIX pwd polcies ) i can see them in
ldapsearch -D "cn=Directory Manager" -w - -b "ou=ou=people,ou=ccc,dc=vvv,dc=abc,dc=com" "cn=*" dn nsrole pwdPolicySubentry
How can i make this only user to get exempting from that pwd plocy and assign new pwd policy ?
You may be able to use the cospriority to give another cos template higher priority. I wonder if that's how your other exception cases are getting a different password policy. Could you paste LDIF of one of the users who has objectclass posixaccount but does not have the unix password policy? If an exception framework has already been devised for your Directory, the first option to explore is simply to reuse what you've already got.
It is showing me zeo results when i tried with objectclass=posixacount and not cn=unix passwpord policy.
I thinking to create a group and assign a user to that group and define, with cos prioiry is 0 which is high..hope it would make reflect to new password policy
n: cn="cn=pwd for user,ou=people,ou=ccc,dc=vvv,dc=abc,dc=com"
pwdPolicySubentry: cn=new password policy,ou=ou=people,ou=ccc,dc=vvv,dc=abc,dc=com
is it going to work, im not touching the clready existed roles or CoS..Pls share your thoughts on this
You'll need to make it a role instead of a group, but otherwise that should work.
I stilll don't understand the use case, really, so I can't say if this is the best design for the problem you are trying to solve. I have a sneaking suspicion it's not, but that may not be within the purview of this forum.
we are working on much improved filtered role to meet the business logic, hope it will work otherwise will raise SR with oracle, thanks chris for your thoughts, it had given me some great tiips, Thanks you so much!!