The CoS functionality is a complex mechanism which, for performance and security reasons, is subject to the following limitations:
You cannot create CoS definitions in either the cn=config or cn=schema subtrees.
Searches in suffixes where an attribute is declared as a CoS-generated attribute will result in an unindexed search. This may have a significant impact on performance. In suffixes where the same attribute is NOT declared as a CoS attribute, the search will be indexed.
Restricted attribute types
The following attributes should not be generated by CoS because they do not have the same behavior as real attributes of the same name.
userPassword - A CoS-generated password value cannot be used to bind to Directory Server.
aci - Directory Server will not apply any access control based on the contents of a virtual ACI value defined by CoS.
objectclass - Directory Server will not perform schema checking on the value of a virtual object class defined by CoS.
nsRoleDN - A CoS-generated nsRoleDN value will not be used by the server to generate roles.
All templates must be local
The DNs of template entries, either in a CoS definition or in the specifier of the target entry, must refer to local entries in the directory. Templates and the values they contain cannot be retrieved through directory chaining or referrals.
CoS virtual values cannot be combined with real values
The values of a CoS attribute are never a combination of real values from the entry and virtual values from the templates. When the CoS overrides a real attribute value, it replaces all real values with those from the templates. However, the CoS mechanism can combine virtual values from several CoS definition entries. For more information, see “CoS Limitations” in the Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide.
The filter string of a filtered role cannot be based on the values of a CoS virtual attribute. However, the specifier attribute in a CoS definition may reference the nsRole attribute generated by a role definition. For more information, see “Creating Role-Based Attributes” in the Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide.
The server controls access to attributes generated by a CoS in exactly the same way as regular, stored attributes. However, access control rules that depend on the value of attributes generated by CoS are subject to the conditions described in CoS Limitations.
The CoS cache is an internal structure that keeps all CoS data in memory to improve performance. This cache is optimized for retrieving CoS data to be used in computing virtual attributes, even while CoS definition and template entries are being updated. Therefore, once definition and template entries have been added or modified, there may be a slight delay before they are taken into account. This delay depends on the number and complexity of CoS definitions, as well as the current server load, but it is usually in the order of a few seconds. Consider this latency before designing overly complex CoS configurations.