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:

Sunday, 29 November 2009

Change Notification For Intersite Replication

You can override the default replication interval for intersite links.
To do it, go into adsiedit with an Enterprise Admin account.
Navigate to the siteLink object you want to set change notification for, and edit the options attribute.
The first bit needs to be 1. Generally, the attribute will not be set so just set it to 1. Otherwise you'll need to do a bitwise OR calculation on it to add the 1.
Once this is done, allow the configuration partition change to replicate to all affected DCs in those sites. After it has done, all further changes made to the AD on DCs in those sites will replicate between the 2 sites faster using change notification.

Tuesday, 27 October 2009

AD snapshots and Directory Service Comparison Tool

AD snapshots. They sound nice don't they?
And they sort of are.

The details on how to set them up are here:

The main issue I have is that there are no good ways to export the data into the AD. You can develop a script, use csvde, ldifde, but not really easy in times of crisis.

You should be aware that all snapshot data is read only and is, by default, only accessible to domain and enterprise admins.

The Directory Service Comparison Tool does provide a nice interface to doing some of these things. The only issue I had with it is that after loading the snapshot and the AD, it didn't show any changes that had occurred in the live AD since the snapshot.
Now, this may be me, but I haven't seen anything on t'internet that tells me otherwise.

It will pick up any changes that you make to the AD while the mounted snapshot is active.
You can then reanimate and restore attributes.

However, if it can't tell me the initial differences between a snapshot and the AD, it ain't no good to me as it would have to be running all of the time otherwise.

Preventing OU Deletion

When you create an OU in W2K8 console, there is an option to prevent it from accidental deletion.
If you choose this, it just adds an ACE for Everyone, which denies "Delete" and "Delete Subtree" on the OU.

Owner Rights Restrictions

W2K8 adds a new well-known security descriptor - Owner Rights (S-1-3-4).
This overrides the traditional owner rights that are granted to CREATOR OWNER on a file (such as being able to change the DACL).

This is useful in an AD delegation model where you want a group to be able to create but not delete objects. Under the old model, they'd be able to delete those that they created. This new SID allows you to prevent that behaviour.

Owner rights will only work when all DCs are running W2K8. Otherwise the Owner Rights ACE is ignored by down-level DCs.

See this link for a good description of how to use Owner Rights:

Monday, 26 October 2009

Restartable AD

AD in W2K8 is restartable as a service.

This can allow an offline defrag (though whether this is of much use is debatable). However, it does allow the ntds.dit file to be compacted so you will likely see a decrease in the size of the file.

AD does do a regular (12 hours) online defrag as part of ongoing garbage collection process. This optimises data storage and disposes of tombstone objects, but won't decrease the size of the database.
Therefore the offline defrag can help to shrink the database and allow it to more easily be held in memory space and gain the performance gains that that entails.
See link for instructions.