Table of Contents
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.
My view is that trusted devices in the company are trusted (when compliant) and by them self provides strong authentication. Strong reauthentication happens often automatically. Example: WHFB, MAC Os platform sso. Mobile Devices must also be compliant. We only trust known company devices. BUT: Unknown devices are not to be trusted and reauthentication is rampid (only a few hours token lifetime and never persistent). Adding reauthentication once pr week seams not necessary to me.
I tend to agree with you. However, I work with two large software companies, one of which insists on a CA policy that forces reauthentication (MFA) for guest accounts every three days. The other takes a more relaxed view and forces reauthentication for guest accounts using a much longer interval (many months). Who’s right? The point is that each organization must make their own minds up how to protect themselves. In this instance, the decision was to use a CA policy with a 7-day sign in frequency. Is that justified? Maybe not in your organization, but maybe so in others.
Definitely better to use a Runbook over a script on the server. But you are still giving it significant access and increasing the attack surface of your environment. Much better to work in the limitations of conditional access and convince you client to adopt a solution that is native than introducing this in my view.
So what conditional access settings (apart from a 7-day sign in frequency) would you recommend?
The difficulty is to align the start of the sign-in period to a single point to ensure that users are not interrupted in the middle of their work. I appreciate the value of this point because I constantly find that I have to reauthenticate just before an important Teams meeting or other event… I don’t know a way of forcing authentication at a specific time with a CA policy (otherwise I would have said so).
And I don’t know why a runbook which uses a managed identity increases the attack surface of the environment. If that was the case, would you ever use a runbook?
To meet your objective you could set it to 5 days to account for most people’s working week, so assume a user logs in Monday at 9AM then they would expire on Saturday morning. Of course there would be edge cases where sessions are established later in the week or over the weekend, but this will be less frequently disruptive than 7 days.
But IMO, as per previous commentors reccomendation if you should probably have have no policy for devices on Windows Hello for Business, just make sure the screens lock automatically when unattended. And a policy for untrusted devices only which is enforced to a single day’s work, say 12 hours and non-persist browser sessions as well. I agree re: sign-in fatigue is an issue, but once a day is not too onerous.
This of course assumes users are either using managed devices or registered devices where a PRT is established on the device and authentication is seamless between applications. If this is not the case then signing into multiple different applications each day could be onerous. If there is no PRT for whatever reason, in my opinion it would be better to tackle seamless sign-on to avoid authentication fatigue.
I’m not sure that a five day SIF will work. There’s just too many instances where that five-day period won’t align with the working week.
I’m with you in terms of securing devices…
Please don’t assume that I advocate that anything explained in an article is a perfect solution. The idea is to respond to questions and to encourage people to think about the best way to meet requirements advanced by the business. And as we all know, some of those requirements can be pretty odd.