Wednesday, 2 December 2009

Synchronisation of the Directory

There are 2 primary methods for synchronising with the AD.

The first is DirSync. The usual way of doing this is to have it operate in "per partition" mode.
This requires that the permission Replicating Directory Changes is granted to the user account under which the DirSync control is running.
This permission has to be granted on the top level of the partition.
It then uses a cookie to first sync with the partition and then to subsequently poll the directory, after which the cookie will contain only the directory changes.
Since this permission is at the top level it will contain all changes in the directory and an ldap query will then filter it for just the objects and attributes required.

The Replicating Directory Changes permission basically appears to grant the right to read and copy the data from AD.

This does give some concern over how confidential data is read (using the confidential bit for example). The data will still be detected as changed. However I'm unsure if the data can then be read by the program, so you may end up with a change recorded but no record of what the change actually was. This also really applies to all objects - does the DirSync account also need read permissions on any attributes that it wants to sync the changes for?
By default it will also record deletions as tombstoned objects, but again, may have to grant permissions on the Deleted Objects container.

There is also a "per object" mode which allows you to not record all changes and does not require the Replicating Directory Changes permission. However, details here are sketchy.

The second method is to monitor the uSNChanged attribute.
Since every time a change is made on a DC, it updates its highestCommittedUSN (check this attribute out on RootDSE).The uSNChanged attribute of the object that was changed is then set to the same as the highestCommittedUSN value.
uSNChanged is not replicated.

Therefore, by doing a complete AD sync and then for subsequent reads only reading the uSNChanged attribute where it is greater than the previous high, you get a list of objects that have changed.
Deletions are captured either by reading the Deleted Objects container or by periodically doing a full AD sync.

A single DC will need to be read otherwise the uSNChanged attribute becomes meaningless. If the DC does change a full sync will be required.

Objects should be tracked using the objectGUID since this is the only attribute guaranteed not to change.

Some useful links:

No comments:

Post a Comment