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?
1 person found this helpful
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
DESC 'Sun Directory Server Password Policy objectclass'
MUST ( cn )
MAY ( description $
X-ORIGIN 'Sun Directory Server' )
DESC 'Password Policy objectclass'
MUST ( pwdAttribute )
MAY ( pwdMinAge $
X-ORIGIN 'Password Policy for LDAP Directories Internet Draft' )
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.