Редагувати

Поділитися через

Prerequisites for Microsoft Entra Cloud Sync

  • Стаття

This article provides guidance on using Microsoft Entra Cloud Sync as your identity solution.

Cloud provisioning agent requirements

You need the following to use Microsoft Entra Cloud Sync:

  • Domain Administrator or Enterprise Administrator credentials to create the Microsoft Entra Connect cloud sync gMSA (group managed service account) to run the agent service.
  • A Hybrid Identity Administrator account for your Microsoft Entra tenant that isn't a guest user.
  • An on-premises server for the provisioning agent with Windows 2016 or later. This server should be a tier 0 server based on the Active Directory administrative tier model. Installing the agent on a domain controller is supported. For more information see Harden your Microsoft Entra provisioning agent server
    • Required for AD Schema attribute - msDS-ExternalDirectoryObjectId
  • High availability refers to the Microsoft Entra Cloud Sync's ability to operate continuously without failure for a long time. By having multiple active agents installed and running, Microsoft Entra Cloud Sync can continue to function even if one agent should fail. Microsoft recommends having 3 active agents installed for high availability.
  • On-premises firewall configurations.

Harden your Microsoft Entra provisioning agent server

We recommend that you harden your Microsoft Entra provisioning agent server to decrease the security attack surface for this critical component of your IT environment. Following these recommendations will help to mitigate some security risks to your organization.

  • We recommend hardening the Microsoft Entra provisioning agent server as a Control Plane (formerly Tier 0) asset by following the guidance provided in Secure Privileged Access and Active Directory administrative tier model.
  • Restrict administrative access to the Microsoft Entra provisioning agent server to only domain administrators or other tightly controlled security groups.
  • Create a dedicated account for all personnel with privileged access. Administrators shouldn't be browsing the web, checking their email, and doing day-to-day productivity tasks with highly privileged accounts.
  • Follow the guidance provided in Securing privileged access.
  • Deny use of NTLM authentication with the Microsoft Entra provisioning agent server. Here are some ways to do this: Restricting NTLM on the Microsoft Entra provisioning agent Server and Restricting NTLM on a domain
  • Ensure every machine has a unique local administrator password. For more information, see Local Administrator Password Solution (Windows LAPS) can configure unique random passwords on each workstation and server store them in Active Directory protected by an ACL. Only eligible authorized users can read or request the reset of these local administrator account passwords. Additional guidance for operating an environment with Windows LAPS and privileged access workstations (PAWs) can be found in Operational standards based on clean source principle.
  • Implement dedicated privileged access workstations for all personnel with privileged access to your organization's information systems.
  • Follow these additional guidelines to reduce the attack surface of your Active Directory environment.
  • Follow the Monitor changes to federation configuration to set up alerts to monitor changes to the trust established between your Idp and Microsoft Entra ID.
  • Enable Multi Factor Authentication (MFA) for all users that have privileged access in Microsoft Entra ID or in AD. One security issue with using Microsoft Entra provisioning agent is that if an attacker can get control over the Microsoft Entra provisioning agent server they can manipulate users in Microsoft Entra ID. To prevent an attacker from using these capabilities to take over Microsoft Entra accounts, MFA offers protections so that even if an attacker manages to, such as reset a user's password using Microsoft Entra provisioning agent they still cannot bypass the second factor.

Group Managed Service Accounts

A group Managed Service Account is a managed domain account that provides automatic password management, simplified service principal name (SPN) management, the ability to delegate the management to other administrators, and also extends this functionality over multiple servers. Microsoft Entra Cloud Sync supports and uses a gMSA for running the agent. You'll be prompted for administrative credentials during setup, in order to create this account. The account appears as domain\provAgentgMSA$. For more information on a gMSA, see group Managed Service Accounts.

Prerequisites for gMSA

  1. The Active Directory schema in the gMSA domain's forest needs to be updated to Windows Server 2012 or later.
  2. PowerShell RSAT modules on a domain controller.
  3. At least one domain controller in the domain must be running Windows Server 2012 or later.
  4. A domain joined server where the agent is being installed needs to be either Windows Server 2016 or later.

Custom gMSA account

If you're creating a custom gMSA account, you need to ensure that the account has the following permissions.

Type Name Access Applies To
Allow gMSA Account Read all properties Descendant device objects
Allow gMSA Account Read all properties Descendant InetOrgPerson objects
Allow gMSA Account Read all properties Descendant Computer objects
Allow gMSA Account Read all properties Descendant foreignSecurityPrincipal objects
Allow gMSA Account Full control Descendant Group objects
Allow gMSA Account Read all properties Descendant User objects
Allow gMSA Account Read all properties Descendant Contact objects
Allow gMSA Account Create/delete User objects This object and all descendant objects

For steps on how to upgrade an existing agent to use a gMSA account see group Managed Service Accounts.

For more information on how to prepare your Active Directory for group Managed Service Account, see group Managed Service Accounts Overview and Group managed service accounts with cloud sync.

In the Microsoft Entra admin center

  1. Create a cloud-only Hybrid Identity Administrator account on your Microsoft Entra tenant. This way, you can manage the configuration of your tenant if your on-premises services fail or become unavailable. Learn about how to add a cloud-only Hybrid Identity Administrator account. Finishing this step is critical to ensure that you don't get locked out of your tenant.
  2. Add one or more custom domain names to your Microsoft Entra tenant. Your users can sign in with one of these domain names.

In your directory in Active Directory

Run the IdFix tool to prepare the directory attributes for synchronization.

In your on-premises environment

  1. Identify a domain-joined host server running Windows Server 2016 or greater with a minimum of 4-GB RAM and .NET 4.7.1+ runtime.
  2. The PowerShell execution policy on the local server must be set to Undefined or RemoteSigned.
  3. If there's a firewall between your servers and Microsoft Entra ID, see Firewall and proxy requirements.

Note

Installing the cloud provisioning agent on Windows Server Core isn't supported.

Provision Microsoft Entra ID to Active Directory - Prerequisites

The following prerequisites are required to implement provisioning groups to Active Directory.

License requirements

Using this feature requires Microsoft Entra ID P1 licenses. To find the right license for your requirements, see Compare generally available features of Microsoft Entra ID.

General requirements

  • Microsoft Entra account with at least a Hybrid Identity Administrator role.
  • On-premises Active Directory Domain Services environment with Windows Server 2016 operating system or later.
    • Required for AD Schema attribute - msDS-ExternalDirectoryObjectId
  • Provisioning agent with build version 1.1.1370.0 or later.

Note

The permissions to the service account are assigned during clean install only. In case you're upgrading from the previous version then permissions need to be assigned manually using PowerShell cmdlet:

$credential = Get-Credential  

  Set-AADCloudSyncPermissions -PermissionType UserGroupCreateDelete -TargetDomain "FQDN of domain" -EACredential $credential

If the permissions are set manually, you need to ensure that Read, Write, Create, and Delete all properties for all descendent Groups and User objects.

These permissions aren't applied to AdminSDHolder objects by default Microsoft Entra provisioning agent gMSA PowerShell cmdlets

  • The provisioning agent must be able to communicate with one or more domain controllers on ports TCP/389 (LDAP) and TCP/3268 (Global Catalog).
    • Required for global catalog lookup to filter out invalid membership references
  • Microsoft Entra Connect Sync with build version 2.2.8.0 or later
    • Required to support on-premises user membership synchronized using Microsoft Entra Connect Sync
    • Required to synchronize AD:user:objectGUID to AAD:user:onPremisesObjectIdentifier

Supported groups and scale limits

The following is supported:

  • Only cloud created Security groups are supported
  • These groups can have assigned or dynamic membership groups.
  • These groups can only contain on-premises synchronized users and / or additional cloud created security groups.
  • The on-premises user accounts that are synchronized and are members of this cloud created security group, can be from the same domain or cross-domain, but they all must be from the same forest.
  • These groups are written back with the AD groups scope of universal. Your on-premises environment must support the universal group scope.
  • Groups that are larger than 50,000 members aren't supported.
  • Tenants that have more than 150,000 objects aren't supported. Meaning, if a tenant has any combination of users and groups that exceeds 150K objects, the tenant isn't supported.
  • Each direct child nested group counts as one member in the referencing group
  • Reconciliation of groups between Microsoft Entra ID and Active Directory isn't supported if the group is manually updated in Active Directory.

Additional information

The following is additional information on provisioning groups to Active Directory.

  • Groups provisioned to AD using cloud sync can only contain on-premises synchronized users and / or additional cloud created security groups.
  • These users must have the onPremisesObjectIdentifier attribute set on their account.
  • The onPremisesObjectIdentifier must match a corresponding objectGUID in the target AD environment.
  • An on-premises users objectGUID attribute to a cloud users onPremisesObjectIdentifier attribute can be synchronized using either Microsoft Entra Cloud Sync (1.1.1370.0) or Microsoft Entra Connect Sync (2.2.8.0)
  • If you're using Microsoft Entra Connect Sync (2.2.8.0) to synchronize users, instead of Microsoft Entra Cloud Sync, and want to use Provisioning to AD, it must be 2.2.8.0 or later.
  • Only regular Microsoft Entra ID tenants are supported for provisioning from Microsoft Entra ID to Active Directory. Tenants such as B2C aren't supported.
  • The group provisioning job is scheduled to run every 20 minutes.

More requirements

TLS requirements

Note

Transport Layer Security (TLS) is a protocol that provides for secure communications. Changing the TLS settings affects the entire forest. For more information, see Update to enable TLS 1.1 and TLS 1.2 as default secure protocols in WinHTTP in Windows.

The Windows server that hosts the Microsoft Entra Connect cloud provisioning agent must have TLS 1.2 enabled before you install it.

To enable TLS 1.2, follow these steps.

  1. Set the following registry keys by copying the content into a .reg file and then run the file (right click and choose Merge):

    Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

  2. Restart the server.

Firewall and Proxy requirements

If there's a firewall between your servers and Microsoft Entra ID, configure the following items:

  • Ensure that agents can make outbound requests to Microsoft Entra ID over the following ports:

    Port number Description
    80 Downloads the certificate revocation lists (CRLs) while validating the TLS/SSL certificate.
    443 Handles all outbound communication with the service.
    8080 (optional) Agents report their status every 10 minutes over port 8080, if port 443 is unavailable. This status is displayed in the Microsoft Entra admin center.

  • If your firewall enforces rules according to the originating users, open these ports for traffic from Windows services that run as a network service.

  • Ensure that your proxy supports at least HTTP 1.1 protocol and chunked encoding is enabled.

  • If your firewall or proxy allows you to specify safe suffixes, add connections:

URL Description
*.msappproxy.net
*.servicebus.windows.net		 The agent uses these URLs to communicate with the Microsoft Entra cloud service.
*.microsoftonline.com
*.microsoft.com
*.msappproxy.com
*.windowsazure.com		 The agent uses these URLs to communicate with the Microsoft Entra cloud service.
mscrl.microsoft.com:80
crl.microsoft.com:80
ocsp.msocsp.com:80
www.microsoft.com:80		 The agent uses these URLs to verify certificates.
login.windows.net The agent uses these URLs during the registration process.

NTLM requirement

You shouldn't enable NTLM on the Windows Server that is running the Microsoft Entra provisioning agent and if it is enabled you should make sure you disable it.

Known limitations

The following are known limitations:

Delta Synchronization

  • Group scope filtering for delta sync doesn't support more than 50,000 members.
  • When you delete a group that's used as part of a group scoping filter, users who are members of the group, don't get deleted.
  • When you rename the OU or group that's in scope, delta sync won't remove the users.

Provisioning Logs

  • Provisioning logs don't clearly differentiate between create and update operations. You may see a create operation for an update and an update operation for a create.

Group renaming or OU renaming

  • If you rename a group or OU in AD that's in scope for a given configuration, the cloud sync job won't be able to recognize the name change in AD. The job won't go into quarantine and remains healthy.

Scoping filter

When using OU scoping filter

  • The scoping configuration has a limitation of 4MB in character length. In a standard tested environment, this translates to approximately 50 separate Organizational Units (OUs) or Security Groups, including its required metadata, for a given configuration.

  • Nested OUs are supported (that is, you can sync an OU that has 130 nested OUs, but you cannot sync 60 separate OUs in the same configuration).

Password Hash Sync

  • Using password hash sync with InetOrgPerson isn't supported.

Next steps