General Driver Design Guidelines#

Limit the traffic that one connected system sends to another#

You want to do as much fitlering and checking on the subscriber channel as possible. Yes, you can just send all events out and then let the other system filter it, but then you are processing extra events and putting extra traffic on the wire. So don't just send events blindly out the subscriber channel! Be efficient about things.

Creating user objects in eDirectory#

When creating objects in eDirectory, always apply a template even if there isn't much to done with the template today, it will provide the customer with the flexibility after to easily modify the way objects are provisioned without having to modify the drivers.

Special Events#

  1. Moves A Move should always be blocked in the sub-scriber channel. Please explain? Moves are as often transformed as blocked
  2. Renames
  3. Sync Events
  4. Resync
  5. Heartbeat
  6. Deletes
  7. Add - When would you want to block an Add? Probably not too often, since and add might become a modify in the next system if the matching rule finds and links up a match.


There are many attribute topics; indexing, creating aux classes, using base attributes, new classes, attribute filters, etc. CN can be a multi-valued attribute, since it is retrieved for many operations, please work with your customer to not populate multiple values for the CN. When a multi-valued attribute is retrieved there is no ordering of which value is retrieved first, so you cannot be assured you will retrieve the value you want.

Custom Attributes#

Create custom attributes as needed, use an Aux Class, these aren't as scary as you might think they are and don't take much to get going. You want your attribute design to be self describing, kinda like XML

Use the Right Attributes#

Don't mis-use existing attributes that are in eDirectory to store identity information. For example don't store the user's favorite color in "carLicense" because it is a single valued case ignore string that is rarely used by a product. Take the time and create "customerFavoriteColor"

Don't use an existing mutil-valued attribute when you only need a single valued attribute. This will come back to bite you. Take the time and create a custom attribute.

Attribute Filter List#

Only sync the specific attributes that are required to create objects and those that you will be using.

If you have extra attributes then you are going to generate un-needed and unwanted events and cause an extra load on the system. You will also have more testing to do, that doesn't add a whole lot of value. You also want to make sure that the filters match on both subscriber and publisher channels so that the merge engine doesn't make some value and no value equal no value....Not fun when you loose your group memberships or security equals, end users will be quite upset.

Entitlements and Triggers#

Going forward in IDM3 you really need to use entitlements rather than attributes as triggers.
  1. . Entitlements are more portable from one customer to another
  2. . Entitlements are more supportable for you by the Novell Support organization, rather than custom attributes to generate triggers
  3. . Entitlements will speed up your deployment. IDM3 Drivers are packaged with with policies that support and work with entitlements.

Naming Conventions#

More Information#

There might be more information for this subject on one of the following: