!!! Overview
Shows some [DirXML Example] and [XPATH Example] for working with [DirXML].
!! [modifyTimestamp|2.5.18.2]
When you are using LDAP to view Objects in eDirectory you may have noticed the [modifyTimestamp|2.5.18.2].
The [modifyTimestamp|2.5.18.2] 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|2.5.18.2] attribute you will not find it.
The [modifyTimestamp|2.5.18.2] you see in the LDAP view is actually the Timestamp of the [modifiersName|2.5.18.4] attribute in eDirectory.
You can query the [modifiersName|2.5.18.4] attribute in IDM following the next steps:
Query [modifiersName|2.5.18.4] 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 lib[vrdim]* 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"|IDM-SYNCoperation] 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
%%category [DirXML]%%
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]