A) Design the directory so you never need to move objects, instead update attributes on the objects. It will save you grief if you ever have replication issues.

B) Use IDM to set a custom time attribute which indicates the creation time, e.g., idmCreateTimestamp. This will not be touched if you move the object.

Hi,
Thanks, we may unfortunately not prevent moves A) from happening, and we already had in mind to address it with B), we were just wondering if there is a built-in possibility to determine object creation time.
Regards,
N.

creation time stamp is an 'operational attribute' that can be queried via ldap - here is an example using ldapsearch where i query several of the operational attributes on a user 'test99'

ldapsearch -D cn=admin,o=testlab -W -b o=testlab cn=test99 createtimestamp creatorsname entryflags localentryid modifytimestam

----

dn: cn=test99,o=testlab
creatorsname: CN=admin,O=testlab
localEntryID: 90C7
entryFlags: 0
createTimeStamp: 20230822213615Z
modifyTimeStamp: 20230927202818Z

I have not got an OES server running at the moment to conduct tests, but I wonder if you could not get the object creation time indirectly by retrieving the modification time for an attribute such as GUID which is set at creation time, should not change, and would not be affected by a move operation.

HTH, John

It WOULD change on a move.

From experience I would always check the modify- and createTimestamp using iMonitor if there is any doubt. Just to be sure. 

Not that I doubt that ldap will give the right answer, but iMonitor is the reference. 

To my understanding, the problem is that a move is not really a move but a clone and delete (and the clone will have updated timestamps).

As far as I recall from my ATT Times, as long as the move is in progess, you have 2 objects (old and clone) and both have the obituary-processing until all servers are happy with the change, then the old will be deleted from DIB.

Create yourself an IDM driver to duplicate creationTimestamp from the object into a custom attribute for operation add (and for rollout on sync) to save the date.

When there is an object move, the IDM driver cache will represent it as a move, not as an add/delete, so your driver will not update the custom attribute when moving the object.

Hope it helps to get along

Steffen