CoS is “Class of Service”, a feature of Netscape family directory servers that allows for the dynamic generation of attributes and their values from a template.
With or without thousands of CoS definitions, once you start approaching the limit of having different CoS schemes for every target entry or two, you are better off paying the management price of updating the real values, thereby gaining the performance price of reading real, rather than CoS-generated values.
There’s a really good discussion of CoS here:
Part 12, Directory Server Class of Service, Directory Server Reference, ODSEE 11gR1
The possible use of CoS for something like provisioning custom password policies was the first chance I got to really dig in to it. Following is some basic steps to use it in just that way. Hopefully someone will find it illuminating. In the end I decided not to use CoS for this purpose because of my concern about impacts on directory performance.
Steps to use CoS for provisioning custom password policies:
First you create a Filtered policy role (one that applies to every entry that matches the LDAP filter):
dn: cn=ContractorFilteredRole,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: nsRoleDefinition objectclass: nsComplexRoleDefinition objectclass: nsFilteredRoleDefinition cn: ContractorFilteredRole nsRoleFilter: (&(objectclass=inetorgperson)(employeetype=Contractor)) description: Filtered role for Contractors
Then a CoS policy Template container and CoS policy Template to assign the policy to the class:
dn: cn=ContractorCosPolicyTemplate,dc=example,dc=com objectclass: top objectclass: nsContainer dn: cn="cn=ContractorFilteredRole,dc=example,dc=com", cn=ContractorCoSPolicyTemplate,dc=example,dc=com objectclass: top objectclass: extensibleObject objectclass: LDAPsubentry objectclass: costemplate cosPriority: 1 pwdPolicySubentry: cn=TempPwdPolicy,dc=example,dc=com
And finally the “Classic” CoS policy Definition Entry to effect the class:
dn: cn=ContractorCoSPolicy,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: cosSuperDefinition objectclass: cosClassicDefinition cosTemplateDN: cn=ContractorCoSPolicyTemplate,dc=example,dc=com cosSpecifier: nsRole cosAttribute: pwdPolicySubentry operational
Why do you clutter up your domain root with all that policy and CoS stuff? The short answer is, “because that’s how it has always been done.” Sometimes the examples given in documentation establish a pseudo convention that becomes established. There is actually a better reason: if you follow a pattern that puts all that kind of cruft up in the root it will be easier to find by those who follow (you are grooming your “heir” by now, aren’t you?). This is why I always put my acis (Access Control Instructions) in the domain root..