Revoke Access for User Accounts at a Good Time

A recent question in the Facebook Office 365 Technical Discussions group covered the situation where a conditional access policy imposes a 7-day sign-in frequency. I’m not a great fan of short sign in frequencies because I think the constant nagging for authentication is very distracting for users. If you use a strong authentication method with multifactor authentication, like the Microsoft authenticator app, a more relaxed regime is often justified. Equally so, the security requirements of some organization mandate a higher security profile with more frequent authentication.

In this instance, a strong authentication method is in use (Yubiko FIDO2 keys). The problem is that the week-long sign-in period finishes at different points during the week and can disrupt users at important points in their work. My favorite example is when the CEO is preparing to join a critical Teams call with some investors and is suddenly prompted to reauthenticate. Computer systems have no mercy or appreciation of when people don’t need to be disturbed. All that Entra ID knows is that the 7-day period is up, and the user must reauthenticate.

The ask is therefore how to force reauthentication at a suitable point during the working week, like early on Monday morning. If everyone starts the week off by authenticating, Entra ID won’t bother them until the following Monday.

Azure Automation Runbook to Revoke User Sessions

After thinking about the problem, the simplest solution seems to be to revoke user tokens early every Monday morning. The easiest way to do this is with a PowerShell script that runs as a scheduled task. My preference is always to use Azure Automation for scheduled tasks. Many people like to use the Windows Scheduler to run PowerShell scripts, but I think that Azure Automation is a much better and more secure option.

The outline of the solution is as follows: The PowerShell code to revoke access from user accounts executes as a runbook belonging to an Azure Automation account. To process runbooks, you need an Azure automation account associated with an Azure account with a paid-for subscription.

The code uses cmdlets from the Microsoft Graph PowerShell. The modules containing the cmdlets must be loaded as resources in the automation account. The modules are:

Microsoft.Graph.Authentication

Microsoft.Graph.Users

Microsoft.Graph.Users.Actions

Microsoft.Graph.Groups

The automation account uses a managed identity to connect to the Microsoft Graph. To process the user accounts, the automation account must have consent to use the Users.ReadWrite.All and User.RevokeSessions.All application permissions. This article explains how to assign permissions to automation accounts. The automation account must also hold at least the User administrator role.

After authenticating, the runbook finds the set of target accounts to process. If access is to be revoked for every account, the Get-MgUser cmdlet can retrieve the accounts. To avoid the potential of locking everyone out of the tenant, I use a group to identify the set of accounts (a dynamic group would be a good choice), so the Get-MgGroupMember cmdlet fetches the set of accounts to process.

Revoking User Sessions

For each account, the Revoke-MgUserSignInSession cmdlet revokes access and forces the user to reauthenticate. Here’s the code:

Connect-MgGraph -Identity -NoWelcome
# Get users to process
[array]$Users = Get-MgGroupMember -GroupId bdae941b-389d-4972-a78a-9ef2b7dc4c7a -All

ForEach ($User in $Users) {
$RevokeStatus = Revoke-MgUserSignInSession -UserId $User.Id
If ($RevokeStatus.Value -eq $true) {
Write-Output (“Access revoked for user {0}” -f $User.additionalProperties.displayName)
}
}

Test the code in Azure automation to make sure that everything works (Figure 1). Also make sure that the effect of revoking sessions for user accounts has the desired effect.

Scheduling the Revoke Runbook

When the code runs as expected, publish the runbook and link it to a schedule in the automation account. If an appropriate schedule isn’t available, you’ll need to create one. Figure 2 shows a schedule to execute linked runbooks at 7:00 every Monday.

Everything Worked as Expected

Everything worked as expected for me. Entra ID terminated user sessions to force the users to reauthenticate. The scheduled job made sure that the process happened every Monday morning to allow people to work for the entire week without Entra ID demanding their credentials. If you’re going to look for frequent reauthentication, I guess you should minimize the pain.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.