How to Block User Access to Microsoft 365 Accounts

Multiple Techniques Available to Stop People Connecting

Updated 20-Feb-2024

A recent article about using PowerShell to control Entra ID conditional access policies caused me to start thinking about the techniques used to block user access to Office 365. Four years ago, I considered the problem in a Petri.com article inspired by a French law to allow people to disconnect over the weekend. In places other than France, the need to preserve space between personal and work time became more evident as the Covid-19 pandemic forced many people to work from home. Some worked more, some worked less, and the line between personal and work time blurred. Now, the advance of time and development in technology combine to make it reasonable to revisit the problem.

Update: Microsoft has implemented continual access evaluation (CAE) for critical events like password changes or account blocks in all tenants. The net effect of CAE is that depriving user access to an account works much faster (almost immediately).

Stopping Email Connections Temporarily or Permanently

The issue of disabling service to users isn’t just about stopping people working over the weekend or when they are on vacation. It also applies when people leave a company. Over the years, different techniques have evolved, originally for email connectivity because that’s where the problem first surfaced.

Because Exchange Online supports a rich set of connectivity protocols for mailboxes, you can disable individual protocols by running the Set-CASMailbox cmdlet. In this example, we disable mobile connectivity for a mailbox for both Exchange ActiveSync (EAS) and the Microsoft sync technology used by Outlook mobile:

Set-CASMailbox -Identity Ken.Bowers@Office365itpros.com -ActiveSyncEnabled:$False
Set-CASMailbox -Identity Ken.Bowers@Office365itpros.com -OutlookMobileEnabled:$False

Why disable both protocols? Outlook mobile uses the Microsoft sync technology to enable many advanced features like delegate access to mailboxes, but other clients like the mail apps included in the iOS and Android operating systems use EAS for basic email connectivity with Exchange Online. If you don’t disable both, you create a situation where a user can still connect to their mailbox with a different app. In fact, for completeness, you should also disable the IMAP4 and POP3 protocols to close off any chance that a mobile device can connect to a mailbox.

The weakness of concentrating on disabling protocols is that some information leakage can still occur. Take the example of Outlook mobile. You can disable the Microsoft sync technology to stop clients sending messages and downloading messages to the device, but both iOS and Android use services to notify users of the arrival of new messages. The notifications contain snippets about new messages to allow users to decide if they need to read the full message. These notifications keep on arriving after you disable the sync protocol.

In reality, if you’re serious about controlling mobile devices, you need to deploy a mobile device management (MDM) solution like Intune which allows you to remote wipe corporate data from the device when necessary.

Stopping Access to Office 365

Email is not the only app which steals time over the weekend. Teams, Planner, Yammer, SharePoint Online, and OneDrive for Business all consume hours if people allow. The classic method to block access is to block someone’s account. This can be done through the Microsoft 365 admin center by selecting the account and choosing Block sign-in (Figure 1).

Blocking the account sets the AccountEnabled property to False. When an account is disabled, the user cannot sign into their account:

Forcing Sign-Outs from Apps

Blocking an account from signing in also sets the RefreshTokensValidFromDateTime property for the account to the date and time the action occurred. The effect is to invalidate the refresh tokens issued to applications for a user and tokens issued to session cookies in browsers and forces the user to reauthenticate to continue using the apps. The Microsoft 365 admin center includes an option to sign a user out of all sessions, so you can do this without blocking an account.

You can also force a sign-out for an account with PowerShell by running the Revoke-MgUserSignInSession cmdlet:

$RevokeStatus = Revoke-MgUserSignInSession -UserId $User.Id

Resetting sign-ins for an account sets RefreshTokensValidFromDateTime to the current date and time and AccountEnabled to True. The user can now sign in. When this happens, browsers and apps receive new valid tokens. It can take up to 15 minutes before the user can sign into all apps.

Blocking Accounts with PowerShell

The Update-MgUser cmdlet blocks access to a user account:

Update-MgUser -UserId 'Ken.Bowers@office365itpros.com' -AccountEnabled:$False

The recommended approach is to run Update-MgUser to block the account followed by Revoke-MgUserSignInSession to ensure the account is blocked with a forced sign-out for all apps.

Implementing a Weekend Block

Coming back to the original issue, which is how to disconnect people from Microsoft 365 for one reason or another. Let’s assume that we only want this to happen for a certain category of user, such as those who work in a specific country. If those people are members of a group, we can use that group to drive the disconnect process. In this example, a distribution list defines the accounts to disconnect:

[Array]$Accounts = Get-DistributionGroupMember -Identity "BlockWeekend" | Select WindowsLiveID, ExternalDirectoryObjectId

ForEach ($Account in $Accounts) {
   Write-Host "Turning Off Office 365 Access for" $Account.WindowsLiveID
   Update-MgUser -UserId $Account.ExternalDirectoryObjectId -AccountEnabled:$False
   $RevokeStatus = Revoke-MgUserSignInSession -UserId $Account.ExternalDirectoryObjectId  }

A dynamic distribution list might be a better choice because the membership is then driven by properties such as country or city. To fetch the set of users of a dynamic distribution list, we use the recipient filter for the list to find the members:

$AccountFilter = (Get-DynamicDistributionGroup -Identity "French Country Users").RecipientFilter
[Array]$Accounts = Get-Recipient -RecipientPreviewFilter $AccountFilter | Select-Object WindowsLiveID, ExternalDirectoryObjectId

Of course, you can use the Get-MgGroupMember cmdlet to fetch details of group members if you prefer. For example:

[array]$GroupId = (Get-MgGroup Filter "DisplayName eq 'BlockWeekend'").Id
[array]$GroupMembers = Get-MgGroupMember -GroupId $GroupId | Select-Object additionalProperties
$GroupMembers.displayName

This syntax works with distribution lists, security groups, Microsoft 365 groups, and dynamic Microsoft 365 groups. It doesn’t work with dynamic distribution lists because these objects don’t exist in Entra ID

The task to disconnect users is straightforward. Every Friday night, we run the PowerShell script to disable access and run another script to reverse the process on Monday morning. The big downside is the way Teams processes blocked accounts to remove them from team rosters (without affecting the group membership). If you can live with this issue while Microsoft considers how to improve the situation, then blocking accounts for short periods might work for your organization.

Using a Conditional Access Policy

Conditional access policies run after a user successfully authenticates to decide whether they can connect to the requested resource. Membership of a group is one of the supported conditions, meaning that it is easy to create a policy to block access to apps for a group. Because it’s weekend access we want to block, we could add another condition to say that access is OK if the user is in a corporate location, but not if they are at home or anywhere else.

Figure 3 shows the outlines of such a policy. Anyone specified in the Blocked Weekend distribution list (you can also use a security group or Microsoft 365 group) is blocked if they attempt to access an Office 365 app:

When a user attempt to access an app is blocked by a conditional access policy, they are told that their sign in was successful (authentication worked), but they don’t have permission to access the resource:

If they are already connected to an app and the app attempts to renew its access token, the conditional access policy will block issuance of the token. Figure 5 shows what the user sees when this happens in Teams (the app is very polite!):

Controlling Conditional Access Policies with PowerShell

Conditional access policies allow organizations to exert granular control over the access users have to apps. In our scenario, we want to allow free access during the week. We could disable the conditional access policy during the working week and enable it just for the weekend. This is easily done by editing the policy in the Entra admin center or with PowerShell. For example, here’s how to enable the policy:

$Policy = Get-MgIdentityConditionalAccessPolicy -Filter "displayName eq 'Block Weekend Access'"

Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $Policy.Id -State 'Enabled'

To disable the policy after the weekend, run:

Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $Policy.Id -State 'Disabled'

Changing Conditional Access Policy Conditions

But because we want to illustrate the possibilities which exist to work with conditional access policies through PowerShell, let’s assume that the policy is always active because it’s used during the week to limit access for some users (identified by a group) to certain locations. Over the weekend, we need to update the policy with a different group.

The users blocked by a conditional access policy is defined as a policy condition. To see what users are affected by a policy, we can examine its conditions. Here we see that a single group is included in the policy:

((Get-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $PolicyId).Conditions).Users | Format-List

IncludeUsers  : {}
ExcludeUsers  : {}
IncludeGroups : {468a9356-cf88-4189-bf85-40b096e3c37f}
ExcludeGroups : {}
IncludeRoles  : {}
ExcludeRoles  : {}

We know this is a group rather than an individual user because it’s listed in the IncludeGroups condition. The group is referenced by its unique identifier (a GUID). To find out which group is listed, run the Get-MgGroup cmdlet:

Get-MgGroup -GroupId 468a9356-cf88-4189-bf85-40b096e3c37f

DisplayName                      Id                                   MailNickname Description GroupTypes
-----------                      --                                   ------------ ----------- ----------
Users Blocked for Weekend Access 468a9356-cf88-4189-bf85-40b096e3c37f BlockWeekend             {}

To switch out one group for another in a policy, we need to create a hash table specifying the group identifier of the group to include in the policy and then call the Update-MgConditionalAccessPolicy cmdlet to make the change.

Here’s an example of code to update our conditional access policy. You can see that the GUID for a different group is written into the condition set:

# Update the policy with a new group
$UpdateSettings = @{
    Conditions = @{
        users = @{  
            includeGroups = @(
                "5c011293-7cc7-41c4-a0fc-3e3bb98db834"
            )
        }
    }
}
Update-MgIdentityConditionalAccessPolicy -BodyParameter $UpdateSettings -ConditionalAccessPolicyId $Policy.Id

Within a few minutes, the updated conditional access policy is effective, and the block is in place.

To reverse the process after the weekend is over, update the policy with the GUID for the original group. See this article for more information about managing conditional access policies with PowerShell.

Options and Choices

Conditional access policies require Entra ID P1 licenses. If you’ve already got these licenses, and therefore have invested in conditional access, adding a new policy to control weekend access is not difficult. Being able to control the policies with PowerShell makes it easier to automate switching access on or off on automatic basis.

On the other hand, if you don’t have Entra ID P1 licenses, you can still block user accounts with a few lines of PowerShell. And if you don’t want to block access and simply remind people that they should do less work at the weekend, maybe the technique of using a transport rule to stamp “right to disconnect” disclaimers on internal mail is a good way to go.

Choice is nice…