Anchors and DNs

Each object has two different identifiers: an anchor and a dn.

Anchor

The anchor is used to identify an object in the remote directory and the definition is "immutable during the lifetime of an object". If the anchor attribute is changed, it should be treated by the sync engine as a delete of the object (and an add of a new object).

In the best case during delta import, the anchor is provided by the remote directory on every change (regardless of the DN). The reason is that it allows the sync engine to understand out-of-order changes reading a delta change log. As an example, think of Active Directory. During delta import, both the anchor and DN are provided in the delta stream. If the sync engine sees that the anchor value does not match the expected value for the DN, it assumed that there was a rename (or delete) of the original object and it hasn't seen that change yet. In Active Directory with replication, this can happen. The sync engine creates a "phantom" waiting for the other change to come it so it can resolve what to do with the older object.

Return anchor during export

When an object is provisioned into the connector space from the metaverse, the DN must always be provided. But the anchor might not be known. The anchor is commonly a GUID generated by the remote directory. A connector has the ability to return the anchor value back to the sync engine on export.

DN

The distinguished name (DN) attribute is used for how other objects should reference the object.

The connector space

Even if you use an ECMA2 DN-style that is not using DN, in the connector space database, the anchor is copied to the DN attribute by the sync engine to ensure both attributes are populated. In the sync engine database, the internal requirement is actually not what you might think - DN is required and anchor is not required.