How to Apply Container Management Labels to Existing Teams

Taking Advantage of Container Management Labels to Manage Teams

Last year, I suggested that sensitivity labels are a good way to help secure Teams. My logic is simple: applying a sensitivity label to a team enforces the policy settings from the label such as whether guests can be added to the team membership or what kind of external sharing is allowed. Although team owners can change an assigned sensitivity label, it’s possible to monitor these changes and reapply the original label.

It’s easy to make sure that new teams receive sensitivity labels. The question recently arose about how to deploy container management labels to an existing set of teams. This requires more effort because each team must be assessed to decide which label is most appropriate.

Thinking about the steps to do this in a PowerShell script, the following major steps are needed:

1. Find the set of teams that don’t have a sensitivity label.
2. Find the set of container management labels defined in the tenant.
3. Build rules to decide which label is best for a team.
4. Apply the labels.

Steps 1, 2, and 4 are relatively straightforward in terms of the PowerShell code. Step 3 is highly dependent on the organization because the rules will vary so much from tenant to tenant. In this article, I use some simple rules to illustrate the principle.

Find Teams with No Label

First, let’s find the set of teams that don’t have a sensitivity label. Because we can easily filter for sensitivity labels, we use the Get-UnifiedGroup cmdlet from the Exchange Online management module. Here’s the code to find if any teams are missing a sensitivity label:

Connect-ExchangeOnline
[array]$Teams = Get-UnifiedGroup -Filter {ResourceProvisioningOptions -eq "Team"} -ResultSize Unlimited | Where-Object {$_.SensitivityLabel -eq $Null}
If (!($Teams)) { 
   Write-Host "Congratulations! All your teams have sensitivity labels" 
} Else {
   Write-Host ("{0} teams do not have sensitivity labels - progressing" -f $Teams.count) }

Find Container Management Labels

Next, we want to find the set of sensitivity labels configured for container management. To do this, we connect to the compliance endpoint using the Connect-IPPSSession cmdlet and use the Get-Label cmdlet to find the full set of labels. Not every label is used for container management, so this code loops through the set to filter out any used exclusively for information protection (to encrypt Office documents and PDF files). The output is a hash table.

Connect-IPPSSession
Write-Host "Finding container management labels"
[array]$Labels = Get-Label
$ContainerLabels = @{} 
ForEach ($Label in $Labels) { 
    If ($Label.ContentType -Like "*UnifiedGroup*") { # It's a label for container management
        $ContainerLabels.Add([String]$Label.DisplayName, $Label.ImmutableId) }
}
[array]$OutputLabelNames = $Null
$ContainerLabels.GetEnumerator() | ForEach-Object{ $OutputLabelNames += $_.Key }
$Output = $OutputLabelNames -Join ", "
Write-Output ("These labels support container management: {0}" -f $Output)
These labels support container management: Non-business use, Guest Access, Limited Access, General Access, Confidential Access

Rules for Applying Labels

The most difficult part of the process is to assess the characteristics of each team to decide which container management label is most appropriate. To do this, we define some rules

First, let’s set a default label to assign if no other test determines a better label. Sensitivity labels have a priority order from 0 (least important). The set of labels extracted by Get-Label is ordered by priority. Assuming that the first label is the least restrictive, it seems sensible to use it as a default. In my tenant, this is a label called “Non-Business Use.” Label assignments use GUIDs rather than display names, so it’s important that the code uses GUIDs to assign labels.

Obviously, any label can be the default. It’s simply a matter of selecting which one to use.

In terms of rules, these examples illustrate the principle rather than being definitive. In other words, it’s up to you to build the rules to meet the organization’s business requirements and to put them in order of evaluation.

• If the team membership includes more than ten tenant members, assume that the team should have public access and apply a label with that setting. If less, assume private and use a different label.
• Does the team membership include guests? If so, the assigned label must permit guests.
• If the group access is set to private, select the lowest priority label that sets private access.

Let’s go through the code. First, we define the label GUIDs to assign based on the rules by looking up the hash table for each selected label name.

# Set a default label to assign
$AssignedLabelId = $ContainerLabels["Non-business use"].Guid
# Set labels to use in other circumstances
$GeneralLabelId =  $ContainerLabels["General access"].Guid
$PublicGroupLabelId = $GeneralLabelId
$AllowGuestLabelId = $ContainerLabels["Guest access"].Guid
$GuestPublicId = $AllowGuestLabelId
$GuestPrivateId = $ContainerLabels["Limited access"].Guid

Assessing Teams and Applying Labels

Now let’s create some rules in PowerShell. Remember, there’s nothing sophisticated or complicated here. The idea is to illustrate how to come to a decision about which sensitivity label to apply. The code loops through each team, assesses different characteristics, decides on a label, and runs the Set-UnifiedGroup cmdlet to apply the label.

ForEach ($Team in $Teams) {
  Write-Host "Processing team" $Team.DisplayName
  $InternalMembers = ($Team.GroupMemberCount - $Team.GroupExternalMemberCount)
  # More than ten tenant users = public access
  If ($InternalMembers -ge 10) { $AssignedLabelId = $PublicGroupLabelId }
  # Does the group include guests?
  If ($Team.GroupExternalMemberCount -gt 0) { $AssignedLabelId = $AllowGuestLabelId }
  # Private or public?
  If ($Team.AccessType -eq "Public" -and $Team.GroupExternalMemberCount -gt 0) {
     $AssignedLabelId = $GuestPublicId 
  } ElseIf ($Team.AccessType -eq "Private" -and $Team.GroupExternalMemberCount -gt 0)  {
     $AssignedLabelId = $GuestPrivateId }
 Write-Host ("Assigning sensitivity label {0} to team" -f $AssignedLabelId)
 Set-UnifiedGroup -Identity $Team.ExternalDirectoryObjectId -SensitivityLabelId $AssignedLabelId
}

The dual-write mechanism used by Exchange Online and Azure AD makes sure that the Azure AD group receives the new label immediately. Synchronization to other workloads takes longer, and it might take up to a day before Teams clients reflect the newly-assigned labels. SharePoint Online can take even longer. It all depends on when background synchronization jobs run to update workload-specific caches. Eventually, the newly assigned label will show up in Teams (Figure 1), and the team will respect the container management settings from the label.

Keep Checking for Missing Labels

Even if sensitivity label policies dictate that new teams receive a sensitivity label, it’s possible to create a new team programmatically without assigning a label. For that reason, it’s worthwhile running a periodic check to ensure that labels are in place for all teams. This is a good example of the kind of task that a scheduled Azure Automation runbook (script) handles very nicely. As mentioned earlier, team owners can change assigned labels, so you might also want to run a periodic check for those updates too.