0

AdamSync is crashing periodically. In troubleshooting we found that it's throwing an exception when it encounters what it thinks is an empty DN. I replayed the query using the dirsync cookie stored in the ADLDS configuration. Dumping the returned values I find the following object:

CN=SCCM Site Server\0ADEL:0b9efaf1-24cc-46a1-92ff-f6aa74254d3e,CN=Deleted Objects,DC=appd,DC=appstate,DC=edu
description 
objectguid 0b9efaf1-24cc-46a1-92ff-f6aa74254d3e
instancetype 4
isrecycled TRUE

As far as we can tell, that object no longer exists. We can't find it using any of our tools: User & Computers, LDP, ADSI Edit, AD Admin Center, AD Explorer, PowerShell queries (all using the deleted/recycled filters, extensions, and flags). We have considered that it may have hit its tombstone and been processed by the garbage collector since the date specified in the dirsync query. If that's the case, would the attribute change record continue to be returned? Indefinitely? If it hasn't been processed by the garbage collector why can't we find it?

AdamSync crashing due to the value seems to be a secondary effect or a different problem altogether.

Justin Cervero
  • 246
  • 1
  • 6
  • 1
    Run the Lingering Objects Liquidator to see if this is a lingering object - https://blogs.technet.microsoft.com/askds/2017/10/09/introducing-lingering-object-liquidator-v2/ – joeqwerty May 16 '19 at 02:16
  • @joeqwerty Thanks for the suggestion. I ran it against the entire forest and all my DCs but no luck. It found a handful of objects that are due to be GC'd soon but didn't find the specific object we're hunting. – Justin Cervero May 16 '19 at 12:54

1 Answers1

1

If you run a DirSync LDAP query without specifying any attributes to return it returns any objects that have changed. IF you have the Active Directory Recycle Bin enabled, when an object transitions to a recycled state (as indicated by the attributes listed in the original question), the state change will result in DirSync sending an entry with an object for which isRecycled = True.

After working with an MS Premier engineer we found that AdamSync does a second request for the object after the DirSync results are returned. If the account used to run the AdamSync executable is configured with only the 'Replicating Directory Changes' permission AdamSync is unable to read the returned object due to not having permission to read recycled objects. This results in the DN of the second look up being NULL which crashes AdamSync with an unhandled exception.

Two solutions exist: disable the AD Recycling Bin or modify the AdamSync LDAP query to exclude objects for which isRecycled = TRUE:

(&(<ldap_filter>)(!(IsRecycled=TRUE))

Note that 'TRUE' must be capitalized.

MS Premier indicates that AdamSync is in an 'as-is' state and the unhandled exception is unlikely to be patched.

Justin Cervero
  • 246
  • 1
  • 6