Detecting Changes in Container Management Labels

Using sensitivity labels to control the settings of Microsoft 365 groups, teams, and sites is a very powerful management tool. Since introducing the mechanism, Microsoft has steadily expanded the set of controls that container management labels can apply, like the privacy mode for a group or team. The latest update introduced settings to control the discoverability of private teams.

Nice as it is for Microsoft to continue evolving container management labels by expanding settings, one thing they haven’t done is to provide any method to lock a container management label in place. New groups, teams, or sites can receive a label during the creation process, or a label can be assigned afterwards. And here lies the problem. Any group owner can change the assigned label and apply a label with more restrictive or more permissive settings. Figure 1 shows the option for a team owner to select a container management label.

The logic here is probably that group owners can change the individual settings controlled by labels, such as external access or sharing modes. If this is the case, why shouldn’t a group owner be able to change all the settings controlled by a label by simply switching out the existing label for another label?

My perspective is different. I think that if an organization assigns a container management label to a group, team, or site, it has a good reason to do so. For example, a new site might hold very confidential information that mandates restricted access. To meet this requirement, the person creating the site chooses an appropriate label. Once that label is in place, it should not be changed without some kind of oversight and approval, and that’s what’s missing in Microsoft 365.

PowerShell to Check Assigned Container Management Labels

Fortunately, it’s possible to create a solution in PowerShell to monitor the labels assigned to containers and highlight inconsistencies. The script discussed in this article uses cmdlets from the Exchange Online management module like Get-UnifiedGroup and Set-UnifiedGroup to retrieve and update labels, and uses a custom attribute to store details of the label that should be assigned to a group.

Recently, I was asked if it was possible to update the script to use the Microsoft Graph PowerShell SDK. The original script (written in early 2021) works, but the Get-UnifiedGroup cmdlet is “heavy” in processing terms. Using the Get-MgGroup cmdlet to find a set of groups is usually faster, especially as the number of groups to be processed climbs past a few hundred.

Updating Sensitivity Labels for Groups

It’s certainly possible to use Get-MgGroup or a Graph API request to find groups and include the assignedLabels property in the information returned for each group:

[array]$Groups = Get-MgGroup -All -PageSize 500 -Filter “(groupTypes/any(c:c eq ‘unified’))”
-Property DisplayName, Id, assignedLabels

An example of using a Graph API request is explained in this article about reporting the labels assigned to groups.

In passing, assignedLabels indicates that an object can be assigned multiple sensitivity labels; this is true, but only when the labels don’t encrypt content. Container management labels can also be used for information protection and to encrypt content using rights management. However, I recommend that organizations use separate sets of sensitivity labels for container management and information protection. This scheme makes labels easier to manage.

The Update-MgGroup cmdlet can be used to assign a label to a group. This code creates a hash table to hold the GUID for the label to assign to a group. It then creates another hash table to hold the parameters for the update and includes the label information (in an array, because there might be multiple labels). Finally, Update-MgGroup applies the label.

$DefaultSensitivityLabel = “e42fd42e-7240-4df0-9d8f-d14658bcf7ce” # Guid for General Access label
$AssignedLabels = @{}
$AssignedLabels.Add(“LabelId”, $DefaultSensitivityLabel)
$Parameters = @{}
$Parameters.Add(“assignedLabels”, @($AssignedLabels))

Update-MgGroup -GroupId $Group.Id -BodyParameter $Parameters

But then we run into the problem of how to store details of the label that’s just been assigned. We need this information to check in the future if someone changed the label. The problem is that the Groups resource type in the Microsoft Graph doesn’t support the custom attributes available in Exchange Online and accessible using Get-UnifiedGroup and Set-UnifiedGroup. User accounts does support the 15 custom attributes in the onPremisesExtensionAttributes resource type.

Next Step to Find the Right Extensibility Option

I don’t know why Microsoft decided not to support the custom attributes for Microsoft 365 groups. It’s possible that the Entra ID designers didn’t see the need for these attributes because they weren’t aware of how organizations use custom attributes to store information about groups. Another reason might be that Entra ID supports several group types and a common schema is used for all types.

In any case, other extensibility options exist for the Graph, including directory extensions. The next step is to review each option and figure out which is the best choice. Thinking cap on!

Need more advice about how to write PowerShell for Microsoft 365? Get a copy of the Automating Microsoft 365 with PowerShell eBook, available standalone or as part of the Office 365 for IT Pros eBook bundle.