It feels like only a couple of months ago, but actually only half a year ago, Microsoft released a version of Azure AD Connect that fixed a critical security vulnerability related to password resets. Yesterday, Microsoft released a new version of Azure AD Connect that does the same thing, but actually in a different feature.

The vulnerability was reported to Microsoft by Preempt, who also disclosed information on the vulnerability on their own blog. Their information details stealthy privileged accounts, the adminCount attribute and how the way Microsoft setup the sync account in Active Directory Domain Services (AD DS) when you use Express Settings in Azure AD Connect.

Microsoft responded in three complementing ways:

1. Microsoft issued a security advisory.
2. Microsoft released a script to set the right attributes for the sync account.
3. Microsoft released a new version of Azure AD Connect.

This way, organizations can secure their Hybrid Identity setup, and check if any damage has been done.

Escalation of Privilege vulnerability

The vulnerability in the way Azure AD Connect provisions a service account in Active Directory Domain Services (AD DS) finds its source in the fact that the adminCount property isn’t set on the account, and, subsequently, the account is not protected by the AdminSDHolder process. This specific process makes sure that sensitive accounts cannot be configured to have their password reset right delegated, among other sensitive operations.

Typically, the adminCount attribute is set to accounts that become a member of the Domain Administrators and Enterprise Administrators groups, but also to other well-known groups like Account Operators and Print Operators.

Is your Hybrid Identity setup vulnerable?

Of course, the first question you might ask yourself is if your Hybrid Identity setup is vulnerable or not. To answer this question, we first have to look at the two different ways Azure AD Connect can be installed.

Express Settings and Custom Settings

Many customers have opted to install Azure AD Connect with Express Settings. This four-click setup is an alternative to the more elaborate Custom Settings installation option. However, the Custom Settings installation option allows you to optionally reuse a (managed) service account. This option was added to Azure AD Connect version 1.1.443.0, back in March 2017.

In two scenarios, the vulnerability may exist in your organization’s Hybrid Identity setup:

1. You’ve setup Azure AD Connect using the Express Settings installation option.
2. You’ve setup Azure AD Connect using the Custom Settings installation option, but you have not opted to reuse a pre-created service account, managed service account (MSA) or group managed service account (gMSA).

How do I fix it?

In my experience, many setups are vulnerable. That’s OK, because there are two easy ways to fix it:

• Install Azure AD Connect new, using version 1.1.654.0, or up.
  This scenario is particularly useful for organizations that have not yet gone to production with their Hybrid Identity setup, are still using DirSync, still using Azure AD Sync or are using a deprecated version of Azure AD Connect. Additionally, organizations that may want to benefit from the use of a (g)MSA for Azure AD Connect should choose this scenario, when they want to get rid of the service account, based on a normal user object.
• Run the PowerShell script that Microsoft has made available.
  This scenario is useful for organizations that run Azure AD Connect, and are happy with their configuration and want nothing else to change, except for the vulnerability to disappear.

What does the PowerShell script do?

The PowerShell script tightens the settings on the service account to remove the vulnerability to the below values:

• Disable inheritance on the specified object
• Remove all ACEs on the specific object, except ACEs specific to SELF. We want to keep the default permissions intact when it comes to SELF.
• Assign specific permissions.

How do I run the script?

Since the script is on the Microsoft PowerShell Gallery, it can be easily run, by using the following two lines of PowerShell:

New-Item "C:\Program Files\WindowsPowerShell\Modules\ADSyncConfig" -Type Directory

Copy-Item “C:\Users\administrator\downloads\adsyncconfig.psm1" -Destination "C:\Program Files\WindowsPowerShell\Modules\ADSyncConfig\ADSyncConfig.psm1" -Force

New-ModuleManifest -Path  "C:\Program Files\WindowsPowerShell\Modules\ADSyncConfig\ADSyncConfig.psd1" -RootModule ADSyncConfig.psm1

Import-module ADSyncConfig

Set-ADSyncRestrictedPermissions -ObjectDN "CN=AAD_eabcdefg123,CN=Users,DC=dirteam,DC=com" -Credential $credential

Assuming you’d download the PowerShell Module and storing the download in the Downloads folder, you’d change the grey fields, to make $ObjectDN (the Active Directory account whose permissions need to be tightened) and $Credential (the credential used to authenticate the client when talking to Active Directory. This is generally the Enterprise Admin credentials used to create the account whose permissions needs tightening) appropriate for your environment.

How do I check if the vulnerability has been misused?

Since the escalation of privilege vulnerability lies in the ability for an attacker to reset the password of the Azure AD Connect service account, checking if the vulnerability has been misused, is easy as checking the pwdLastSet attribute of the account.

Additionally, the Active Directory event log contains information for the password reset event in case you find an unexpected timestamp.

Call to Action

If you haven’t configured your Azure AD Connect installation(s) with group Managed Service Accounts (gMSAs), yet, this is a good time to install Azure AD Connect as a Staging Mode server, and then, after due diligence, making it the actively synchronizing Azure AD Connect server.

Managed Service Accounts (MSAs) and group Managed Service Accounts  (gMSAs) are the way forward for service accounts in Microsoft-based environments.