Share via

Windows Azure Active Directory Synchronization tool (dirsync) Impact on AD Permissions

  • Article

We have seen in some customer environments that systems monitoring facilities have flagged the changes executed by the Windows Azure Active Directory Synchronization tool (dirsync) in the configuration phase as security events. Knowing in advance the technical details about what dirsync does can help prevent surprises at execution time.

When executing the Configuration Wizard of dirsync, the following detailed operations happen:

  • A service account is created (named MSOL_xxxxxxxxxxxx, where each ‘x’ represents a hexadecimal character) in the standard Users container in the root domain of the forest.
  • The account is enabled, with the “Password Never Expires” option set.
  • The “Replicating Directory Changes” and “Replicating Directory Changes All” extended permissions are added for the service account created above on each domain container in the forest. These permissions are required for dirsync to be able to read the changes on AD objects, in order to execute delta synchronizations to Office 365. These permissions are set at domain level and inherited by all objects in each domain, except accounts belonging to protected groups. If inheritance has been broken at any level, the dirsync service account may not be able to read changes from some parts of the directory, and will give Access Denied errors in the logs at synchronization time. If this is the case, manual fixing will be needed, usually re-enabling inheritance while maintaining existing permissions on each container where inheritance was broken.
  • In order to apply the required permissions to accounts belonging to protected groups, the “Replicating Directory Changes” and “Replicating Directory Changes All” permissions are also added for the service account created above on the AdminSDHolder object in the System container of the root domain. From there, the Security Descriptor propagator (sdprop) will apply the permissions above to accounts belonging to protected groups. The article at http://technet.microsoft.com/en-us/magazine/2009.09.sdadminholder.aspx explains the details around this process.