Epic news on Azure AD Groups, this as the new Group Writeback (V2) functionality went in public preview last week. In the past Group Writeback was only available for Microsoft 365 groups and was mostly used to get your Exchange Online Address Lists and Address Books up to date.

That limitation has now been removed with the new Group Writeback functionality and enables you to leverage Azure AD cloud groups for their on-premises (hybrid) needs and will provide the following capabilities:

• Microsoft 365 groups (assigned & dynamic) can be written back not only as Distribution list but also as security groups or mail-enabled security groups.
• Azure AD security groups (assigned & dynamic) can be written back as a security group.
• You can decide per group if it needs to be written back in your on-premises Active Directory.

In simple words, the power of groups from the cloud and anything attached to group features (like Dynamic Groups or Access Packages & Access Reviews in Identity Governance) can now be enabled for on-premises resources as well via an Azure AD Group which is written back to your on-premises Active Directory.

The following is required to make use of this functionality:

• Azure AD Premium Licenses
• An up-to-date Azure AD Connect version (min. 2.0.89.0 but preferably the latest)
• Azure AD Connect group writeback enabled
• Enabling Group Writeback V2
• Write-back permissions for the service account

The following limitations do exist today with this new Group Writeback functionality:

• Group writeback always writes back groups as the group scope type ‘Universal’, changing this type manually to another doesn’t have any affect as with the next sync the group scope type will be changed back to ‘Universal’.
• Group writeback does not support writeback of nested group members with group scope type ‘Domain local’ since Azure AD security groups are written back with scope ‘Universal’. If you have a nested group like this, you’ll see an export error in Azure AD Connect with the message “A universal group cannot have a local group as a member” and the resolution is it remove the member with scope ‘Domain local’ from the Azure AD group. 
• Group writeback only supports writing back groups to a single Organization Unit (OU). Once the feature is enabled, you cannot change the OU you selected. A workaround for this is to disable group writeback entirely in Azure AD Connect and then select a different OU when you re-enable the feature, which will delete and re-create the groups.
• Group writeback setting to manage new security group writeback at scale is not available currently. You will need to configure writeback for specific groups on individual level.
• Once groups are written back to your Active Directory, they can only be deleted by permanently deleting them within the Azure Active Directory. Setting the sync value back to ‘No Writeback’ won’t delete the group in Active Directory to prevent accidental deletes and it is by design.
• At last, writing back group owners or native cloud users as a member of a group which is enabled for writeback is not supported.

Important to mention is that the new Group Writeback experience is enabled tenant-wide and not per Azure AD Connect server. The default values for writeback settings on Azure AD cloud groups are backwards compatible with the previous Group Writeback experience. If you did already enable the previous Group Writeback experience, all Microsoft 365 groups will continue to be written back as Distribution lists, without Azure AD Security Groups being written back so there is no need to worry.

Now we know what is required and what the limitations are, let’s check how you can make use of this new Group Writeback experience.

---

Configure and use the new Group Writeback experience

Step 1 – Set writeback state on existing Microsoft 365 groups

This step is highly recommended if you haven’t used group writeback before, if you are already using group writeback to writeback Microsoft 365 groups this step can be skipped.

Before enabling the Group Writeback feature, we first need to prevent all existing Microsoft 365 Groups from being written back. Otherwise all Microsoft 365 groups within your tenant are written back by default. For this we need to set the ‘isEnabled‘ flag within the writebackConfiguration for each group to ‘False‘, by default this value is ‘null‘ (which in practice means ‘true’) and therefore the value should first be updated as you can see in the example below:

Now to update this ‘isEnabled’ value to ‘False’ in bulk, you can use the script below (alter the ‘$groups = ***’ query statement if needed):

#Import-module
Import-module Microsoft.Graph

#Connect to MgGraph Beta
Connect-MgGraph -Scopes Group.ReadWrite.All
Select-MgProfile -Name beta

#Retrieve all Groups
$Groups = Get-MgGroup -All | where {$_.GroupTypes -like "*unified*"}

Foreach ($group in $groups) {
	Update-MgGroup -GroupId $group.id -WritebackConfiguration @{isEnabled=$false}
}

Now the ‘isEnabled‘ flag is set to false for all Microsoft 365 groups as you can see below we can safely proceed to the next step which is adding a sync rule within Azure AD Connect to prevent the actual writeback of these Microsoft 365 groups or to delete them in Active Directory when they have already been written back earlier.

To add the sync rule first download the script here and run it on your Azure AD Connect Server (if you have an active / passive setup you need to run the script on both machines!).

NOTE: The script is developed by Microsoft and fully supported as it’s available on the Microsoft Docs as well.

When asked for the sync rule precedence, put in a number between 0-99 which you haven’t used. In my example I’ve picked 10 (as this number was still available for me).

Once the script has been executed, you can see within the Azure AD Connect Synchronization Rules Editor the rule (Precedence 10) which has been added and which is enabled by default.

Only if you already did enable Group Writeback earlier (as this is an updated blog post) this can trigger deletes with the next synchronization (which triggers a full synchronization automatically for the Azure AD connector). You can see this as the export to your Active Directory step has objects that have been deleted, 13 in my case (for me these are the Microsoft 365 groups which have the Group Writeback Settings set to ‘No Writeback’).

If you ever want revert back to the original Synchronization rule base (for specific reasons) you can decide to disable or delete the rule. Now the ‘No Writeback’ values have been set and the Synchronization rule has been added we can continue with the next step which is configuring Group Writeback Azure AD Connect.

Step 2 – Configure Group writeback in Azure AD Connect

The second step is to change the optional features in Azure AD Connect, again important to know is that the version of Azure AD Connect should be at a minimum of 2.0.89.0 but preferably the latest! Once you’ve made sure you’re on version 2.0.89.0 or higher, open the Azure AD Connect wizard and hit ‘Configure’.

Within the additional tasks pane, make sure to select ‘Customize synchronization options’ and hit ‘Next’. Now sign-in with an Azure AD Global Administrator or Hybrid Identity Administrator account and continue to the ‘Optional features’ configuration.

Within the ‘Optional features’ make sure to enable the checkbox before ‘Group writeback’ and hit ‘Next’

Within the ‘Group Writeback’ configuration, make sure to select the Organizational Unit (OU) in which you want to have the Azure AD Groups written back to in your on-premises Active Directory. And enable the checkbox ‘Writeback Group Distinguished Name with cloud Display Name’, the latter becoming very helpful if we are going to search for groups. Once done hit ‘Next’.

NOTE: The above OU must be selected as well within the OU Filtering selection, you will receive an error otherwise (the OU can of course be empty if that’s what you desire, so it’s only filled with groups written back from Azure AD).

Within the ‘Group Writeback permissions’ select ‘I will configure it using the PowerShell module before continuing’. This as not every IT Administrator is able to put in Enterprise Admin Credentials into Azure AD Connect and using the least privilege model. Once selected hit ‘Next’.

Within the ‘Ready to configure’ pane, verify what you’ve just configured, make sure that ‘Start the synchronization process when configuration completes’ is selected and hit ‘Configure’.

Now wait until the Azure AD Connect wizard says ‘Configuration Complete’ and hit ‘Exit’. At this point, we have only enabled group writeback V1, which is a requirement to ‘step up; to Group writeback V2 :-)!

However, first let’s make sure that the service account used for writing back values in your Active Directory (the Azure AD Connect SA account) has enough permissions to do so for groups.

Therefore, run the following PowerShell cmdlets and hit ‘Yes’ for confirmation to perform the action:

# Import PowerShell module
Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\AdSyncConfig.psm1"

# Grant the AAD Sync account permission to the specified OU (eg. the OU chosen to writeback Office 365 Groups to):
$AzureADConnectSWritebackAccountDN = ‘CN=AADConnect Service Accounts,OU=Service Accounts,OU=Identity-Man,DC=identityman,DC=local’
$GroupWritebackOU = ‘OU=Groups,OU=Identity-Man,DC=identityman,DC=local’
Set-ADSyncUnifiedGroupWritebackPermissions -ADConnectorAccountDN $AzureADConnectSWritebackAccountDN -ADObjectDN $GroupWritebackOU

Once ran successfully, you will see the message ‘The command completed successfully’, this means the permissions for Group Writeback have been configured for the service account in Active Directory.

At this point all the Microsoft 365 Groups in Azure Active Directory will be written back to Active Directory (which is simply the functionality provided in Group Writeback V1). We can verify this by running these two PowerShell cmdlets:

Import-Module 'C:\Program Files\Microsoft Azure AD Sync\Bin\ADSync\ADSync.psd1'
Get-ADSyncAADCompanyFeature

As you can see here ‘GroupWritebackV2’ is not enabled (set to False). Now to upgrade the configuration so it can also writeback any type of Azure AD Security Group, verify there isn’t an active synchronization operation and run the following PowerShell cmdlets:

Import-Module 'C:\Program Files\Microsoft Azure AD Sync\Bin\ADSync\ADSync.psd1'
Set-ADSyncScheduler -SyncCycleEnabled $false
Set-ADSyncAADCompanyFeature -GroupWritebackV2 $true
Set-ADSyncScheduler -SyncCycleEnabled $true

Once configured I’ve ran a full synchronization to make sure that all objects are synchronized correctly with the PowerShell cmdlet:

Start-ADSyncSyncCycle -PolicyType Initial

The required steps ‘Turning on Group Writeback in Azure AD Connect’, ‘Providing permissions to the service account’ and ‘Enabling Group Writeback V2’ have now been completed, meaning we can go to the Azure Portal and decide which groups need to be written back.

Step 3 – Disable writeback for newly created Microsoft 365 groups (Optional)

Now we have enabled group writeback you perhaps don’t want newly created M365 groups to be written back to your Active Directory (this as step 1 only takes action for existing groups). For this we can use the Microsoft Graph API to disable this. For this we first need to go to the Graph Explorer and run the following API call GET ‘https://graph.microsoft.com/v1.0/groupSettings’ and hit ‘Run Query’:

In here note down the id of the ‘Group.Unified’ settings and run the following API call PATCH ‘https://graph.microsoft.com/v1.0/groupSettings/{id}’ with the following ‘Request body’ and hit ‘Run Query’:

{
    "values": [
        {
            "name": "NewUnifiedGroupWritebackDefault",
            "value": "false"
        }
    ]
}

The output should say ‘No Content – 204’ as can be seen below.

If we now check the settings with the call GET ‘https://graph.microsoft.com/v1.0/groupSettings/{id}’, we can see the ‘NewUnifiedGroupWritebackDefault’ is now changed to false.

At this point newly AND existing created Microsoft 365 groups aren’t written back anymore (if you have also followed step 1 of course) to the Active Directory. If you however need a new Microsoft 365 group to be written back, you can continue with step 3 to get it written back!

Step 4 – Enable groups for group writeback

To make sure security groups are written back from Azure Active Directory to the on-premises Active Directory we need to enable to writeback setting within the Azure Active Directory. So, let’s search for the groups SG-NL-Finance-Department & DSG-AVD-PUBAPP-SAP.

If we open the group DSG-AVD-PUBAPP-SAP, we can see that the writeback state is by default set to ‘No writeback’. We can change this to ‘Security’ and hit ‘Save’ to trigger the writeback within Azure AD Connect.

If you want to manage this via the Microsoft Graph API, that’s possible as well of course, for that you can run the ‘Patch’ cmdlet and use the following URL ‘https://graph.microsoft.com/beta/groups/{id}’, whereby {id} should be replaced with the objectId of the Azure AD group (see the example below).

PATCH https://graph.microsoft.com/beta/groups/e27129bc-c041-4ba7-9fee-06ae22d147bd
{
    "writebackConfiguration": {
        "isEnabled": true,
        "onPremisesGroupType": "universalSecurityGroup"
    }
}

NOTE: This doesn’t count for Microsoft 365 Group as they have more options in group type for writing back Microsoft 365 groups compared to security groups (Distribution, Mail enabled security & security).

Now we have enabled groups for writeback, let’s have a look at the results.

Step 5 – Results

Now we have enabled groups for writeback in Azure Active Directory, we will see all Microsoft 365 groups being synced to Active Directory instantly (as that’s simply part of Group writeback V1).

However, if we have enabled security groups as well for writeback we can see them being exported to the Active Directory within the ‘Synchronization Service Manager’. As you can see we have ‘2 Adds’.

If we look at the details, we can see that both security groups in Azure Active Directory have been written back.

If we look at the members in Azure Active Directory for group ‘DSG-AVD-PUBAPP-SAP’ we can see that it contains 6 members.

If we however look at the group which is written back in Active Directory we can only see 4 members. It looks like this is incorrect but that’s not the case, only members which do exists within Active Directory (and which are therefore synced) can be written back as a member of the group. Users which are ‘cloud only’ and are a member of the group are therefore not written back as member.

If we look at the members of the group ‘SG-NL-Finance-Department’ in Azure Active Directory, we can see it contains three members.

Now as all these members are synced users, we can all see them as member in the group written back to the Active Directory, as you can see below.

Both groups can now be used as a Universal Security Group in Active Directory and applications and resources attached to it, this with all the benefits and security measurements sourced from the Azure Active Directory. Important to know however, is that membership changes can take up to a maximum of 30 minutes (as that’s the default sync interval of Azure AD Connect), but comparing that and being able to use Dynamic Groups, Access Reviews, Access Packages for groups in the on-premises Active Directory is something we can overcome today if you would ask me :-)!

---

Conclusion

By using the new group writeback feature we are now able to synchronize all Azure Active Directory groups, including members, back to the Active Directory. By doing this we can leverage all group functionalities offered from the cloud in the on-premises Active Directory, whereby you can think of:

• Access Packages – To let users request access to a group which is written back and provides access to an on-premises resource.
• Access Reviews – To challenge & cleanup members and therefore access, if the group was enabled for writeback these changes are reflected in the Active Directory on the next synchronization as well.
• Dynamic Groups – Create dynamic groups in the Azure Active Directory, write them back to Active Directory and use it to provide access to on-premises resources.
• Privileged Access Groups – Create a Privileged Access Group where members can activate their membership via Privileged Identity Management, enabled writeback for the group and with that provide access to on-premises Active Directory resources as well.
• And more.

My advice to you would be to start enabling this functionality in your environment and see which Active Directory based groups you are able to replace with Azure Active Directory groups with writeback enabled. This not only to just replace them, but to see what added value from the Azure Active Directory can be enabled on these groups to improve the security posture of your environment and make sure only employees which should have access are actually the ones which have access.

As usual I hope you enjoyed reading this blog post and it was valuable to you, please stay tuned for some more new blogs which are coming soon! I promise they will be worth waiting for! 🙂

Other Azure AD Group related blogs written by me:

• Using the new Azure AD Dynamic Groups memberOf Property