Azure AD Connect Group Writeback Deep Dive 

Azure AD Connect Group Writeback is still very new. After spending some time to better understand how it works with the attribute flow and some possible use cases, I’ve come up with some practical pointers for you to consider prior to deployment. Please keep in mind this is version 1.0 and I would expect more flexibility and enhancements in the future, but for now let’s look at Azure AD Connect Group Writeback under the hood. 

Azure AD Global Settings 

If we run the PowerShell (Get-ADSyncGlobalSettings).parameters | sort Name | ft Name,Value cmdlet on the Azure AD Connect server (ADSync PowerShell module) as seen in Figure 1, we can see in the red boxes UserWriteback shows up as False and lower down we can see the UserWriteBack.Container attribute is also ready. Although we can’t turn this feature on yet, it does appear that UserWriteback might be coming soon. 

Looking through the settings below, you can also see other features like AutoUpgradeState, AnchorAttribute, UPNAttribute, ServerConfigurationVersion, StagingMode. 

New Synchronization Rules in Azure AD Connect 

Now, let’s look at Azure AD Connect and the new Synchronization Rules for Group Writeback. You can get to the Azure AD Connect – Synchronization Rules Editor from the Start menu, then under Azure AD Connect click on ‘Synchronization Rules Editor.’ 

In Figure 3, We see the new Group Writeback Synchronization Rule ‘In from AAD – Group SOAInAAD’ and if you click View and go to the Scoping filter tab, we notice when the Azure AD cloudMastered attribute is set to TRUE this triggers Azure AD Connect to synchronize this group to Active Directory. 

Looking at the Join rules tab, we see that the Azure AD cloudAnchor attribute is replicated to the Active Directory cloudAnchor attribute. 

The Transformations tab shows the attribute mappings from the target (Azure AD) to the source (Active Directory) 

IMPORTANT NOTE: these rules should never be changed, if there is a technical requirement to make an update you should create a new Rule with a lower Precedence and disable the current rule. This always gives you a backout plan. 

AAD Connect Metaverse Attributes 

I created three different groups in Azure AD for this test to look at the Azure AD Connect metaverse and Active Directory attributes to better understand what is really happening. 

1. AZ SG01 / Azure AD Security Group 

2. M365 – SG01 / Microsoft 365 Security Group 

3. M365 – MESG01 / Microsoft 365 Mail-Enabled Security Group 

NOTE: The Azure AD Connect ‘metaverse’ is simply the database (SQL Express or SQL) with source and target tables that store objects from all the connected directories (Active Directory, Azure AD, LDAP, etc.). Azure AD Connect Import and Synchronization tasks compares the source and target objects in the metaverse to know which attributes it needs to update. Then the final Export task runs to update appropriate objects.  

Figure 4 shows the metaverse search of the Microsoft 365 mail-enabled security group M365 – MESG01.  We can see the cloudAnchor, which is how Azure AD Connect keeps track of the group and changes. The cloudMastered attribute tells us it is a cloud-only group and is not synchronized from Active Directory. Then we see an attribute targetWritebackType for the Microsoft 365 mail-enabled security group that doesn’t show up for the other two types of groups. 

Figure 5 shows the Microsoft 365 security group M365 – SG01, and we see the same cloudAnchor and cloudMastered. Notice the targetWritebackType isn’t populated on a Microsoft 365 security group. The targetWritebackType only shows up on a Microsoft 365 mail-enabled security group. 

Let’s move to Active Directory and look at the Microsoft 365 mail-enabled security group M365 – MESG01 since it has the most attributes. In Figure 6, we see the Exchange attributes below in the green box that begin with msExch***** and new values for msExchRecipientDisplayType and msExchRecipientTypeDetails as described below.  

Also notice the Active Directory Group SamAccountName looks rather different, this is because the SamAccountName isn’t replicated from Active Directory to Azure AD since the SamAccountName must be unique across the entire forest. Since Azure AD is multi-tenant the SamAccountName isn’t really used by Azure AD tenants. 

When examining objects replicated to Active Directory we can see the different attributes and how they are updated based on the original Azure AD object type and Group Writeback settings.

For instance, using the Get-ADGroup cmdlet, we can see how each group has a unique set of attributes to distinguish them. I only included a single Active Directory attribute dump in Figure 6 of the Microsoft 365 mail-enabled security group M365 – MESG01. 

Get-ADGroup -Filter {DisplayName -eq ‘ <Group DisplayName>’} -Properties * 

Azure AD security group ‘AZ SG01’ 

• GroupCategory = Security 
• GroupScope = Universal  
• groupType = -2147483640  

Microsoft 365 security group ‘M365 – SG01’ 

• GroupCategory = Distribution 
• GroupScope = Universal  
• groupType = 8 
• msExchRecipientDisplayType = 17 (new value for Azure AD Group) 

• msExchRecipientTypeDetails = 8796093022208 (new value for Azure AD Group) 

Microsoft 365 mail-enabled security group ‘M365 – MESG01’ 

• GroupCategory = Security 
• GroupScope = Universal  
• groupType = -2147483640  

• msExchRecipientDisplayType = 17 (new value for Azure AD Group) 
• msExchRecipientTypeDetails = 8796093022208 (new value for Azure AD Group) 

Hopefully, this information helps you understand how the Group writeback feature works and the attribute differences. 

Use Cases  

I then started to think about when and how I might use the Group Writeback feature and came up with some possible applications. 

• You are involved in a tenant-to-tenant migration and the tools you’re using like Quest® OnDemand Migration can replicate Microsoft 365 or security groups from the source tenant to the target tenant.
  • You can now use Group Writeback to synchronize those migrated groups from Azure AD to your Active Directory. 
  • Before this feature you needed to replicate those groups with other methods and automate the group updates. Now you can easily migrate those groups and modify/master them in Azure AD and Group Writeback will do the rest. 

• You are deploying Azure workstreams like Microsoft Endpoint Manager (aka Intune), SharePoint, Teams, or PowerApps and want to use Azure AD Cloud groups, but also want to have the group membership on-premises Active Directory for other purposes. 
• Almost all customers are trying to figure out how to move to cloud-only identities. There are a few Human Capital Management (HCM) systems that can do what is called System for Cross -Domain Identity Management (SCIM). In short, the goal is to use a SaaS solution like Workday to provision accounts directly into Azure AD.  
  • I could see HCM provisioning new groups in Azure AD and using Group Writeback to provision and maintain those groups in Active Directory. 
  • Before rushing into this, this feature needs to be designed with naming conventions, specific cloud and on-premises application requirements, and business use cases. But I see it as a great first step in that direction. 

Important Notes about Deployment 

• You can move an Azure AD Microsoft 365/security group from the original Active Directory OU where it was created to a new Active Directory OU, but when the Azure AD Connect delta runs it will move that group back to the OU where it was originally created. 
• If an Exchange Online user is an Owner of a Microsoft 365 mail-enabled security group or Microsoft 365 security group, they can administer these groups via OWA or Outlook. They can: 
  • Add or delete members 
  • Deliver all group conversations and events to members’ inboxes. 
  • Edit the group to receive either internet or internal email.  

• Microsoft 365 mail-enabled security groups or Microsoft 365 security groups (Distribution Lists) do NOT show up in on-premises Exchange Global Address List (GAL). This is very important if you are in an Exchange Hybrid environment and thinking about moving to Microsoft 365 groups in Azure AD. Users with on-premises mailboxes won’t be able to see the groups.  
• You must set up Active Directory synchronized identities for all members of Azure AD groups you want to synchronize back to Active Directory.
  • This means you can add any Active Directory User object to an Azure AD Microsoft 365 group and have it synchronized back. 
  • If you add any Azure AD cloud-only identities, they will not show up in Active Directory and your group membership will not be consistent.