Auxiliary Classes and Identity Manager



Identity Manager design usually works best with attributes being used as auxiliary classes, instead of extending base schema. There are some very good reasons for this, one of which is it is very hard to modify base schema. Used to be almost impossible but now it can be done, but it is best not too if possible.

Now that you have defined your attributes, added them as optional attributes to an Aux class, (never as mandatory please; more on that later ...) and used them in your driver, there a couple of "cute" things that can happen.

What happens if the same attribute is used in two or more aux classes? Well, it turns out that IDM will automatically add both aux classes to the user. Otherwise, how would it be able to guess which one you intended?

You can see Aux classes a couple of ways. ConsoleOne calls them Extensions of this object. They are actually stored as values of the Object Class attribute (objectClass in LDAP naming), so any tool that can show you attribute values can show you the list. That would include any LDAP tool, or even Console One and the Other tab.

If you had made one of the attributes in one of the Aux classes mandatory, and if one of the mandatories is missing, you can expect an error from IDM trying to add it. This is because it will try to add all object classes as part of a single operation, which will fail with a -609 error: Missing Mandatory.


If you have this issue, you can strip out the object class add of the unwanted Aux class in a command transform. It can be Publisher or Subscriber, depending on where the create is going.

You can also choose to explicitly add the needed class yourself. Just add a value to the object Class attribute for the object in the event transform, or as part of the Create rule Use Add, not Set, because Set will remove all values and just add the one. You want to incrementally add it.


How To-Best Practice
Comment List
Related Discussions