How to Monitor Changes to Sensitivity Labels Used for Container Management

Achieve Consistency for Groups, Teams, and Sites

In June 2020, support for container management through sensitivity labels became generally available. In a nutshell, label settings can control aspects like guest access, privacy, and the sharing capability for SharePoint Online sites. It’s a very powerful and practical way for organizations to apply consistent settings to Microsoft 365 groups, teams, and SharePoint sites.

Some recent work to improve the Teams and Groups activity report script revealed that some groups in my tenant didn’t have sensitivity labels. It seemed like the groups for org-wide teams and Yammer communities were most of the culprits, but I decided that it would be good to apply a default label to all groups without a label. This is reasonably easy with PowerShell. Here’s the code I used:

$DefaultSensitivityLabel = "e42fd42e-7240-4df0-9d8f-d14658bcf7ce" # Guid for General Access
$LabelsAssigned = 0

Write-Host "Fetching Microsoft Groups"
$Groups = Get-UnifiedGroup -ResultSize Unlimited
ForEach ($Group in $Groups) {
   If ($Group.SensitivityLabel -eq $Null) { # No label assigned so let's assign the default label
      Write-Host $Group.DisplayName "has no sensitivity label - assigning the default label" -Foregroundcolor Red
      Set-UnifiedGroup -Identity $Group.ExternalDirectoryObjectId -SensitivityLabel $DefaultSensitivityLabel -CustomAttribute14 $DefaultSensitivityLabel
      $LabelsAssigned++
      }
   Else { # Just update the Custom Attribute
      Set-UnifiedGroup -Identity $Group.ExternalDirectoryObjectId  -CustomAttribute14 $Group.SensitivityLabel
   }
} # End For

Write-Host ("Labels assigned to {0} Microsoft 365 Groups; updated label tracking attribute for {1} groups" -f $LabelsAssigned, $Groups.Count)

Setting a Baseline for Container Labels

Apart from assigning a default label to groups, I use one of the fifteen custom attributes available for mail-enabled objects to store details of the assigned label. The reason why is simple. An organization might assign a sensitivity label to a container, but the Microsoft 365 groups model allows group owners great power over settings, and there’s no way to lock a sensitivity label on a container. Changes to group settings made via an application like Teams or SharePoint Online synchronize with other workloads to make sure that a common view exists across all workloads.

The upshot is that if an organization wants to exert control over group settings, some mechanism must be put in place to check those settings periodically to make sure that group owners haven’t made changes which clash with corporate norms. Storing the assigned label in a custom attribute establishes a baseline that can be checked against. The periodic check can compare the currently assigned label for each group to the one noted in the custom attribute. If a mismatch exists, it can be flagged for action.

Building a List of Container Management Labels

The first thing we’ll do is to build a list of sensitivity labels used for container management. Groups, teams, and sites store label identifiers (GUIDs) for assigned labels. This makes sense because a GUID won’t change while a display name for a sensitivity label might (also, display names can have multiple language values). This code creates a list of container management labels, including the priority of each label. The priority tells us how sensitive a label is. A label with priority 0 (zero) is the least sensitive of any in the organization. By comparing the priority of the original label and a newly assigned label, we can tell if a label replacement is more or less sensitive.

[array]$Labels = Get-Label
$ContainerLabels = [System.Collections.Generic.List[Object]]::new() 
ForEach ($Label in $Labels) { 
    If ($Label.ContentType -Like "*UnifiedGroup*") { # It's a label for container management
      $DataLine = [PSCustomObject] @{
        LabelId     = $Label.ImmutableId
        DisplayName = $Label.DisplayName
        Priority    = $Label.Priority } 
      $ContainerLabels.Add($DataLine) }
}

You must connect to the compliance endpoint to access label information. The easiest way to do this is to connect to the Exchange Online management module and then use the same credentials with the Connect-IPPSession cmdlet.

Checking Groups for Label Changes

The check for label changes is performed by looping through the set of groups to compare the originally assigned label (stored in CustomAttribute14) against the currently assigned label. If a mismatch is found, we capture the information about the old and new labels and figure out if sensitivity is increased or decreased.

Write-Host "Fetching Microsoft Groups"
$Groups = Get-UnifiedGroup -ResultSize Unlimited
$ReviewGroups = [System.Collections.Generic.List[Object]]::new() 
ForEach ($Group in $Groups) {
   If ($Group.SensitivityLabel.Guid -ne $Group.CustomAttribute14) { # We have a mismatch
    Write-Host "Label mismatch discovered for" $Group.DisplayName
    $OldLabelGuid = $Group.CustomAttribute14
    $NewLabelGuid = $Group.SensitivityLabel       
    $OldLabelName = $ContainerLabels | Where-Object {$_.LabelId -eq $OldLabelGuid} | Select -ExpandProperty DisplayName
    $NewLabelName = $ContainerLabels | Where-Object {$_.LabelId -eq $NewLabelGuid} | Select -ExpandProperty DisplayName
    $OldPriority  = $ContainerLabels | Where-Object {$_.LabelId -eq $OldLabelGuid} | Select -Expandproperty Priority
    $NewPriority  = $ContainerLabels | Where-Object {$_.LabelId -eq $NewLabelGuid} | Select -ExpandProperty Priority
    If ($OldPriority -gt $NewPriority) { $LabelStatus = "Sensitivity Label Priority Reduced" 
    } Else { 
      $LabelStatus = "Sensitivity Label Priority Increased"
    }
    $DataLine = [PSCustomObject] @{
        Group       = $Group.DisplayName
        GroupId     = $Group.ExternalDirectoryObjectId
        OldLabel    = $OldLabelName
        OldLabelId  = $OldLabelGuid
        NewLabel    = $NewLabelName
        OldPriority = $OldPriority
        NewPriority = $NewPriority
        Status      = $LabelStatus }    
    $ReviewGroups.Add($DataLine) 
   }
}

Deciding How to Deal with Label Changes

Two obvious approaches could be taken if the original sensitivity label changes:

• Check and query. It’s possible that an administrator or group/team owner changes the label for a good reason. For example, the original label blocked guest access and it is subsequently discovered that guest access is needed. To confirm, you could send email to group owners to ask why the label changed. Alternatively, tenant administrators could review the set of label changes and decide which are appropriate and which should be reversed.
• Check and revert. This is the hard-line approach. The original label is the label and group owners aren’t allowed to change it, so the original label is reapplied.

In the first instance, it should be enough to save the output list to a CSV file and use it as the basis for communication with group owners. Something like this will do the job:

$ReviewGroups | Export-CSV -NoTypeInformation c:\Temp\ReviewGroups.csv

But if we want to restore the original sensitivity label, we can use code like that shown below to list the set of containers with replacement labels and prompt to revert. If a positive answer is given, we reapply the label GUID stored in CustomAttribute14 (Figure 1).

If (!($ReviewGroups)) {Write-Host "All good. No label mismatches discovered"; break}

Clear-Host
$ReviewGroups | Format-Table Group, OldLabel, NewLabel, Status -AutoSize
$PromptTitle = 'Restore original sensitivity label to groups'
$PromptMessage = 'Please confirm whether to go ahead and restore the original sensitivity label to these groups'
$yes = New-Object System.Management.Automation.Host.ChoiceDescription "&yes", 'yes?'
$no = New-Object System.Management.Automation.Host.ChoiceDescription "&no", 'no?'
$cancel = New-Object System.Management.Automation.Host.ChoiceDescription "&cancel", 'Exit'
$PromptOptions = [System.Management.Automation.Host.ChoiceDescription[]]($yes, $no, $cancel)
$PromptDecision = $host.ui.PromptForChoice($PromptTitle, $PromptMessage, $PromptOptions, 0) 
$i = 0
# Decision made Y or default to go ahead and restore the labels, so let's do it.
If ($PromptDecision -eq 0) {
   ForEach ($G in $ReviewGroups) {
     Write-Host "Restoring sensitivity label to" $G.Group
     Set-UnifiedGroup -Identity $G.GroupId -SensitivityLabel $G.CustomAttribute14
     $i++ 
   }
   Write-Host "All done. Sensitivity Labels restored for $i containers" 
} Else {
   Write-Host "OK. Details of the containers are in c:\temp\ReviewGroups.csv"
   $ReviewGroups | Export-CSV -NoTypeInformation c:\temp\ReviewGroups.csv 
}

Some More Work to Do

If the option to restore labels is chosen, the script restores the original labels. However, applying a label to a container only affects future behavior. It does nothing to deal with anything which happened in the past. For instance, if an owner changed the label to allow guest access and then added some guests, reapplying a label which blocks guest access does not remove the guests and they retain access to group resources until they are removed from group membership. It is therefore a good idea to include a check for guest members if labels change.

One way to approach the issue is to check the reapplied label to see if its settings allow guest access. If it doesn’t, check the count of guests in the group membership (stored in the group’s GroupExternalMemberCount property), and flag an error if this is non-zero. Optionally, you could then go ahead and remove guest members using the Remove-UnifiedGroupLinks cmdlet. All possible in a few extra lines of PowerShell.