Newly created LDAP Group objects have different Attribute and Class mappings

Newly created LDAP Group objects have different Attribute and Class mappings
The LDAP Group created at installation time of the first OES server installed in the tree has a longer list of mappings than a brand new one created with iManager or Console One.
The LDAP Group created when installing the second and subsequent OES servers in the tree have a shorter list than either of the previous ones.

This is working as designed. The purpose of this document is to shed some light about how LDAP Group mappings are created and maintained.

If it's necessary to copy the LDAP Group mappings from one object to another, there is no automated process that you can use. The easiest way to do it though, is to create an LDIF export that extracts all the values for the ldapAttributeList and ldapClassList attributes from a given LDAP Group and then import them into the destination object.

If you compare what the differences are between the LDAP group mappings mentioned in the symptom list, you will notice that you can classify most of them by a common product. The group created by the OES install will contain different mappings depending on which products you chose to install (for example apache or OpenSSH). Some of these products extend the schema using an LDIF file and every schema extension done through an LDIF file will generate a mapping for every attribute and class created. These mappings will be added to the LDAP Group object of the server where the schema extension is taking place and will not affect other LDAP groups present in the tree.

The second time the OES install is run, if the schema has already been extended, the mappings will not be added. This is the reason why the second and subsequent LDAP Groups have a shorter list than the original server.

When creating a new LDAP group with ConsoleOne or iManager, the Attribute and Class mappings will default to a normal list that should be sufficient in most cases. You will notice that there are a few attributes and classes more than in the groups created in the previous two examples. The more notorious ones are the ones related to the attributes and classes that start with NSCP: in their name. If you have a pure eDirectory 8.7.3 tree, you will most likely not even have these attributes in your schema. Starting with eDirectory 8.7 it was decided to leave these schema extensions out of the schema that ships with the product and leave an LDIF file in the schema directory to be able to install them later if needed (normally SYS:\SYSTEM|SCHEMA\NETSCAPE-MAPPINGS.LDIF).
An LDAP Server doesn't need to have a mapping for all attributes and classes that are accessed. If no mapping is found, then a set of rules is applied to the NDS name and a resulting name is formed. These rules are:

 - All non alphanumerical characters are removed (this includes spaces and colons) with the exception of the dash sign.
 - Leading uppercase characters are converted to lower case.
 - The first letter of each of the original words (marked by spaces or colons) is made uppercase, with the exception of the first one.

For example, the attribute "New Object's DS Rights" is turned into newObjectsSDSRights.

When you extend the schema using an LDIF file that contains only an LDAP name and no explicit X-NDS_NAME value (the reference of how this value will be called in NDS) for every attribute or class, the mappings that are created will not be very usefull. They will simply state that both the NDS and the LDAP name are the same. There is no need to try to copy them to other LDAP Group objects.

 
If you want to see how these rules apply to your existing schema, the best way to do so is to do an export of your schema via LDIF. You can so so with the following command:

 ldapsearch -h <host> -D <admin account> -w <admin password> -b cn=schema -s base objectclass=subSchema
Formerly known as TID# 10097818