What Happens When You Block a Microsoft 365 Account?

Blocking a Microsoft 365 account is commonly used to stop access to an account when someone leaves the organization or when an administrator suspects that attackers have compromised an account. Blocking an account has other uses, such as temporarily making an account unavailable when a person goes on extended vacation. Blocked accounts retain their assigned licenses. It’s therefore reasonable to expect that the account remains functional.

Two methods exist to block an account. You can edit the account settings in the Microsoft 365 admin center and choose to block sign-in to the account (Figure 1) or you can run the Set-AzureADUser cmdlet to set the AccountEnabled property to False.

Blocking a user account in the Microsoft 365 admin center
Figure 1: Blocking a user account in the Microsoft 365 admin center

Using the admin center or PowerShell has the same effect. The user’s Azure AD account is blocked from further sign-ins together with a reset for the validity of refresh tokens for the account to force applications connected to the account to sign out once their current access tokens expire. This process can take up to an hour to complete. If the user has an Exchange Online mailbox, the account disabled status is also updated there. When everything is done, no one can sign into the account until the block is lifted.

Auditing Account Blocks

Azure AD captures audit records when an account is blocked (Figure 2). We can see the action to disable the account followed by actions to invalidate refresh tokens and update the properties of the account.

Audit records in the Azure AD log captured when an account is disabled
Figure 2: Audit records in the Azure AD log captured when an account is disabled

These audit records flow through from Azure AD to the Office 365 audit log and can be seen there by running the Search-UnifiedAuditLog cmdlet or the Audit search in the Compliance Center.

The Impact of Blocking on Teams

In this case, the blocked account is a Teams user. Figure 3 shows the teams available to the user before blocking their account. Two are “standard” teams where the membership is controlled by the team owner; the other four are org-wide teams where a Teams background process controls the membership.

Teams as accessed by the user before disabling their account
Figure 3: Teams as accessed by the user before disabling their account

The account was unblocked at 21:20 (local time) on 13 April. When the user accessed Teams twelve hours later, their teams list was empty (Figure 4).

No teams available twelve hours after unblocking an account
Figure 4: No teams available twelve hours after unblocking an account

After 24 hours, the standard teams reappeared in the user’s teams list (Figure 5). No sign was visible of the org-wide teams (a week later, Teams has still not readded the user to the org-wide teams).

Standard teams reappear but no sign of org-wide teams
Figure 5: Standard teams reappear but no sign of org-wide teams

Investigating What Happened

The Office 365 audit log ingests records from many different workloads, including Azure AD and Teams. It is therefore a good place to start when looking for answers about what happened to an object. Here’s the search I used and what I found:

$Records = Search-UnifiedAuditlog -StartDate "12-Apr-2021 11:03" -EndDate "15-Apr-2021 19:00"-Formatted -ResultSize 5000 -Operations "Update user", "Disable account", "Set-Mailbox", "Update StsRefreshTokenValidFrom Timestamp", "Remove member from group", "MemberRemoved", "Add member to group", "MemberAdded"

$Records |Format-Table CreationDate, Operations, UserIds

CreationDate        Operations                                 UserIds
------------        ----------                                 -------
14/04/2021 19:05:14 MemberAdded                                Administrator@
14/04/2021 19:05:12 MemberAdded                                Tony.Redmond@
13/04/2021 20:20:23 Set-Mailbox.                               Tony.Redmond@
13/04/2021 20:20:21 Update StsRefreshTokenValidFrom Timestamp. Tony.Redmond@
13/04/2021 20:20:21 Update user.                               Tony.Redmond@
13/04/2021 20:20:21 Update user.                               Tony.Redmond@ 
13/04/2021 19:04:35 MemberRemoved                              Tony.Redmond@
13/04/2021 19:04:26 MemberRemoved                              Tony.Redmond@
13/04/2021 19:04:20 MemberRemoved                              Tony.Redmond@
13/04/2021 19:04:09 MemberRemoved                              Tony.Redmond@
13/04/2021 19:04:01 MemberRemoved                              Tony.Redmond@
13/04/2021 19:03:40 MemberRemoved                              Tony.Redmond@
13/04/2021 19:03:32 Remove member from group.                  ServicePrincipal_bb1ef4a0-a422-482e-b529-df389d32ae55
13/04/2021 19:03:31 Remove member from group.                  ServicePrincipal_bb1ef4a0-a422-482e-b529-df389d32ae55
13/04/2021 19:03:30 Remove member from group.                  ServicePrincipal_bb1ef4a0-a422-482e-b529-df389d32ae55
13/04/2021 19:03:29 Remove member from group.                  ServicePrincipal_bb1ef4a0-a422-482e-b529-df389d32ae55
12/04/2021 11:05:00 Set-Mailbox                                Tony.Redmond@
12/04/2021 11:04:42 Update user.                               Tony.Redmond@
12/04/2021 11:04:42 Update user.                               Tony.Redmond@
12/04/2021 11:04:42 Update StsRefreshTokenValidFrom Timestamp. 
12/04/2021 11:04:42 Disable account.                           Tony.Redmond

The timeline (from the bottom) is:

  • 12-April 11:04 (UTC) Account blocked. Audit records captured for Disable account, Update StsRefreshTokenValidFrom Timestamp, Update user (x2 to record new token refresh time and that AccountEnabled is now False), and Set-Mailbox (mailbox records account disablement).
  • 13-April 19:03 (UTC) Account is removed from Azure AD Groups: Capture of four Remove member from group audit events from Azure AD to record that ServicePrincipal_bb1ef4a0-a422-482e-b529-df389d32ae55 (a service principal registered to Microsoft Teams) removed the blocked account from the org-wide teams. This is expected behavior as disabled accounts lose access to automatic membership like org-wide teams and dynamic groups. Teams does not remove accounts from the membership of Azure AD groups for standard teams.
  • 13-April 19:04 (UTC) Account is removed from Teams: Capture of six MemberRemoved audit events from Microsoft Teams. Each event records the removal of the blocked account from one team (the four org-wide and two standard teams). Teams also captures this event when it removes a user from the membership of a private channel. Oddly, the audit event records that a user account performed the removal. This appears to be because the recorded account is the first registered owner for the team from which the account is removed.
  • 13 April 20:20 (UTC) Account is unblocked: Capture of Update User audit records to note the update to the STS access token and AccountEnabled property for the Azure AD account plus Set-Mailbox to reflect the update to the Exchange Online mailbox.
  • 14 April 19:05 (UTC) Teams restores standard team memberships: Ten hours and 45 minutes after unblocking the account, the audit log records the capture of two MemberAdded audit events when Teams restores the unblocked account to the membership of the two standard teams. Note the continued anomaly of including team owner names as the people responsible for the action (in both cases, the user captured in the audit record is the first listed owner for the corresponding team). To compound the error, teams also signals that the selected owner removed or added the user in the team’s information panel.

As noted above, the org-wide teams remain missing a full week after unblocking the account. The delay is likely because a separate background process deals with the membership of org-wide teams. Even if an explanation exists, it’s an unconscionable delay.

Teams Actions for Blocked Accounts

In summary, it seems like when a user account is disabled (but still licensed), a Teams background process (perhaps the policy evaluation service used by information barriers to ensure that team members do not violate policies) removes the account from team memberships. This process can happen within hours of an account being blocked; it can also take much longer.

It is reasonable for Teams to remove disabled accounts from org-wide teams. It’s also logical that Azure AD excludes disabled accounts when it calculates the membership of dynamic groups. Why anyone thinks it is a good idea and necessary for Teams to remove disabled accounts from the memberships of regular teams while leaving the account as a member of the underlying Microsoft 365 groups is inexplicable. Team owners usually have reasons and context when they decide to remove a member, but an automated process has no conception or understanding of why an account is disabled and therefore no idea if it is good or bad to remove the account.

What’s also troubling is the delay which occurs before Teams restores unblocked accounts to the membership of normal teams allied to an even worse delay to add the accounts back to org-wide teams. No other workload prevents a user from working after their account is unblocked. And making the audit records seem as if team owners added and removed members is simply bizarre. A Teams background process performed these actions; the audit records should capture that fact.

Effects on User Accounts

Now that we know what happens when Teams encounters blocked accounts, let’s consider the effect of the actions taken by Teams.

  • The user loses access to teams for an unpredictable lengthy period following an account unblock while waiting for a background process to fire and restore their membership of standard teams. Org-wide team membership
  • Removing a user from a team also removes them from membership of any private channels in that team. The process to add the account back to the team does not restore private channel membership.
  • The process does not add any tags previously assigned to the account.
  • Unblocked users can show up as “unknown user” in conversations and chats.
  • Attempts to chat with blocked accounts can show that the user is available through Skype rather than Teams.
  • If a user is leaving the company and some sensitivity exists around their departure, it does not help the organization when people notice that the person’s account has suddenly disappeared from Teams, apparently removed by the team owners.

This problem is not new. Teams has insisted on removing blocked users from memberships for a few years, back to around the time when Microsoft first introduced support for information barrier policies for Teams. I don’t know if the two facts are connected, but coincidences are often suspicious when they occur in IT systems.

Teams Leave My Accounts Alone!

The bottom line is that Teams shouldn’t remove blocked accounts from team memberships. That decision should be left to tenant administrators and team owners. This is an example of unwanted automated management gone mad. Microsoft needs to step up and change this aspect of Teams management.

About the Author

Tony Redmond

Tony Redmond has written thousands of articles about Microsoft technology since 1996. He is the lead author for the Office 365 for IT Pros eBook, the only book covering Office 365 that is updated monthly to keep pace with change in the cloud. Apart from contributing to Practical365.com, Tony also writes at Office365itpros.com to support the development of the eBook. He has been a Microsoft MVP since 2004.

Comments

  1. Eric Weintraub

    Solid write up Tony, these kind of reverse engineering explorations are key to being effective as a modern Microsoft IT Administrator these days. Its a shame these processes arent better documented by Microsoft directly. IT Admins can manage just about anything but being an IT Admin in modern times is like tight rope walking blindfolded. Put another way, they shouldn’t call it the cloud, they should call it the “fog”.

  2. Quinten365

    This reminds me of an additional annoyance.
    I use custom app policies for distributing Teams Apps to a set of users to test and fiddle with them before they get deployed to all users.

    When a user is assigned this custom policy, and then this user is disabled, the user can no longer be found in the Teams admin center, yet the policy is still assigned to that user.
    This makes it so that you are unable to delete that custom / temporary policy until the user is enabled.
    Then the user is visible in Teams admin and an be removed from the policy whereafter you can remove the policy.

    not major blocking or anything, just something annoying I stumbled uppon once.

  3. McSmartypants

    Quick’n’dirty workaround: set users password to a random string and tick “User cannot change password”? This will leave the account open, block sign-ins and leave everything else intact.

    1. Tony Redmond

      Good suggestion. One issue is that if an account is then unblocked, the user will be forced to change their password. Not a biggie.

  4. Andreas

    Oh, that’s a big yikes!

Leave a Reply