Overview#

Shows some DirXML Example and XPATH Example for working with DirXML.

modifyTimestamp#

When you are using LDAP to view Objects in eDirectory you may have noticed the modifyTimestamp.

The modifyTimestamp attribute is helpful if you are checking if something has been changed in a period of time. However if you look at eDirectory from IDM for the modifyTimestamp attribute you will not find it.

The modifyTimestamp you see in the LDAP view is actually the Timestamp of the modifiersName attribute in eDirectory.

You can query the modifiersName attribute in IDM following the next steps:

Query modifiersName of an object into a local variable as a nodeset. With XPATH you can use DirXML Variables/@Timestamp to get the modifyTimestamp.

Keep DirXML from Loading#

We have run across a couple of time when we needed IDM to NOT load when starting eDirectory. What we found moving all the libdxevent* and libvrdim* files into another directory (creating a temp directory underneath their current location).

Then start eDirectory.

We have found two occasions when this has come up.

• Once a bad Activation certificate was put in for IDM and eDirectory dropped hard.
• The file system that held eDirectory went read-only. The server was re-booted; but eDirectory would not load.

Working with AUXILIARY ObjectClasses#

DirXML filters only look at the base (aka effective or STRUCTURAL) class of an object, so if you want the attributes to synchronize you need to add them to the filter for User and removed the entry for the AUXILIARY class altogether.

The only other piece of the puzzle is that somewhere in your policies you are going to have to arrange to add the AUXILIARY class to the ObjectClasses attribute in the LDAP directory.

Usually the easiest way to deal with AUXILIARY ObjectClasses in DirXML is to pretend that they don't exist and that their attributes are just part of the LDAP Entry.

Add the attributes to the filter and schema mapping for the base class (most often user) and they will automatically sync in and the aux class will be added automatically if IDM detects that it is needed.

The exceptions to this are:

1. If the attributes could come from more than one aux class, IDM will automatically add all aux classes that they could come from and you have to strip out the ones you don't want in the Publisher Command Transformation.

2. Any attributes you add via direct command from policy or that are injected in the publisher command transformation will not have aux classes added automatically.

Also if you want the aux class to be put on the object at creation time even though none of the attributes might be needed at that time, then you would usually do this by adding the name of the class to the Object Class attribute in a publisher creation policy.

---

Copy Entry#

A client wanted to copy every object that was ever deleted or renamed to a "deleted-users" container. Altthough we have not worked out all the details yet, the idea is to:

On Delete#

• Disable the account.
• Remove the user from all groups
• Move the user entry to the "deleted-users" container.
• Rename the entry
• Remove the association.

On Rename#

This one is a little tricky. We have two entries to work with. here is what was proposed.

• Disable the account.
• Remove the user from all groups
• Move the user entry to the "deleted-users" container.
• Rename the entry
• Remove the association.
• Issue a "sync" of the Entry form the Identity Vault. This would create a new entry as the "moved" entry is no longer associated.

Overview Of Linux-Unix Fanout Driver#

You can also circumvent using the iManager plug-in by pointing your browser directly to port 3451.. this may eliminate the possiblility of a iManager or iManager plug-in bug.

Category#

DirXML

More Information#

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

• IDMDeveloperInfo