I think there is no perfect solution. In your case, the password policy requires the presence of the pwdChangeTime attr to trigger
- reset passwords and force users to change their passwords so that the pwdchangeTime is generated when then change their password
- modify the targetted user passwords as cn=directory manager: search for the encrypted/hashed password then replace it again. This will cause the pwdChangeTime attribute to be generated. Would work if the password policy let you do that (e.g no password history)
- export data to a LDIF file, add the pwdChangeTime attribute manually (using sed/awk) if it is not present and reimport.
When closing a thread as answered remember to mark the correct and helpful posts to make it easier for others to find them
Sylvain ,Many thanks for your reply and suggestions. Always good to have a choice!
So it seems the only way to get the password aging clock to tick is for the password to be changed after having the password policy applied.
Option1 is not really an option although it certainly would make the users change the password and set up the password aging...
The main difficulty with odsee 11g (Version 18.104.22.168.0) is that pwdChangedTime is a system read-only attribute linked to a modification to userPassword attribute, I cannot use ldapmodify to add/modify the pwdChangedTime attribute.
I was amazed that I can read/store the userpassword as the base64 string and replace the userpassword attribute with this value using ldapmodify. This is very easy (and works!) but will cause the pwdChangedTime attribute to contain the same time for all users. I can imagine helpdesk loving it when everyone calls them in 6 months time.
Using the LDIF backup/restore utility looks the best option, if it succeeds. At least we can randomize the actual value of pwdChangedTime with this approach.
Yes, your help desk has to deal with call volume if all user password expires on the same day, some users will call and others will simply change it and move on.
Although we don't have pwd policy on DS11g but we have SiteMinder pwd policy. So to avoid heavy call volume we had to schedule to change pwd for few thousand users every week. In that case you are spreading the pwd expiration date.