title: Notes on CoS link: https://onemoretech.wordpress.com/2011/12/23/notes-on-cos/ author: lembobro description: post_id: 1666 created: 2011/12/23 13:12:58 created_gmt: 2011/12/23 17:12:58 comment_status: closed post_name: notes-on-cos status: publish post_type: post

Notes on CoS

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.

from Chapter 7, Tuning Class of Service in the Sun Directory Server 5.2 Performance Tuning Guide. 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..

Copyright 2004-2019 Phil Lembo