Govern on-premises Active Directory based apps (Kerberos) using Microsoft Entra ID Governance
Important
The public preview of Group Writeback v2 in Microsoft Entra Connect Sync will no longer be available after June 30, 2024. This feature will be discontinued on this date, and you will no longer be supported in Connect Sync to provision cloud security groups to Active Directory. The feature will continue to operate beyond the discontinuation date; however, it will no longer receive support after this date and may cease functioning at any time without notice.
We offer similar functionality in Microsoft Entra Cloud Sync called Group Provision to Active Directory that you can use instead of Group Writeback v2 for provisioning cloud security groups to Active Directory. We're working on enhancing this functionality in Cloud Sync along with other new features that we're developing in Cloud Sync.
Customers who use this preview feature in Connect Sync should switch their configuration from Connect Sync to Cloud Sync. You can choose to move all your hybrid sync to Cloud Sync (if it supports your needs). You can also run Cloud Sync side by side and move only cloud security group provisioning to Active Directory onto Cloud Sync.
For customers who provision Microsoft 365 groups to Active Directory, you can keep using Group Writeback v1 for this capability.
You can evaluate moving exclusively to Cloud Sync by using the user synchronization wizard.
Scenario: Manage on-premises applications with Active Directory groups that are provisioned from and managed in the cloud. Microsoft Entra Cloud Sync allows you to fully govern application assignments in AD while taking advantage of Microsoft Entra ID Governance features to control and remediate any access related requests.
With the release of provisioning agent 1.1.1370.0, cloud sync now has the ability to provision groups directly to your on-premises Active Directory environment. You can use identity governance features to govern access to AD-based applications, such as by including a group in an entitlement management access package.
Watch the group writeback video
For a great overview of cloud sync group provisioning to Active directory and what it can do for you, check out the video below.
Prerequisites
The following prerequisites are required to implement this scenario.
- 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.1367.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" -TargetDomainCredential $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 with build version 2.2.8.0 or later.
- Required to support on-premises user membership synchronized using Microsoft Entra Connect.
- Required to synchronize AD:user:objectGUID to Microsoft Entra ID:user:onPremisesObjectIdentifier.
Supported groups
For this scenario, only the following groups are supported:
- Only cloud created Security groups are supported
- Assigned or dynamic membership groups
- Contain only on-premises synchronized users and / or cloud created security groups
- 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
- Written back with the AD groups scope of universal. Your on-premises environment must support the universal group scope
- Not larger than 50,000 members
- Each direct child nested group counts as one member in the referencing group
Supported scenarios
The following sections discuss the scenarios that are supported with cloud sync group provisioning.
Configuring supported scenarios
If you want to control whether a user is able to connect to an Active Directory application that uses Windows authentication, you can use the application proxy and a Microsoft Entra security group. If an application checks a user's AD group memberships, via Kerberos or LDAP, then you can use cloud sync group provisioning to ensure an AD user has those group memberships before the user accesses the applications.
The following sections discuss two scenario options that are supported with cloud sync group provisioning. The scenario options are meant to ensure users assigned to the application have group memberships when they authenticate to the application.
- Create a new group and updating the application, if it already exists, to check for the new group, or
- Create a new group and updating the existing groups, the application was checking for, to include the new group as a member
Before you begin, ensure that you're a domain administrator in the domain where the application is installed. Ensure you can sign into a domain controller, or have the Remote Server Administration tools for Active Directory Domain Services (AD DS) administration installed on your Windows PC.
Configuring the new groups option
In this scenario option, you update the application to check for the SID, name or distinguished name of new groups created by cloud sync group provisioning. This scenario is applicable to:
- Deployments for new applications being connected to AD DS for the first time.
- New cohorts of users accessing the application.
- For application modernization, to reduce the dependency on existing AD DS groups.
Applications, which currently check for membership of the
Domain Adminsgroup, need to be updated to also check for a newly created AD group also.
Use the following steps for applications to use new groups.
Create application and group
- Using the Microsoft Entra admin center, create an application in Microsoft Entra ID representing the AD-based application, and configure the application to require user assignment.
- If you're using application proxy to enable users to connect to the application, then configure the application proxy.
- Create a new security group in Microsoft Entra ID.
- Use Group Provisioning to AD to provision this group to AD.
- Launch Active Directory Users and Computers, and wait for the resulting new AD group to be created in the AD domain. When it's present, record the distinguished name, domain, account name and SID of the new AD group.
Configure application to use new group
- If the application uses AD via LDAP, configure the application with the distinguished name of the new AD group. If the application uses AD via Kerberos, configure the application with the SID, or the domain and account name, of the new AD group.
- Create an access package. Add the application from #1, the security group from #3, as resources in the Access Package. Configure a direct assignment policy in the access package.
- In Entitlement Management, assign the synced users who need access to the AD based app to the access package.
- Wait for the new AD group to be updated with the new members. Using Active Directory Users and Computers, confirm that the correct users are present as members of the group.
- In your AD domain monitoring, allow only the gMSA account that runs the provisioning agent, authorization to change the membership in the new AD group.
You can now govern access to the AD application through this new access package.
Configuring the existing groups option
In this scenario option, you add a new AD security group as a nested group member of an existing group. This scenario is applicable to deployments for applications that have a hardcoded dependency on a particular group account name, SID, or distinguished name.
Nesting that group into the applications existing AD group will allow:
- Microsoft Entra users, who are assigned by a governance feature, and then access the app, to have the appropriate Kerberos ticket. This ticket contains the existing groups SID. The nesting is allowed by AD group nesting rules.
If the app uses LDAP and follows nested group membership, the app will see the Microsoft Entra users as having the existing group as one of their memberships.
Determine eligibility of existing group
- Launch Active Directory Users and Computers, and record the distinguished name, type and scope of the existing AD group used by the application.
- If the existing group is
Domain Admins,Domain Guests,Domain Users,Enterprise Admins,Enterprise Key Admins,Group Policy Creation Owners,Key Admins,Protected Users, orSchema Admins, then you'll need to change the application to use a new group, as described above, as these groups can't be used by cloud sync. - If the group has Global scope, change the group to have Universal scope. A global group can't have universal groups as members.
Create application and group
- In the Microsoft Entra admin center, create an application in Microsoft Entra ID representing the AD-based application, and configure the application to require user assignment.
- If application proxy is used to enable users to connect to the application, then configure the application proxy.
- Create a new security group in Microsoft Entra ID.
- Use Group Provisioning to AD to provision this group to AD.
- Launch Active Directory Users and Computers, and wait for the resulting new AD group to be created in the AD domain, When it's present, record the distinguished name, domain, account name and SID of the new AD group.
Configure application to use new group
- Using Active Directory Users and Computers, add the new AD group as a member of the existing AD group.
- Create an access package. Add the application from #1, the security group from #3, as resources in the Access Package. Configure a direct assignment policy in the access package.
- In Entitlement Management, assign the synced users who need access to the AD based app to the access package, including any user members of the existing AD group who still need access.
- Wait for the new AD group to be updated with the new members. Using Active Directory Users and Computers, confirm that the correct users are present as members of the group.
- Using Active Directory Users and Computers, remove the existing members, apart from the new AD group, of the existing AD group.
- In your AD domain monitoring, allow only the gMSA account that runs the provisioning agent, authorization to change the membership in the new AD group.
You'll then be able to govern access to the AD application through this new access package.
Troubleshooting
A user who is a member of the new AD group, and is on a Windows PC already logged into an AD domain, might have an existing ticket issued by an AD domain controller that doesn't include the new AD group membership. This is because the ticket might have been issued prior to the cloud sync group provisioning adding them to the new AD group. The user won't be able to present the ticket for access to the application, and so must wait for the ticket to expire and a new ticket issued, or purge their tickets, log out and log back into the domain. See the klist command for more details.
Existing Microsoft Entra Connect group writeback v2 customers
If you're using Microsoft Entra Connect group writeback v2, you'll need to move to cloud sync provisioning to AD before you can take advantage of cloud sync group provisioning. See Migrate Microsoft Entra Connect Sync group writeback V2 to Microsoft Entra Cloud Sync