HOWTO: Properly delegate Directory permissions to Azure AD Connect service accounts

Hybrid Identity

Most Microsoft-based Hybrid Identity implementations use Active Directory Federation Services (AD FS) Servers, Web Application Proxies and Azure AD Connect installations. In this series, labeled Hardening Hybrid Identity, we’re looking at hardening these implementations, using recommended practices.

In this part of the series, we’ll look at properly delegating directory access to Azure AD Connect service accounts.

 

Why look at Directory Access for Azure AD Connect Service Accounts

Azure AD Connect uses three service accounts:

  1. A local account on the Windows Server installation running Azure AD Connect, used to run the he Microsoft Azure AD Sync service. This account can be configured as a group Managed Service Account (gMSA)
  2. An account in the Azure Active Directory tenant
  3. One account per Active Directory Domain Services environment in scope for Azure AD Connect.

Azure AD Connect offers a choice when creating this third account in the AD forest account dialog screen. You can specify your own service account, or let Azure AD Connect create the service account. The latter option is the default option.

The default Azure AD Connect service account

When you let Azure AD Connect create the account, an account is created that follows the naming convention, resulting in a name starting with MSOL_, followed by the first 8 bytes of the Azure AD Connect installation ID (a version 4 UUID) and the server name. It is placed in the Users container per Active Directory domain in scope.

This account then is delegated the following Directory Services permissions at the root level of the Active Directory domains in scope:

  • Replicate changes
  • Replicate changes all
  • User objects: reset password, change password and read/write all properties
  • InetOrgPerson objects: read/write all properties
  • Groups: read/write all properties
  • Computer objects: read/write all properties

Note:
When you have Device Writeback configured, the service account is also delegated extensive permissions to the RegisteredDevices container. These delegations are created when you configure Device Options in the Azure Active Directory Connect Configuration wizard.

The issue

These permissions are too lenient, when:

  • Organizations use Domain and OU Filtering
    These organizations do not synchronize all Organizational Units and containers of their Active Directory domain(s) to Azure AD with Azure AD Connect, and/or
  • Organizations use Azure AD App Filtering
    These organizations do not synchronize all attributes for the objects in scope of their Active Directory domain(s) to Azure AD with Azure AD Connect
  • Organizations wish to apply least privileges to Azure AD Connect service accounts

In these cases, the permissions mentioned above should be restricted.
Further more, per Microsoft’s own recommended practice, delegation of Directory Services permissions should be per group, not per individual user object.

Possible negative impact (What could go wrong?)

I feel delegated Directory Services permissions should be ‘just right’.

If you have too strict permissions, functionality might break. For instance, Device Writeback may not work.

If you have permissions outside the scope of Azure AD Connect, you might experience a large fall-out when the service account in breached. For instance, the permissions might be used to add people to over 1015 groups in a Denial of Service attack or eventually be used to change the password of admin accounts (although not directly).

If you have delegated Directory Services permissions to a user account, these permissions get orphaned when the user object is deleted. This will result in several unusable permissions referring to the sID of the user object; garbage weighing Active Directory down. This is why we prefer to use groups.

 

Getting Ready

To properly delegate Directory access to Azure AD Connect service accounts, make sure to meet the following requirements:

 

System requirements

Make sure you have a clear inventory of the Active Directory OU structure, what OUs and containers are in scope for Azure AD Connect and what type of objects reside per OU and container.

Important!
If you intend to move objects around in another project, postpone or abandon properly delegating Directory Services permissions at a granular level.

You can use the following lines of Windows PowerShell on a Windows Server with an Azure AD Connect installation to achieve this goal:

$c = Get-ADSyncConnector -Name domain.tld
($c).Partitions.ConnectorPartitionScope.ContainerInclusionList | Out-GridView

 

Important!
The below commands make the assumption that you explicitly enable Organizational Units and containers on the Domain and OU Filtering screen in the Azure Active Directory Configuration wizard. If you enable an OU and then disable a child OU of this OU, remove the /I:S part of the command on the parent OU.

 

Privilege requirements

Make sure to sign in with an account that has privileges to make changes on the Security tab of OUs and containers. For an Active Directory environment with a single domain, an account that is a member of the Domain Admins group will suffice. For multi-domain Active Directory forests, a member of the Enterprise Admins group is required.

 

How to do it

Follow these steps to properly and granularly delegate Directory Services permissions for Azure AD Connect service accounts:

 

Create groups

First off, we create the Active Directory groups to delegate Directory Services permissions to:

  1. A group for the base Active Directory permissions
  2. A separate group for Password Reset permissions
  3. A separate group for Password Writeback
  4. A separate group for Group Writeback
  5. A separate group for Device Writeback
  6. A separate group for Hybrid Exchange

Provide these groups with apt names, following the naming convention within your organization. Place them wherever you like in your Active Directory environment, but preferably outside of the Azure AD Connect synchronization scope.

 

Delegate base permissions

Use the following line on a Command Prompt (cmd.exe) to properly provision the group for the base Active Directory permissions:

dsacls.exe “dc=domain,dc=tld” /G “DOMAIN\GroupBasePermissions:CA;Replicating Directory Changes;” DOMAIN\GroupBasePermissions:CA;Replicating Directory Changes All;” 

 

Delegate Write-back of the ms-DS-ConsistencyGUID source anchor

Recent versions of Azure AD Connect use the mS-DS-ConsistencyGUID attribute as the source anchor for user objects. As this is the new standard, my recommendation is to add the delegated permissions to the base permissions group.

Use the following line on a Command Prompt (cmd.exe) to allow members of the base permissions group to writeback the source anchor attribute.

Tip!
Use this line on each OU in scope for Azure AD Connect with user objects in scope for Azure AD Connect.

dsacls.exe “OU=OrganizationalUnit,dc=domain,dc=tld” /I:S /G “DOMAIN\GroupBasePermissions:WP;mS-DS-ConsistencyGUID;user”

 

Delegate password reset permissions

Use the following line on a Command Prompt (cmd.exe) to properly provision the separate group for Password Reset permissions:

Tip!
Use this line on each OU in scope for Azure AD Connect with user objects that will be configured with Azure AD Self-service Password Reset.

dsacls.exe “OU=OrganizationalUnit,dc=domain,dc=tld” /I:S /G “DOMAIN\GroupNamePasswordReset:CA;Reset Password;user” DOMAIN\GroupNamePasswordReset:CA;Change Password;user”

 

Delegate password Writeback permissions

Use the following line on a Command Prompt (cmd.exe) to properly provision the separate group for Password Writeback permissions:

Tip!
Use this line on each OU in scope for Azure AD Connect with user objects that will be configured with Password Writeback.

dsacls.exe “OU=OrganizationalUnit,dc=domain,dc=tld” /I:S /G “DOMAIN\GroupNamePasswordWriteBack:CA;Reset Password;user” DOMAIN\GroupNamePasswordWriteBack:CA;Change Password;user” DOMAIN\GroupNamePasswordWriteBack:WP;lockoutTime;user” DOMAIN\GroupNamePasswordWriteBack:WP;pwdLastSet;user”

 

Delegate Device Writeback permissions

Use the following line on a Command Prompt (cmd.exe) to properly provision the separate group for Device Write-back on the RegisteredDevices container:

dsacls.exe “CN=RegisteredDevices,CN=System,DC=domain,DC=tld” /I:S /G “DOMAIN\GroupNameDeviceWriteBack:CCDCRPWP;;computer”     

 

Delegate group writeback permissions

Use the following line on a Command Prompt (cmd.exe) to properly provision the separate group for Group Write-back:

Tip!
Use this line only on the OU you’ve specified for Group write-back when you’ve configured Azure AD Connect.

dsacls.exe “OU=WrittenBackGroups,DC=domain,DC=tld” /I:S /G “DOMAIN\GroupNameGroupWriteBack:WP;members;group”

 

Delegate Exchange Hybrid permissions

Use the following line on a Command Prompt (cmd.exe) to properly provision the separate group for Hybrid Exchange permissions to write back attributes to user objects:

Tip!
Use this line on each OU in scope for Azure AD Connect with user objects in scope for Azure AD Connect.

dsacls.exe “OU=OrganizationalUnit,dc=domain,dc=tld” /I:S /G “DOMAIN\GroupExchangeHybrid“:WP;”proxyAddresses”;user”
DOMAIN\GroupExchangeHybrid“:WP;”msExchUserHoldPolicies”;user”
DOMAIN\GroupExchangeHybrid“:WP;”msExchArchiveStatus”;user”
DOMAIN\GroupExchangeHybrid“:WP;”msExchBlockedSendersHash”;user”
DOMAIN\GroupExchangeHybrid“:WP;”msExchSafeRecipientsHash”;user”
DOMAIN\GroupExchangeHybrid“:WP;”msExchUCVoiceMailSettings”;user”
DOMAIN\GroupExchangeHybrid“:WP;”publicDelegates”;user”
DOMAIN\GroupExchangeHybrid“:WP;”msDS-ExternalDirectoryObjectId”;user”

 

Add service accounts to the groups

With the right permissions in place, we can now add existing Azure AD Connect service accounts to the groups, or create new service accounts.

Azure AD Connect initiates synchronization cycles every 30 minutes, by default. The new group memberships will be automatically effective the next synchronization cycle, unless you run the Azure AD Connect service with the same service account. In this latter case, restart the Azure AD Connect server(s) for the changes to take effect.

 

Remove legacy permissions

After you’ve properly and granularly delegated Directory Services permissions, you can remove the legacy permissions. You can use the Security tab on the domain level to observe and remove these permissions. Don’t be surprised if you stumble upon even older Azure AD Connect service accounts here.

 

Optionally: Remove  old Azure AD Connect service accounts

When you choose to start over with new accounts, you can now safely remove the old Azure AD Connect accounts, as they will no longer be used by Azure AD Connect, and will no longer have any delegated permissions associated to them in Active Directory.

 

Concluding

Having a Microsoft product use default settings does not always result in the most securely configured environment. Having Azure AD Connect create its service account doesn’t result in a desired environment from  a security perspective.

Further reading

AADSync – AD Service Account Delegated Permissions
DSACLS command to Grant Domain Groups Password Reset and Unlock Account
Active Directory Delegation with DSACLS
HOWTO: Properly set and manage Azure AD Connect’s Export Deletion Threshold
HOWTO: Use Domain and OU Filtering to limit objects in scope for Azure AD Connect
HOWTO: Use Azure AD App Filtering to limit attributes for the objects in scope for Azure AD Connect

Series Navigation

<< HOWTO: Use Azure AD App Filtering to limit attributes for the objects in scope for Azure AD ConnectHOWTO: Enable Extended Protection for Authentication on the AD FS Farm >>

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.