Active Directory Cookbook

4.13. Dynamically Linking an Auxiliary Class

Tip

This recipe requires the Windows Server 2003 forest functional level.

Problem

You want to dynamically link an auxiliary class to an existing object instance.

Solution

In each solution below, an example of adding the custom rallencorp-SalesUser auxiliary class to the jsmith user object will be described.

Using a graphical user interface

1. Follow the directions for Recipe 4.11.

2. Edit the values for the objectClass attribute.

3. For “Value to add,” enter rallencorp-SalesUser.

4. Click Add.

5. Click OK twice.

Using a command-line interface

Create an LDIF file called dynamically_link_class.ldf with the following contents:

dn: cn=jsmith,cn=users,dc=rallencorp,dc=com
changetype: modify
add: objectClass
objectClass: rallencorp-SalesUser
-

then run the following command:

> ldifde -v -i -f dynamically_link_class.ldf

Using VBScript

const ADS_PROPERTY_APPEND = 3
set objUser = GetObject("LDAP://cn=jsmith,cn=users,dc=rallencorp,dc=com")
objUser.PutEx ADS_PROPERTY_APPEND,"objectClass",Array("rallencorp-SalesUser")
objUser.SetInfo

Discussion

Dynamically linking an auxiliary class to an object is an easy way to use new attributes without modifying the object class definition in the schema directly. In Windows 2000, auxiliary classes could only be statically linked in the schema. With Windows Server 2003, you can dynamically link them by appending the auxiliary class name to the objectClass attribute of an object.

A situation in which it makes more sense to dynamically link auxiliary classes rather than link them statically is when several organizations or divisions within a company maintain their own user objects and want to add new attributes to the user class. Under Windows 2000, each organization would need to create their new attributes and auxiliary class in the schema, and then modify the user class to include the new auxiliary class. If you have 10 organizations that want to do the same thing, user objects in the forest could end up with a lot of attributes that would go unused. In Windows Server 2003, each division can instead create the new attributes and auxiliary class, and then dynamically link the auxiliary class with the specific objects that they want to have the new attributes. This eliminates the step of modifying the user class in the schema to contain the new auxiliary classes.

It is also worth mentioning that extensive use of dynamically linked auxiliary classes can lead to problems. If several groups are using different auxiliary classes, it might become hard to determine what attributes you can expect on your user objects. Essentially, you could end up with many variations of a user class that each group has implemented through the use of dynamic auxiliary classes. For this reason, use of dynamic auxiliary classes should be closely monitored.

See Also

Recipe 4.11 for modifying an object