Group Management Today Prepares for Utilizing Azure AD Connect Tomorrow

The majority of organizations that have been around for more than a couple of years have enough reasons to keep their on-premises active directory (AD) environment around. Whether it is to support device management, authentication for on-premises Microsoft or other third party services, or access to file shares, we have a long way to go before we completely abandon a traditional AD environment.

The long runway for migration from on-premises AD has positioned directory synchronization tools as cornerstones in most cloud platforms today. While highly effective in keeping matching objects between AD and Microsoft 365 (M365) ecosystems, these synchronization tools create a disjointed experience for most organizations.

Since the launch of the Azure AD Connect service in 2015, it has been a core piece of architecture for organizations transitioning into Microsoft cloud platforms. In addition to being free, the service remains the best and easiest way to keep on-premises AD objects up to date in the cloud.

Despite its mainstream use, this service is not without its quirks. One of the major headaches in managing objects in hybrid identity is understanding the concept of which environment the object is anchored. In other words, in which environment did the administrator create the object?

The example below captures the most common configuration we see with our customers. Here we see an on-premises AD environment and an Azure AD environment (which supports M365), with Azure AD Connect as the directory sync tool that matches groups from on-premises to the cloud.

For the On-Prem Group in Azure AD, notice the group has a lock icon next to it. I’ve included this icon because it is a mirror of the original group in the on-premises AD environment, and it was synchronized via Azure AD Connect to Azure AD.

What does this mean for users and administrators? Any changes (name, membership, hiding it from the global address list), must be made in the on-premises AD environment. In contrast, the Cloud Only Group can reside in Azure AD and be fully modified and changed natively in that environment. The Cloud Only Group does not have a matching group in the on-prem AD environment.

There are some implications that are not always apparent. Here are some ideas to consider about group management based on our most common customer scenarios:

• Groups must be managed in both systems.
•  On-premises or cloud groups may not support incoming email depending on routing settings.
• Group settings and membership for on-premises groups are managed by IT.
• Group settings and membership for cloud-only groups are managed by IT or users.
• Groups with similar names and functions may need to be created, such as an HR group for access to the file share and an HR group that supports an MS Team.
• M365 groups (aka unified groups) can only be created as cloud-only groups.
• On-Premises groups can be used to provide access to some O365 resources.
• Cloud-only groups cannot be used to provide access to on-prem resources.
• Dynamic groups cannot be synchronized from on-premises to the cloud.
• Management of mail-enabled groups through Outlook will only work for groups anchored in that environment. An on-prem mailbox can manage on-prem groups, and a cloud mailbox can manage cloud-only groups.

Also consider that groups cannot be nested in M365 groups. This isn’t a result of Azure AD Connect utilization, but it is a major part of the disjointed experience and a limitation of M365 groups, so it’s an important problem to note.

For most M365 users, the ability to create and manage M365 groups is a huge functionality boost. By default, without assistance from IT, users can create and manage M365 groups that can function as a security group, distribution group, shared mailbox, SharePoint site and Microsoft Team. This amplifies users’ autonomy when compared to users who require IT to be a gatekeeper, a custom workflow or user access to an AD administrator interface. As a result, it's easy to imagine M365 groups rapidly becoming the preferred group type for end users.

Some organizations have historically allowed end users to manage group membership (both distribution lists and security) in the on-premises Exchange environment, where users are accustomed to this functionality. For them, locking group management behind IT will be an especially tough pill to swallow since they will be losing this functionality as they transition away from the on-premises environment.

I expect that as time passes, more organizations will default to cloud-only groups, but the increased autonomy comes with some downsides:

• Inconsistent Behaviors — The difference in group manageability and functionality can be confusing to end users when they see the ability to manage membership for some groups but not others. This is because they are not visibly different from most end user applications.
• Lack of standardization — Groups created by end users frequently fail to adhere to standardized naming conventions and may have a similar or the same name as other groups or resources in the environment. This lack of governance tends to lead to a sprawling M365 environment making it difficult for users and administrators searching for the right resources.

After reading this far you might be thinking, “If these cloud-only groups provide all this extra value to our end users, and we’re stuck governing the cloud-only groups anyway, why don’t we just move all our groups to be cloud-only?” This appears to be the direction Microsoft is leading us, with the biggest short-term question being how to use these cloud groups to assign permissions to on-premises resources.

However, that desired end state where we are Azure AD first appears to be far away. While Microsoft does have group writeback functionality in Azure AD Connect, which takes a cloud-only group and creates a mirror copy on-premises, the current functionality falls short for a few reasons:

• Not all relevant group types are synchronized.
• Groups are not synchronized back in a group format.
• The functionality doesn’t support permission assignment.

Due to these shortcomings of Azure AD Connect’s current capabilities, most organizations cannot make this leap today.

Microsoft has recently made some announcements about their Group Writeback capabilities that will dramatically improve the group management story for most of our customers. The full and up-to-date version of the new features in preview are listed in the Microsoft Knowledge base here.

Some highlights of these announced features:

• M365 groups can be written back to AD as mail-enabled security groups.
• Cloud Dynamic Groups can be written back to AD.
• Group nesting in Azure AD will be written back to AD if both groups exist on-premises.

As you can see some of these new features are positioned to change the game and provide a lot of incentives for admins to move deeper into making Azure AD their source of truth for group management.

It’s unclear exactly when and how functional these features will be when the launch finally happens, but I think we will eventually see the architecture below become the standard model for most organizations:

This model would give us the best of both worlds. Cloud-only groups will supply admins and users the best options for productivity and management, using those groups to access systems that still rely on on-premises AD. On-premises groups could continue to be synced to the cloud as they are today, but I would expect that to become less common as time goes on.

Today admins are stuck between a rock and hard place. There simply isn’t a good end state for  consistent management of end users that allows access to all the resources users need. However, as we can see on the roadmap, this hopefully will not be the case forever.

For now, we encourage our customers to begin shifting toward cloud only groups to make adoption of the new Azure AD Connect features easier once they begin to roll out. The best place to start would be reviewing new group requests and determine whether they support any on-premises systems. If not, create them as cloud-only groups.

For organizations that want to be more proactive or gain some efficiencies around user group management, it is also possible to convert on-premises groups to cloud-only groups. These conversions can be a tricky at scale and should ask several questions:

• Is this group supplying security access to a resource, and where is that resource located?
• If the group is converted, how can we reassign those permissions?
• Is this group nested inside another group? And on the other hand,
• Does this group have groups nested inside it?
• Is this group supporting email? If so, are these internal or external emails?

CDW’s professional services team has years of experience helping customers navigate these group management decisions and hurdles. We developed customized scripts and procedures to help customers efficiently and repeatably convert synced, on-premises groups into cloud-only groups, while avoiding common pitfalls. If you want to set up time to speak with a specialist, do not hesitate to ask your CDW Account Executive about Microsoft 365 Advisory or Cloud Group Conversion Services.

Story by Ryan Bandel, a Technical Architect focused on Microsoft Collaboration on the Services R&D team at CDW.