Two new posts on ADAMsync over at AskDS

There are two new posts on ADAMsync over at AskDS.

The first is an ADAMsync 101, covering basic ADAMsync configuration; see also my AdamSync Common problems

The second (ADAMSync + (AD Recycle Bin OR searchFlags) = “FUN”) covers interaction between ADAMsync and the AD Recycle Bin functionality; I saw a related issue a long time ago with a customer who had chosen to preserve most every attribute on deletion as a way of trying to avoid doing database restores after accidental deletions. Another issue in this area was in very early versions where the ADAMsync did not have sufficient privilege to see deleted objects; this was fixed by introducing “obscured tombstone” logic that supports DirSync (which underlies ADAMsync) by just returning objectGUID and isDeleted for callers that would not usually have rights to see tombstones.

It’s great to see Microsoft still actively supporting ADAMsync.

Structure Rules! NAMING_VIOLATION and Error 0x2099 (The object cannot be added because the parent is not on the list of possible superiors)

In AD, structure rules determine which parent child relationships are possible amongst instances of classSchema objects and the structure rules are defined by the possSuperiors and systemPossSuperiors attributes of the classSchema objects. Let’s look at the default schema classSchema for an organizationalUnit (OU) in AD LDS:

We should find ourselves unable to create an organizationalUnit with an object that is not listed in systemPossSuperiors as its parent so e.g. we should not be able to create an organizationalUnit beneath a “container” object. Let’s try:

We would see the same if we tried using ldf, the ldf file (ou.ldf) to create the OU would be

dn: ou=test,cn=roles,o=msft
changetype: add
objectClass: organizationalUnit

It’s possible to modify structural rules by modifying possSuperiors for a classSchema object (it has to be possSuperiors rather than systemPossSuperiors as the latter is owned by the system and so can only be specified when the classSchema object is first created), so in our example to add the  container class as possible parent of an OU we could use an ldf (mod-posssuperiors.ldf):

dn: cn=Organizational-Unit,cn=Schema,cn=Configuration,dc=X
changetype: modify
add: possSuperiors
possSuperiors: container
–

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
–

The first modify operation is to add container to possSuperiors of Organizational-Unit.
The second modify operation uses a RootDSE modify operation schemaUpdateNow to tell the directory service to update the cached version of the schema so that the first modification can be used immediately.

If we now import this schema modification:

C:\Windows\system32>ldifde -i -f c:\Local\mod-posssuperiors.ldf -s localhost:389 -c “cn=Schema,cn=Configuration,dc=X” #schemaNamingContext

Connecting to “localhost:389”
Logging in as current user using SSPI
Importing directory from file “c:\Local\mod-posssuperiors.ldf”
Loading entries…
2 entries modified successfully.

and now re-run our attempt to create an OU beneath a container:

C:\Windows\system32>ldifde -i -f c:\local\ou.ldf -s localhost:389
Connecting to “localhost:389”
Logging in as current user using SSPI
Importing directory from file “c:\local\ou.ldf”
Loading entries..
1 entry modified successfully.

The same problem is sometimes seen with adamsync where the AD DS objectClass builtinDomain has only domainDNS as a possSuperior, if that objectClass is imported into the AD LDS schema (using ADSchemaAnalyzer) then if an AD LDS partition is created as, say, cn=mysync,o=msoft the attempt to adamsync from the AD DS will fail as it attempts to create a builtinDomain object with a Container as a superior. The fix is as above:

dn: cn=Builtin-Domain,cn=Schema,cn=Configuration,dc=X
changetype: modify
add: possSuperiors
possSuperiors: container
–

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
–

AdamSync Common problems

Here’s a list I have kept of the common problems in attempting to use Adamsync:

[1]Schema mismatch. (Use ADSchemaAnalyzer)

[2]Target partition in Adamsync configuration does not exist in target ADAM. Note: target partition must be an NC head.

[3]MS-AdamSyncMetadata.ldf is not imported

[4]Source AD is W2K and so Replicating Directory Changes permission is not granted for sync account on source AD NC head.

[5]ObjectClass foo is not in the ADAM schema when target-object-class in the ADAMsync configuration is set to foo. foo is usually userProxy.

[6]If target-object-class in ADAMsync is userProxy then objectSID must be in the include element of the ADAMsync configuration.

[7]Account used for ADAMsync /install must be able to write to target ADAM application NC head.

[8]If source-ad-account element is used in the ADAMSync configuration then will probably need /passPrompt on the ADAMSync /install command line.

[9]If object-filter element in ADAMSync configuration uses objectCategory then problems can arise, in particular deletions in source AD will likely not be sync’ed.

[10]object-filter element in ADAMSync configuration needs:

and = “&” use &

or = “|” use  & #124;

not = “!” use & #33;

[11]Choice of target-dn restricts the children that can be sync’ed from AD through possSuperiors e.g. if you make your target-dn ou=something and your base-dn is a domain NC head dc=contoso,dc=com then CN=builtin under the domain NC head will cause a sync failure as OU is not a possSuperior of builtinDomain

[12]Not using /log on the ADAMsync /sync when hitting problems.

[13] Infinite loops in synchronization with Windows 2003 Adamsync

[14] Problems with Adamsync aging runs e.g. random objects may be renamed and then moved into the ADAM Lost and Found container. Aging has many problems and is best avoided.

See also How to troubleshoot an OBJ_CLASS_VIOLATION error in Adamsync in Windows Server 2003 or in Windows Server 2008