Entra ID (formerly Azure Active Directory) Connect is the tool that’s used to synchronize identities from your on-premises Active Directory (AD) to EntraID—and in some cases synchronize objects, attributes, and passwords back to your on-premises directory. We discuss the importance of AD identity structure, object cleanup, and installation considerations in an earlier article, Entra ID Connect Installation Strategies. The out-of-box AADC installation creates a set of permissions throughout your directory. These permissions are domain-wide and in some cases do not follow the concept of least privilege. Even with selecting specific organizational units for AAD to synchronize, these permissions are still broadly deployed. Organizations typically have their objects in some sort of hierarchy for users, computers, and groups—sometimes combined together.
A common use case to control access rights for AADC is to restrict password writeback to exclude privileged accounts via Azure self-service password reset (SSPR). An out-of-box installation with SSPR enabled would allow for a password reset of undesired accounts, such as Domain Admin or other accounts with elevated permissions, due to the wide scope of delegated permissions that AADC service accounts are granted.
Entra ID Connect Default Permissions
Partner with Microsoft experts you can trust
If it’s time to take that first step toward leveling up your organization’s security, get in touch with Ravenswood to start the conversation.
An out-of-box AADC installation performs several tasks, but we want to specifically focus on the Active Directory Domain Services (AD DS) Connector account. When using the Express installation settings, this is the MSOL_ account created in your directory. This account is responsible for synchronization to and from your AD environment to the AADC metaverse. It is granted a set of permissions at the root of your directory. These permissions are responsible for writing the consistency GUID and password hash sync, as well as managing Exchange attributes and password, device, and group writeback.
The permissions listed below are delegated to the MSOL_ account at the root of the directory:
- Replicating Directory Changes
- Replicating Directory Changes All
- Users – Reset Password and Read/Write All Properties
- InetOrgPerson – Read/Write All Properties
- Groups – Read/Write All Properties
- Computers – Read/Write All Properties
Of these permissions, the only ones that need to be at the root are Replicating Directory Changes and Replicating Directory Changes All. Replicating Directory Changes All is needed in order for AADC to synchronize password hashes to AAD. Replicating Directory Changes allows AADC to discover changes in the directory.
How to Restrict Permissions
Entra ID Connect likely will not need the ability to modify groups and computers across the board in your environment. In addition, you might be synchronizing some user objects to AAD, but you may not necessarily want password writeback or other attributes on these objects to be modified independently from other identity and access management processes.
The first step in properly delegating access for AADC is to identify where your objects are stored. Several optional AADC features are important in scoping access rights. Password writeback for SSPR, group writeback, and device writeback all grant rights into the on-premises environment that you may want to control. Password writeback allows for password changes/resets originating in Azure to be written to the on-premises AD, which poses a potential risk to sensitive or privileged accounts. Group writeback allows for groups that are created in Azure to be synchronized to a specified on-premises organizational unit for use in Active Directory. Device writeback similarly allows AADC to create computer objects on-premises for use in federated scenarios with Active Directory Federation Services (ADFS). Specifically, we need to know where user objects, computer objects, and group objects are stored in the directory. Once the proper organizational units have been identified, we can delegate granular permissions.
There are several ways to delegate control properly. I prefer to create task groups that define the specific permission being delegated in the directory. For example, a group that would need access to reset user passwords might be named Task-UserOU-UserPwdReset. For this example, we will use the following task groups, which Figure 1 shows:
- Task-ReplDirChanges
- Task-ReplDirChangesAll
- Task-UserOUUserPwdReset
- Task-UserOUUserRW
- Task-UserOUInetOrgPersonRW
- Task-GroupOUGroupRW
- Task-ComputersOUComputerRW
Figure 1 – Example of groups in AD
You will create an Allow rule at the root of the domain for the Replicating Directory Changes permission for “This object only” and select the Task-ReplDirChanges task group as the principal. The same applies for the Replicating Directory Changes All permission and the Task-ReplDirChangesAll task group. Figure 2 shows these changes.
Figure 2 – Replicating directory changes
At the root of each Users, Groups, and Computers organizational unit, you will add an Allow permission for each role, selecting the appropriate descendant User/Group/Computer objects and the appropriate permissions of Read All Properties, Write All Properties, Reset Password, or Change Password. Figure 3 and Figure 4 show these changes.
Figure 3 – Example of Reset Password permissions for the Users organizational unit
Figure 4 – Permissions for the Users organizational unit
After the task group permissions are delegated, you can create and then add the MSOL_ service account as a member of the task groups, as Figure 5 shows.
Figure 5 – MSOL_service account permissions
You can view your current MSOL_ account by launching a PowerShell instance on your AADC server and running the following commands.
To import the ADSyncConfig module, run:
Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\AdSyncConfig.psm1"
To view the current MSOL_service account, run:
Get-ADSyncADConnectorAccount
Additional ADSyncConfig module information can be found here.
After you add the MSOL_ user, you can then remove the permissions that were created by the AADC installer at the root of the domain.
Service Accounts for Custom AADC Installation
This solution lets you create your own service account that you can use during a custom AADC installation. It can also be extended to multiple organizational units where various objects exist.
There are several scenarios in which granular delegation of attributes or permissions can be applied. Ravenswood Technology Group can provide Active Directory health checks as well as assistance with hardening your environment. Contact us today!
