3 Replies Latest reply: Sep 30, 2013 3:53 AM by fletches40 RSS

    Adding password policies to historical instance.

    fletches40

      Hi,

       

      Newbie here - just inherited management of our LDAP systems so please be patient.

      We've got a directory instance that has been multiply upgraded. Originally it was based on OpenLDAP  then SUN DS5, through DS6 and now DS7.

      We have a requirement to add password policies to a subgroup within the repository which I believe I have done but it doesn't seem to work.

      So far, taken server from DS5 compat mode to DS6-mode, created password policy via admin interface and applied it to relevant group. Features of the policy are password lifetime, 3 incorrect login attempts, password dictionary etc etc.

       

      Problem: test user tries to log in. After 3 failures there is no lockout. User can fail login any number of times then a correct attempt will work.

       

      The custom policy is set to override the global policy for the affected group.

       

      The question is why is the policy not being followed?

       

      I'm concerned there may be some historical feature of the schema which is preventing the policy from functioning. If this is the case ( and how would I find out if this is so) what might be done about it?

       

      Regards

        • 1. Re: Adding password policies to historical instance.
          fletches40

          Partly answered my own question I think. It looks like we have both objectClass=passwordPolicy from the old SUN ONE incarnation and the current objectClass=sunPwdPolicy in the schema. Given this is so, how do I go about removing the old passwordPolicy from the schema?

          • 2. Re: Adding password policies to historical instance.
            Sylvain Duloutre-Oracle

            Hello,

             

            sunPwdPolicy objectclass contains Sun specific extension and derive from  the standard password policy objectclass defined in passwordPolicy,

            so in general, password policy entries contain both objectclasses as long as you start using Sun extensions

             

            ( 1.3.6.1.4.1.42.2.27.9.2.119

            NAME 'sunPwdPolicy'

            DESC 'Sun Directory Server Password Policy objectclass'

            SUP pwdPolicy

            AUXILIARY

            MUST ( cn )

            MAY ( description $

              passwordRootdnMayBypassModsChecks $

              passwordStorageScheme $

              passwordExpireWithoutWarning $

              pwdIsLockoutPrioritized $

              pwdKeepLastAuthTime )

            X-DS-USE 'internal'

            X-ORIGIN 'Sun Directory Server' )

             

            ( 1.3.6.1.4.1.42.2.27.8.2.1

            NAME 'pwdPolicy'

            DESC 'Password Policy objectclass'

            SUP top

            AUXILIARY

            MUST ( pwdAttribute )

            MAY ( pwdMinAge $

              pwdMaxAge $

              pwdInHistory $

              pwdCheckQuality $

              pwdMinLength $

              pwdExpireWarning $

              pwdGraceAuthNLimit $

              pwdLockout $

              pwdLockoutDuration $

              pwdMaxFailure $

              pwdFailureCountInterval $

              pwdMustChange $

              pwdAllowUserChange $

              pwdSafeModify)

            X-DS-USE 'internal'

            X-ORIGIN 'Password Policy for LDAP Directories Internet Draft' )

             

            -Sylvain

            • 3. Re: Adding password policies to historical instance.
              fletches40

              I believe I have found the problem. It is what appears to be a conceptual error in the design of our schema. An attribute of the selected group of users which has been named "ou" isn't really an "Organizational Unit" though I think that was the original intention. The password policy filters built into the DSEE admin interfaces aren't geared to the structures we have. We will need to reorganize things to make this more manageable. We could still attempt a custom filter based on attribute but it becomes very cumbersome to manage in the future.