Azure AD Connect Hybrid Writeback and Permissions

In the world of hybrid headaches, directory synchronization is the root of all evil. While there's nothing wrong with using directory synchronization (I'm a big fan), most of the issues and questions I encounter when dealing with hybrid issues are a direct result of not understanding directory synchronization and how the process works.

Let’s start with documentation on the subject. To spare you from reading the entire page, here's the one-sentence summary: “in order to build out a hybrid Exchange configuration, you must have synchronization enabled with the ‘hybrid writeback’ feature enabled.”

The latter ensures that a handful of attributes (eight, to be exact), are written back from Azure Active Directory into the on-premises organization. The number of attributes that are written back has been static, but some time ago themmsDS-ExternalDirectoryObjectIDmattribute was added to the list. As the documentation states, the AD schema is extended with the attribute when you introduce Exchange 2016.

While Exchange 2016 does extend the schema, and makes the attribute known in the on-premises organization, the same is true when you introduce AD based on Windows Server 2016. You don't even have to have a domain controller running Windows Server 2016 – extending the schema to the 2016 version is enough for the attribute to show up. No surprises there though.

If you install Azure AD Connect, it takes care of the necessary permissions required to write to the attribute. It configures the required permissions at the root of the domain(s) in the forest that it is installed in. Azure AD Connect assumes those permissions will propagate through AD based on normal AD inheritance. (The fact that inheritance could be missing is a point we'll discuss later.)

A lot of organizations have an Active Directory with quite a bit of history. Chances are those permissions are not inherited. Over the years, I've seen some interesting directory structures with all sorts of permission layers. It's common in larger environments to see permissions in AD maintained by a different team, and you might not have the rights to add/modify permissions in AD. In these cases, permissions for the synchronization engine are often added manually using a PowerShell script (and dsacls.exe.)

Here is a good such a Powershell script as to configuring sync and writeback permissions in Azure AD. While the script Brian shares contains the permissions for all possible objects, the team executing it might wrongfully assume that they don’t need to add  the permissions for the msDS-ExternalDirectoryObjectId attribute based on the documentation previously referenced above.

However, as soon as the attribute is in your local AD (even if you are not running Exchange 2016), and you enable hybrid write-back, you must assign proper permissions for the attribute. If not, the synchronization engine will complain about it. It won’t impact the user or the hybrid deployment (because the attribute isn’t used), but it's not very clean to keep those errors in the synchronization log.

 There's nothing wrong with disabling inheritance. In some situations, breaking inheritance might be the only option. Whoever is managing AD permissions might not realize that some objects can’t be written back to until the synchronization engine has performed its initial synchronization. The solution is as simple as it is difficult — (manually) add the required permissions. 

There are various ways to manually add the required permissions:

• Re-enable inheritance. The quickest way to solve the problem, but it might overwrite permissions already in place, add permissions that shouldn't be there, or create a noncompliant situation.
• Manually apply the permissions. This can work great if the inheritance is blocked at OU-level, but all underlying OUs have inheritance enabled. In that case, you only must reapply the permissions at the OU where the inheritance was broken. If inheritance is blocked at various levels, you might need to reapply the same set of permissions on various locations throughout your directory.

You might find that inheritance is blocked for certain users but not for others. This often points to an inheritance that was blocked at the user level. If you don't know why the inheritance is blocked for a user, it could have been lifted as part of a process in AD related to protect specific admin accounts, also referred to as AdminSDHolder protection. The solution is the same, but it might shed some light on what's going on in your directory.

Solving a synchronization problem is often a quick fix. To avoid running into these hiccups, running a report on the permissions beforehand can catch issues before installing and configuring Azure AD Connect. One effective way to keep track of this is to use the reports built into Mailscape 365 to check permissions before deploying directory synchronization. You can use Mailscape 365’s monitoring capabilities to get early warning of DirSync problems or concerns such as event log messages indicating that attribute permissions are broken. Learn more about Mailscape 365.

Active Directory Monitoring and Reporting

Active Directory is the foundation of your network, and the structure that controls access to the most critical resources in your organization. The ENow Active Directory Monitoring and Reporting tool uncovers cracks in your Active Directory that can cause a security breach or poor end-user experience and enables you to quickly identify and remove users that have inappropriate access to privileged groups (Schema Admins, Domain Administrators). While ENow is not an auditing software, our reports reduce the amount of work required to cover HIPAA, SOX, and other compliance audits.

Access your FREE 14-day trial to accelerate your security awareness and simplify your compliance audits. Includes entire library of reports.