3 Replies Latest reply: May 6, 2014 11:14 AM by stan25 RSS

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

    user5527480

      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

        • 1. Re: Introducing a custom Password policy to expire passwords. odsee 11g - what are the expected results
          Sylvain Duloutre-Oracle

          Hello,

           

          I think there is no perfect solution. In your case, the password policy requires the presence of the pwdChangeTime attr to trigger

           

          You can

          - 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.

           

          -Sylvain

           

          ------

          When closing a thread as answered remember to mark the correct and helpful posts to make it easier for others to find them

          • 2. Re: Introducing a custom Password policy to expire passwords. odsee 11g - what are the expected results
            user5527480

            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.

            • 3. Re: Introducing a custom Password policy to expire passwords. odsee 11g - what are the expected results
              stan25

              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.

               

              Thanks!