IDB Renames - Multiple Successive Renames on the same object fail on the second FIM confirming import.

Hey Guys,

I've uncovered a new issue with IDB in regards to renames.

This issue occurs when multiple renames are perfomed on the same object. I've performed a significant ammount of testing and analysis on this issue, which i'll explain in detail below, but in each case, after the second rename, the confirming import in FIM produces one or more need-full-object errors. I also believe I have determined where the issue is being produced.

In most cases, this is the general procedure for producing the issue:

1. Rename user (uid) in Active directory and produce a Provisioning Rename for Export to TAM.
2. Export rename to TAM (Successfull)
3. FIM Delta Import confirms rename. (Successfull)
4. Rename same user again in AD.
5. Export rename to TAM (Successfull)
6. FIM Delta Import - need-full-object error produced.

In each case the rename is successfully exported to TAM, and i have confirmed that in all cases the Modify Anchor method on the connector is being hit.

These are the cases tested, and the results:
(All UNIFYDelta files for these cases are in the attached ZIP)

1. - Rename user cladn3 to cladn30, and then rename back to cladn3.
2nd Import Result - need-full-object error produced on cladn3

2. - Rename user kxhep0 to kxhep50, and then rename again to kxhep70.
2nd Import Result - need-full-object errors produced on both kxhep70, and kxhep0

3. - Rename user uxngt0 to uxngt05. Perform an IDB full import, then rename user back to uxngt0.
2nd Import Result - need-full-object error produced on uxngt0

4. - Rename user ulgni1 to ulgni10. Perform a FIM full import, then rename user back to ulgni1.
2nd Import Result - need-full-object error produced on ulgni1

5. - Rename user ugfen1 to ugfen10. Perform an IDB & FIM full import, then rename user back to ugfen1.
2nd Import Result - need-full-object error produced on ugfen1

6. - Rename user bxttt0 to bxttt05. Drop IDB Connector Partition and FIM CS, then Reimport. Rename user back to bxttt0.
2nd Import Result - Rename successfull.

The need-full-object error is defined here: http://support.microsoft.com/kb/818559
We've seen this error before on QDET-156, and it occurs when an update operation is attempted on an object before the object is sucessfully renamed. The rename is completed by the presence of a moddn operation in the delta ldif file. Until this operation is processesd, the object in FIM retains it's original DN.

In viewing the UNIFYDelta ldif files produced on the second confirming import, the issue becomes apparant.

In the cases where the uid was changed back, no moddn entry is present to confirm the rename. Updates present for the object fail with the error as explained above.

In case 2, where the uid was renamed again to a different uid, the ldif file did contain a moddn, but it was incorrect. As above in this case, the first rename was from kxhep0 to kxhep50, and the second from kxhep50 to kxhep70. The second moddn (see below) was trying to rename from kxhep0 to kxhep70.

The moddn for the first rename in this case looked like this:

dn: UID=kxhep0,CN=Users,DC=DET,DC=QLD,DC=GOV,DC=AU
changetype: moddn
newrdn: UID=kxhep50
deleteoldrdn: 1
newsuperior: CN=Users,DC=DET,DC=QLD,DC=GOV,DC=AU

This is correct, and the rename was successful.

The second rename:

dn: UID=kxhep0,CN=Users,DC=DET,DC=QLD,DC=GOV,DC=AU
changetype: moddn
newrdn: UID=kxhep70
deleteoldrdn: 1
newsuperior: CN=Users,DC=DET,DC=QLD,DC=GOV,DC=AU

This is incorrect, as it is trying to rename from kxhep0 to kxhep70, but at this point in FIM, the DN is kxhep50.

After seeing this error, i performed some analysis on the database to monitor the status of the records around a simlilar operation. In this case i renamed a user from uxnnt3 to uxnnt30, and then to uxnnt31.
The results of this trace are in the attached excel sheet, but i was able to note that throught all of the exports and imports, the DN field on the entity table remained unchanged from it's initial state.

The fact that this field is not being updated explains all of the above issues. When the uid is being renamed as in case 2, it produces a moddn from the DN present, to the required DN. In cases where the uid is being changed back, as it allready has the same value in the DN field, it does not produce a moddn as assumes none is required.

It looks like this field is used to create the moddn entry, particularly in specifying the current DN of the object. On the second rename, the moddn entry is produced incorrectly, as the DN was not updated after the first rename. The result of this is that the rename is not confirmed on the FIM import, and remains in the state of awaiting export confirmation.

To summarise all of the above, i've confirmed that on rename operations within IDB, the DN field of the entity table is not updated to reflect the new DN of an object. The result of this causes issues when creating the moddn entries after a second object rename.