Microsoft has issued a security advisory to Office 365 customers via the Message Center. The advisory lets customers know about a recently disclosed issue with the security restrictions on the service account in Active Directory that Azure AD Connect creates and uses.
We’ve detected a problem with Azure AD Connect and previous versions of Sync products due to insufficient restrictions on the service account that these products use when automatically creating the service account during installation.
How does this affect me?
If you don’t fix this problem, your Active Directory environment could be compromised by an unauthorized elevation of privilege attack.What action do I need to take?
To fix this problem you need to restrict the access right on the service account to prevent this attack.
When you install Azure AD Connect and allow it to create its own service account (which occurs when you install using Express Settings), the account is not adequately protected from low privilege administrators performing a password reset on the account. A low privilege administrator (such as a help desk operator) could reset the password on the service account, and then use the permissions of that account to gain full domain admin privileges in Active Directory. Microsoft credits a company named Preempt with the disclosure of this security risk, and they have a write up and demonstration video available here.
This is certainly a problem that deserves your attention. Internal attacks are not uncommon, whether it be a disgruntled help desk or systems administrator, or an outside attacker who has compromised a low privilege admin account. Privilege escalation risks should always be taken seriously.
Microsoft has published a fix, which I’ll discuss shortly, but I think it’s also worth looking at the mitigations for this risk.
Microsoft calls out three best practices that would mitigate this risk.
- The use of Account Operators group should be avoided, since members of the group by default have Reset-Password permissions to objects under the User container.
- Move the AD DS account used by Azure AD Connect and other privileged accounts into an OU (Organization Unit) that is only accessible by trusted or highly-privileged administrators.
- When delegating Reset-Password permission to specific users, scope their access to only user objects for which they are supposed to manage. For example, you want to let your helpdesk administrator manage password reset for users in a branch office. Consider grouping the users in the branch office under a specific OU and grant the help desk administrator with Reset-Password permission to that OU instead of the User container.
If you already align with those best practices, then you are in better shape than most customers I’ve dealt with over the years. But you should still look at deploying the fix from Microsoft.
For new Azure AD Connect deployments, AAD Connect builds 1.1.654.0 and later will include this fix, and you can safely install with Express Settings.
For existing deployments, AAD Connect will not automatically apply the fix during an upgrade newer builds, and you’ll need to complete the following steps. These are slightly modified from MVP Jeff Guillet’s explanation on his blog here, because I had multiple sync service accounts due to reinstalling AAD Connect in the past (which is a mess I should clean up!), and also needed to install the Active Directory PowerShell module on my AAD Connect server.
First, download the AdSyncConfig PowerShell module from the TechNet Script Gallery.
The current build of the module is not digitally signed, so you will need to set your PowerShell execution policy to allow the unsigned code to run.
PS C:\Admin> Get-ExecutionPolicy RemoteSigned PS C:\Admin> Set-ExecutionPolicy -ExecutionPolicy Unrestricted
If you don’t already have the Active Directory PowerShell module installed, run the following command in PowerShell to install it.
PS C:\Admin> Install-WindowsFeature RSAT-AD-PowerShell
Still in PowerShell, navigate to the folder where you downloaded the AdSyncConfig PowerShell module and import it.
PS C:\Admin> import-module .\AdSyncConfig.psm1
Save a credential object for re-use. This credential must be a user account that has Domain Admin and Enterprise Admin rights, according to Microsoft’s somewhat vague notes.
PS C:\Admin> $credential = Get-Credential
Retrieve the Msol* service accounts in your Active Directory and store them in a variable.
PS C:\Admin> $Accounts = @(Get-ADUser -Filter 'Name -like "msol_*"')
Apply the restrictions to each Msol* account.
PS C:\Admin> $accounts | % {Set-ADSyncRestrictedPermissions -ObjectDN $_.distinguishedname -Credential $credential}
If you have any concerns about possible compromise of your AAD Connect sync service account, Microsoft recommends that you check the last password reset date for the account(s).
PS C:\Admin> Get-ADUser -Filter 'Name -like "msol_*"' -Properties:PasswordLastSet | Select Name,Password* Name PasswordLastSet ---- --------------- MSOL_68fa8f6671b9 8/19/2017 9:23:45 PM MSOL_94e4597ee7d6 2/2/2016 2:32:41 AM MSOL_f4cb7275345d 9/25/2014 11:42:18 AM
You can also check your domain controller event logs for password reset events for those accounts.
Follow up – fairly new to PS – do I have to set back the execution policy at the end or is it set by automatically when PS is closed? i.e. the below was issued near the top of the process:
Set-ExecutionPolicy -ExecutionPolicy Unrestricted
HI!
I just can’t get further with this after running the last “line”. I have used an domain admin account with (domain\username).. bu still got this messages. I’m not so into powershell, but i guess i’m doing some elementary wrong here.. Thnx if somebody can help!
————————————
Test-Credential : Validating credential parameter failed. Exception Details: Validating credential parameter failed.
Admin account System.Management.Automation.PSCredential.UserName could not be found.
At C:\temp\AdSyncConfig.psm1:71 char:4
+ Test-Credential $Credential
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Test-Credential
Validating credential parameter failed. Admin account System.Management.Automation.PSCredential.UserName could not be
found.
At C:\temp\AdSyncConfig.psm1:173 char:4
+ throw [System.ArgumentException] “Validating credential parameter failed. Adm …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (:) [], ArgumentException
+ FullyQualifiedErrorId : Validating credential parameter failed. Admin account System.Management.Automation.PSCre
dential.UserName could not be found.
The Real Person!
The Real Person!
“UserName could not be found.”
That seems pretty straight forward to me. I can’t see your environment obviously, but it’s probably something simple like a typo.
Thank you Paul for the post.
I was able go step by step and at the last step I get this Error message
Set-ADsyncRestrictedPermissions : Setting Restricted permissions on CN=MSOL_xxxxxxxxxxx,CN=Users,DC=contoso,DC=local
failed. Exception Details: You cannot call a method on a null-valued expression.
At line:1 char:16
+ $Accounts | % {Set-ADsyncRestrictedPermissions -ObjectDN $_.distinguishedname -c …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Set-ADSyncRestrictedPermissions
I have total of two MSOL accounts and get this message for both.
Please let me know what could be a problem.
Thank you
The Real Person!
The Real Person!
Try just running the command manually for each account’s distinguished name.
Thank you very much for the reply, actually Dorinel Siteavu was correct, when I was storing credentials I set it as domain\username and it worked.
thanks again
Hello
When you type the credentials remember that you need to use this format : domain\AdministratorUser.
I was getting the same error and it was I was putting administrator@domain.local.
In other topic many thanks Paul for the post.
Best Regards
Thank you Dorinel, I changed the credentials to domain\username and it fixed the problem.
Pingback: Security Risk in Azure AD Connect Account | Sam's Corner
Fantastic write up! Thank you.
I ran the powershell commands and applied the restricted permissions to the found MSOL account. I then ran the tool again it still states the account is a stealthy admin.
The Real Person!
The Real Person!
Ran what tool?
Sorry about that. Your article contains a link to the preempt website. On their website they have an free “preempt inspector tool” that searches for stealthy admin accounts. Their tool identified the MSOL account as a stealthy admin account. I then ran your power shell commands against the MSOL account and it stated the commands were successful.
I was expecting that when I reran the preempt inspector tool again it would no longer classify the MSOL account as a stealthy admin since the account restrictions were successfully applied.
Maybe I am thinking about this wrong.
The Real Person!
The Real Person!
I think their tool will always consider it a “stealthy admin” because of the way that account has its permissions delegated.
Vinod try looking in computer management in local users and groups on your server.
I am unable to find any account which starts from MSOL. we upgraded from Azure AD sync to Azure AD Connect and we are still in version 1.1.130.0 Please let me know if i need to upgrade to 1.1.654.0
The Real Person!
The Real Person!
Yes, you should keep Azure AD Connect updated.
If you don’t have an Msol* account you might not have installed using the Express Settings, and you may have manually nominated a service account.