Introducing a custom Password policy to expire passwords. odsee 11g - what are the expected results

Question

We have left the default Password Policy untouched. As a default password aging is off. Our DS compatibility mode is now DS6 so we can add Password Policies with max age!
Some users need to have their passwords changed regularly due to political reasons.
We have introduced a custom Password Policy which has a pwd_Max_age value of 180 days and allows the user to Change Password. Entry is cn=Custom Pwd Policy for ABC,dc=mycorp,dc=com
Ok. Now we get confused by the behaviour of this ODSEE 11g server. Now, we are ADDING a new custom Password Policy to just a few selected users!
1. When we add the Policy to the user by setting the passwordpolicysubentry attribute = "cn=Custom Pwd Policy for ABC,dc=mycorp,dc=com"
- Nothing seems to happen.
- WHEN IS THE PASSWORD EXPIRED?
2. After we change a password for a user who has the passwordpolicysubentry attribute, he gains a new attribute pwdChangedTime
- IS THIS THE ONLY TIME THE EXPIRY CLOCK STARTS TICKING? *AFTER* THE PASSWORD IS CHANGED?
3. Is it true, that if a user never changes his password, even if he gets the new custom password policy applied, his password never automatically expires????
I just cannot work out what is supposed to happen. I would have hoped that at the very least, the password begins to expires as soon as he gets a Password Policy with pwd_Max_age set.
How is ODSEE 11g designed/supposed to function.
Help!!!!!
*HH

Answer 1

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 11.1.1.7.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.
Mercy Buckets.