How can you get a 0ACNF mangled RDN with only one DC?

Posted: 10th August 2012 by Christoffer Andersson in Uncategorized

Most tombstones will have their name mangled for deletion e.g. [1] CN=<RDN>\0ADEL:<GUID> and are moved to the “Deleted Objects” container if such exists [2] in the NC the object resides in and if it doesn’t have the DISALLOW_MOVE_ON_DELETE flag.
[2] All NCs except the Schema NC have “Deleted Objects” containers by default – but trust me they can get removed themselves J

The case I’m looking for here is when an object deletion acutely bypasses the requirement to transit to the intermediate state of being a tombstone, deleted object or recycled object before it tries to get physically deleted from the database.

Okay one case to cause this is: Object instanced with the auxiliary class dynamic Object e.g.:

dn: cn=Christoffer Andersson,cn=ESEDEV,DC=ADAM,DC=chrisse,DC=com
changetype: add
objectClass: user
objectClass: dynamicObject
entryTTL: 900

Dynamic objects never transit thru the state of being a tombstone, deleted object or recycled object, they get physically removed once their TTL expires by the garbage collector, however if there is other objects referring to them e.g.

[3] Let’s create an object referencing the dynamic object.
dn: cn=OtherObject,cn=ESEDEV,DC=ADAM,DC=chrisse,DC=com
changetype: add
objectClass: user
seeAlso: cn=Christoffer Andersson,cn=ESEDEV,DC=ADAM,DC=chrisse,DC=com

900 (15min passes) and “cn=Christoffer Andersson,cn=ESEDEV,DC=ADAM,DC=chrisse,DC=com” is about to being physically deleted by the garbage collector, But it’s not cause someone else reference it [3], so it’s rather converted to a (none-object) phantom without being either RDN managed for deletion [1] or moved to the “Deleted Objects” container and it will be stuck here as long as cn=OtherObject,cn=ESEDEV,DC=ADAM,DC=chrisse,DC=com reference it by seeAlso.

Now create an new object named : “cn=Christoffer Andersson,cn=ESEDEV,DC=ADAM,DC=chrisse,DC=com” e.g.:

dn: cn=Christoffer Andersson,cn=ESEDEV,DC=ADAM,DC=chrisse,DC=com
changetype: add
objectClass: user

The phantom will now become CNF mangled, to give room for the new real object that request the same RDN.

e.g. “cn=Christoffer Andersson\0ACNF:<GUID>,cn=ESEDEV,DC=ADAM,DC=chrisse,DC=com”

Bonus to those who know and can list in the comments – the attributes of “cn=Christoffer Andersson\0ACNF:<GUID>,cn=ESEDEV,DC=ADAM,DC=chrisse,DC=com” that are still left one the phantom (e.g. those who survived the translation from a real object to a (none-object)) – that’s all!

  1. Rob says:

    Hi, how can I replicate this in a lab?

    I have an issue where I have a conflict user object which has an isDeleted = true but it does not appear in deleted objects, nor does the dn refer to the deleted items, it merely shows the conflict object with the original dn, but does not show up in dsa.msc or adsiedit. The only way I can see it is via get-adobject -includedeleteditems

    Any help appreciated!