I have a case in my table where AAD Connect has been implemented with express settings (four clicks to the cloud) and is using default accounts created by installation wizard. 

There isn’t nothing wrong with this agile deployment method from productivity point of view, but when we look at it from security point of view you might want to re-consider is this a safest way to deploy Azure AD Connect.

The case

My customer wants to tighten up security (mainly because of ADDS delegations) and follow best practices found from here, Security Advisory 4056318

Currently default accounts are used in the environment and when we are talking AD DS Connector Account, it’s the one circled in picture below

Before change account created by installation wizard (MSOL_e0182xx) is used as AD DS Connector account and it has following permissions delegated from the domain root level.

Because I’m changing the AD DS Connect Account and using mS-DS-ConsistencyGuid as source anchor attribute I also need to grant permissions for new service account to necessary organizational units. It can be done with different methods but nowadays AAD Connect PowerShell module has new cmdlets included which are used in this scenario.

New AAD Connect account is svc_aadconnect, permissions are granted through AD group based on delegation model with following commands:

As a pre-req: Import-Module “C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\AdSyncConfig.psm1”

Examples below are from my demo environment where I delegated permissions only to needed organizational units to attributes which are needed in this specific environment. Those are:

  • Write-back to mS-DS-ConsistencyGuid
  • Write-back for a password reset (SSPR)
  • Password Hash sync

Set Read Permissions if inheritance is blocked to OU’s where synced objects are

  • Set-ADSyncBasicReadPermissions -ADConnectorAccountDN “CN=AD_AADC_Permissions,OU=ADManagement,DC=monaegroup,DC=com” -ADobjectDN “OU=OrgTEst,DC=monaegroup,DC=com”
  • Set-ADSyncBasicReadPermissions -ADConnectorAccountDN “CN=AD_AADC_Permissions,OU=ADManagement,DC=monaegroup,DC=com” -ADobjectDN “OU=OrgUsers,DC=monaegroup,DC=com”

Set mS-DS-ConsitencyGuid Permissions to needed OU’s

  • Set-ADSyncMsDsConsistencyGuidPermissions -ADConnectorAccountDN “CN=AD_AADC_Permissions,OU=ADManagement,DC=monaegroup,DC=com” -ADobjectDN “OU=OrgTEst,DC=monaegroup,DC=com”
  • Set-ADSyncMsDsConsistencyGuidPermissions -ADConnectorAccountDN “CN=AD_AADC_Permissions,OU=ADManagement,DC=monaegroup,DC=com” -ADobjectDN “OU=OrgUsers,DC=monaegroup,DC=com”
Adding permissions to mS-DS-ConsistencyGuid

Set Password Hash Sync Permissions to domain root

  • Set-ADSyncPasswordHashSyncPermissions -ADConnectorAccountName “svc_aadconnect” -ADConnectorAccountDomain monaegroup.com
Adding permissions to domain root
Verified permissions from domain root

Set Password Write-back permissions

  • Set-ADSyncPasswordWritebackPermissions -ADConnectorAccountDN “CN=AD_AADC_Permissions,OU=ADManagement,DC=monaegroup,DC=com” -ADobjectDN “OU=OrgTEst,DC=monaegroup,DC=com”
  • Set-ADSyncPasswordWritebackPermissions -ADConnectorAccountDN “CN=AD_AADC_Permissions,OU=ADManagement,DC=monaegroup,DC=com” -ADobjectDN “OU=OrgUsers,DC=monaegroup,DC=com”
After configuring permissions verified with ADACLScanner that everything is in place

Change AD DS Connector Account

AD DS Connector account can be changed from MIIS client. 

  • Select “Connectors” from top left corner
  • ADDS connector – monaegroup.com
  • Properties from right side of the console

When configuration screen open select “Connect to Active Directory Forest” and to username & password fields fill the new account details.

Close the MIIS client just in case and open it again that all necessary information is updated (needed to do in my case). 

That’s it, account has been changed and it’s time to verify does it work.

Create new account and run delta synchronization profiles two (2) times to get mS-DS-ConsistencyGuid written from cloud back to created user object.

Start-ADSyncsynccycle -PolicyType Delta

Runing delta profiles
Noticed coming mS-DS-ConsitencyGUID value
It was written successfully to user object attribute
Change was made my new connector account svc_aadconnect

Voila! Everything works as expected and new connector account is able to make changes to on-premises Active Directory. What I’m not aware is that is this solution supported by Microsoft so when changing the account test it carefully.

Update 06/12/2018

Finally got response from Microsoft that this method is fully supported, so we are good to go!

Hardening Service Account

An improvement has been added to Azure AD Connect version running¬†1.1.654.0 (and after) so if you have made a fresh installation of AAD Connect with version above you are “safe”. If you have made upgrade from previous versions hardening is needed. In my case hardening is needed to hardening my service account with Set-ADSyncRestrictedPermissions cmdlet.¬†

Note: documentation says that you need to use “objectDN” switch but there isn’t such a switch so use “ADConnectorAccount” instead

Set-ADSyncRestrictedPermissions “svc_aadconnect,OU=ADManagement,DC=monaegroup,DC=com”

or

Set-ADSyncRestrictedPermissions -ADConnectorAccountDN “svc_aadconnect,OU=ADManagement,DC=monaegroup,DC=com”

Or by tool found from Technet

$credential = Get-Credential 
Set-ADSyncRestrictedPermissions “CN=svc_aadconnect,OU=ADManagement,DC=monaegroup,DC=com” -Credential $credential

Hope this helps if you are planning to change ADDS Connector Account in you AAD Connect installation. Until next time!