I am trying to update password policy with new customized pwd policy. Present pwd policy which assigned is cn=unixpasswdpolicy,..dc=xx,dc=com".
I have tried from both console and command(DSEE 6.3). Its saying that target DN has been modified as its saying console also "successfully assigned pswd policy"
But when i checked from console and command..It is still showing old pwd policy i e cn=unixpwdpolicy...
here its command im checking
/ldapsearch -h sxxx -p 389 -D "cn=directory manager" -w-? -b "ou=ggg,dc=wer,dc=abc,dc=com" uid=1234 "pwdPolicySubentry"
Note: i think this is right command to check a user's pwd assigned pwd policies anyway console also showing the old pwd policy"
Kindly help me with how can i assign a new new pwd policy and also how to confirm myself that whether has it been updated with new pwd policy?
Doubt: Shall we assign two pwd policies to a single user? and Why it is still showing old pwd policies when it has shown the success status?
Thanks for your help
Edited by: 980770 on Jan 21, 2013 2:19 AM
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.
unfortunately, no permission to stop the server to run db2ldif..I have tried below command
./dsconf export -h host -p port -f not-print-entry-ids -s ou=people,dc=example,dc=com -s ou=contractors,dc=example,dc=com dc=example,dc=com
instance-path/ldif/export.ldif (as Oracle doc)
it saying that wrong operands.. Do u find anything wrong in this command,
I am quite new to the COS definitions, can you pls share any link on the same
Thanks for your help as always
Edited by: 980770 on Jan 23, 2013 12:05 AM
Ok, perhaps you should just skip to looking at the COS definitions.
To search for COS definitions, use a filter like:
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.
This is the output for "(&(objectclass=LDAPSubEntry)(objectclass=cosSuperDefinition))"
cosAttribute: pwdPolicySubentry operational
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!!!
Thanks in Advance for your reply
Yes, that's how COS works. It's one of the more sophisticated features of the product, and it can save you a lot of administrative work, though it does take some getting used to.
Your COS definition also indicates that the specifier is nsrole, which means this is a role-based COS. So now you need to learn about that:
The templates that are governing this behavior are located in:
You should look in that container for cos templates:
ldapsearch -b cn=PolicyTemplateContainer,ou=people,ou=ccc,dc=vvv,dc=abc,dc=com "(&(objectclass=LDAPSubEntry)(objectclass=costemplate))"
In there you will find the template that's currently assigning the value of pwdPolicySubentry to your users. It will have the attributes:
The cn will be the DN of the role that gets the COS, and the pwdPolicySubentry will be the value to place on the users.
Now, since the COS is simply acting based on the roles, you also need to learn about roles:
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.
Hope that helps.
Yes it is. It is so helpful.Now i understood CoS and Role and how it works.
this is the output for ldapsearch -b cn=PolicyTemplateContainer,ou=people,ou=ccc,dc=vvv,dc=abc,dc=com "(&(objectclass=LDAPSubEntry)(objectclass=costemplate))"
Adding to that this is the role (FYI)
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 ?
Thank you very much
Edited by: 980770 on Jan 24, 2013 8:24 AM
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.
Sorry Chris, I was out of town.
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!!