Novell IDM Best Practices: Don’t Forget the Small Stuff

Novell IDM Best Practices: Don’t Forget the Small Stuff

When developing a Novell IDM driver its easy to get focused on requirements and lose track of the little things that can come back to bite you later on. The perfect example of this is the DirXML-Associations attribute.

This handy little attribute is typically automatically set by a driver to establish a relationship between an object in eDirectory and the object in the driver’s connected system.  When this value is set for a specific driver it allows future changes to be processed more quickly and efficiently.  These relationships are stored in eDirectory on the object and consist of the unique identifiers from the connected Microsoft systems; for example, the Microsoft Active Directory driver leverages the Active Directory’s GUID value for the account to create the association in eDirectory.

The problem is that once these associations are created there are only two ways of getting rid of them.  The most obvious way is to delete the associated object in eDirectory.  If the object holding the values is deleted then it goes without saying that the values are deleted.  This method doesn’t require any additional coding or consideration in the driver.

The other method is to remove the association value from the attribute in eDirectory either manually (not recommended) or programmatically by creating a policy in the driver that contains the Remove Association action.  This means that someone has to create a policy or policies that contain a number of conditions to determine if/when an association should be removed.  The only thing is that in the course of requirements gathering and design these use cases and conditions are overlooked and not documented and therefore do not get implemented.

More often than not requirements simply dictate that a driver is not to delete objects out of eDirectory.  The natural instinct is to create a simple policy that checks to see if the current transaction is a delete event and if so to do a simple veto action.  The veto action will stop the transaction from processing through the driver to eDirectory and will result in the eDirectory object being unchanged, including the driver association.

So what’s the issue with keeping a driver association in eDirectory after the object/account/record has been deleted out of the connected system?  Well, simply put, it causes errors! This is because of how the driver detects and uses the association values in the DirXML-Associations attributes for more efficient transaction processing its a problem to have an association for a driver that points to a nonexistent record.

The result is that when an transaction for an object in eDirectory in such a state processes through the associated driver the driver will use the invalid association as its target reference.  This causes the transaction to result in an error because the target reference no longer exists.  The obvious result of this is that no changes are made in the target system.

On the flip side of things, if an unassociated object/account is created/modified in the target system and the driver attempts determines that the record in questions matches are previously associated eDirectory record the driver will attempt to merge the records and create a new association in eDirectory with the new account.  This causes an issue too.  An eDirectory object is only allowed to have one association per driver and since the driver already has an association for the old record on the eDirectory object the merge process will fail and the driver logs will record an error along the lines of “Object already associated“.

In either case the obsolete associations in eDirectory essentially defeat the purpose of having an identity management system.  Removing an association through driver policies is simple to do and can go a long way in developing a system that delivers reliable identity management capabilities between the various connected systems.  So the next time you are planning a driver or get a requirement that demonstrates the use case where the relationship between eDirectory and a connected system is being destroyed remember to clean up the association.

Questions, comments or concerns? Feel free to reach out to us below or at IDMWORKS