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”
Set Password Hash Sync Permissions to domain root
- Set-ADSyncPasswordHashSyncPermissions -ADConnectorAccountName “svc_aadconnect” -ADConnectorAccountDomain monaegroup.com
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”
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
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”
$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!
Sam's Corner 
Hi, Please point me to the Microsoft URL saying that “changing AD DS connector Account” is fully supported . Thanks in Advance!
Hi,
There isn’t any URL or website that would have such information that I’m aware or. I received a response from Microsoft Support during my case. If you need to change the account take permissions into account. The ADDS connector account is used for read/write operations against on-prem AD. Here are some links for the start:
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-accounts-permissions
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-configure-ad-ds-connector-account
Is it possible to change the ADDS connector account to a gMSA account?
To best of my knowledge, it is not. gMSA can be used as ‘ADSync’ service account
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-accounts-permissions#accounts-used-for-azure-ad-connect
When you write AD AADC Permissions you mean svc aadconnect? Why are you giving two different accounts if you are changing to svc_aadconnect?
That’s right. In this blog, the permissions were defined (as an example) to a group and in one example to a svc_aadconnect account directly. I always prefer to use groups instead of users when granting permission to AD.