Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierFlux principal

Reducing the Likelihood of Token Theft with Conditional Access Policies

New Token Protection Conditional Access Policy Session Control

Now that the removal of basic authentication from Exchange Online has made password spray attacks far less likely to compromise user credentials for an Azure AD account, those who want to sneak into a tenant need another avenue to explore. Microsoft’s Detection and Response Team (DART) reports an increase in adversary-in-the-middle phishing attacks where attempts are made to capture user credentials and the tokens used by applications to access protected resources like user mailboxes or SharePoint Online sites.

If you need further evidence of the techniques used to compromise and exploit tokens, this article by Edwin David is a good read. It’s a reminder that although all Azure AD accounts should be protected by multi-factor authentication, MFA is not a silver bullet and attackers will continue to develop methods to work around barriers erected by tenants.

Token Binding to Devices

Which brings me to a new session control for Azure AD conditional access policies designed to protect sign-in tokens (refresh tokens) using token protection. The control, which has just appeared in preview, creates a “cryptographically secure tie” between the token and the device Azure AD issues the token to (aka token binding). Without the client secret (the device), the token is useless to an attacker. The device needs to run Windows 10 or above and be Azure AD joined, hybrid Azure AD joined, or registered in Azure AD. When this is the case, a user’s identity is bound to the device.

Microsoft notes that “Token theft is thought to be a relatively rare event, but the damage from it can be significant.” One interpretation of this statement is that Microsoft knows the bad guys are working on using more token thefts, so they’re investing to get ahead of the curve.

Clients

It’s a preview, so some limitations are inevitable. For instance, conditional access policies with token protection can only process connections from tenant accounts and can’t handle inbound connections from guest accounts. Token protection supports Microsoft 365 apps for enterprise subscription versions of desktop clients accessing Exchange Online and SharePoint Online. Perpetual versions of the Office apps aren’t supported. The apps include the OneDrive sync client (22.217 or later) and the Teams desktop client (1.6.00.1331 or later). These are relatively old versions already, so meeting the software requirements should not be a big issue.

PowerShell clients accessing Exchange Online, SharePoint Online, or these endpoints via the Microsoft Graph APIs are unsupported by conditional access policies with token protection, meaning that users are blocked from accessing Exchange and SharePoint. The same is true for some other apps like Visual Studio and the Power BI desktop app. It also applies to connections generated using OWA and Outlook mobile.

In effect, the users selected to test a token protection condition access policy (Figure 1) should be those who don’t need to use any of the unsupported clients and are happy to limit their access to Outlook desktop and Teams.

Parts of a conditional access policy with token protection
Figure 1: Parts of a conditional access policy with token protection

Users who don’t meet the policy requirements (like attempting to sign in with OWA, the browser version of Teams, or the SharePoint Online or OneDrive for Business browser clients) will fail to connect (Figure 2).

Token protection stops an app connecting
Figure 2: Token protection stops an app connecting

In fact, any Office browser app that connects to Exchange or SharePoint resources will be inaccessible. For instance, Viva Engage (Yammer) will start up before immediately exiting when the client attempts to access SharePoint Online.

A Pointer to the Future

Given the relative lack of support by Microsoft 365 apps for token protection, this preview feature is unlikely to get the same range of testing as other recent extensions to conditional access policies (like authentication strength). That being said, if token theft becomes as biga  problem as some security commentators think it might, it will be good to have methods like token protection ready to repel the threat.


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.

Pragmatic and Practical Security is Better than Hard-line Security

An Unreasonable Azure AD Sign-in Frequency Creates a Barrier to Productivity

I had an unpleasant surprise this week when the security team for one of the companies where I have a guest account decided to improve tenant security. I strongly support any effort to improve tenant security, especially when the effort means better use of multi-factor authentication. It’s a topic I’ll cover during the TEC Europe 2023 tour in London, Paris, and Frankfurt in April. Registration for those events is now open.

It’s always important to take a pragmatic and practical view of security and not to implement anything that has a significant impact on user productivity. All change can impact users, but most of the time people learn to live with change and it’s not disruptive. Unfortunately, deciding to increase the user sign-in frequency for Azure AD accounts can be extraordinarily disruptive if you go too far.

Azure AD sign-in frequency is the period before a user must sign in again when attempting to access a resource, like opening a SharePoint Online document, creating a message with OWA, or accessing a Teams channel. By default, Azure AD uses a rolling 90-day window for its sign-in frequency. In other words, once you successfully sign-into a tenant, Azure AD won’t ask you to sign-in again for another 90 days.

Revoking User Account Access

Ninety days sounds like a long time, and it is. But this period needs to be viewed through the prism of how Azure AD and Microsoft 365 applications work. For example, in early 2022, Microsoft enabled Continuous Access Evaluation (CAE) for all tenants. CAE is a mechanism that allows Azure AD to notify applications of a critical change in the directory, such as an updated password. Applications that understand CAE, like SharePoint Online, revoke existing access for the account to require the user to reauthenticate.

The Microsoft 365 admin center also includes an option to sign users out of all current sessions (Figure 1) to force them to reauthenticate.

Forcing a user to sign out and reauthenticate
Figure 1: Forcing a user to sign out and reauthenticate

Of course, you might want to do more than sign a user out. In some cases, like employee departures, you might want to block future sign-ins. This is an operation that’s easily scripted with PowerShell. For example, this code:

  • Retrieves the identifier for an Azure AD user account.
  • Disables the account.
  • Sets a new password.
  • Revokes all refresh tokens.

$UserId = (Get-MgUser -UserId Lotte.Vettler@Office365itpros.com).Id
# Disable the account
Update-MgUser-UserId $UserId -AccountEnabled:$False
# Set a new password
$NewPassword = @{}
$NewPassword["Password"]= "!DoneAndDusted?"
$NewPassword["ForceChangePasswordNextSignIn"] = $True
Update-MgUser -UserId $UserId -PasswordProfile $NewPassword -AccountEnabled:$True
# Revoke refresh tokens
$Status = Invoke-MgInvalidateUserRefreshToken -UserId $UserId

It might take a little time for the full block to be effective because tokens must expire, and clients recognize the need for reauthentication, but it will happen.

How Conditional Access Can Make Guest Accounts Miserable

The reason I had a problem was that the security team updated the conditional access policies for guest users to enforce a 60-minute sign-in frequency (Figure 2). This change had a horrible effect. Guests switching to the tenant with Teams inevitably resulted in an MFA challenge. Opening a document stored in SharePoint Online or OneDrive for Business in that tenant brought an MFA challenge. My day was filled with MFA challenges, except when sending email to people in the tenant to complain about the new policy. Email isn’t affected by conditional access policies.

Setting the sign-in frequency in an Azure AD conditional access policy

Azure AD sign-in frequency for guest accounts set in a conditional access policy
Figure 2: Setting the sign-in frequency in an Azure AD conditional access policy

As Microsoft notes in their documentation, “Based on customer feedback, sign-in frequency will apply for MFA as well.” They understate the matter. Sign-in frequency does apply for MFA too.

I understand the motivation on the part of the security team. Forcing people to reauthenticate before they can access resources is a good thing. Using MFA is a good thing. Forcing MFA challenges every hour must be a brilliant change to make.

Only it isn’t. As an external person working with another company, the change made my productivity much worse, and I doubt that it added one iota to the overall security effectiveness of the tenant. The tenant did not use number matching and additional context for MFA challenges, so the constant MFA challenges were a great example of how user fatigue creeps in as I clicked and clicked again to say “yes, it’s me.” System-preferred authentication wasn’t used either, so while I used the Authenticator app, other guests might use relatively insecure SMS challenge/response.

Overall, the change made it unpleasant to work with the tenant and that’s bad. A one-hour sign-in frequency is just too rigid and strict. I don’t know of any other tenant (where I am a guest) that uses such a short frequency. Most tenants I know of use the 90-day default. Some use 7 days. The most security-conscious (before now) uses a 1-day frequency.

No Best Answer for All Tenants

In truth, I don’t know the best user sign-in frequency to use for either tenant or guest accounts. It all depends on the security posture that an organization wants to assume. But I can say that most tenants would be better off making sure that all accounts use MFA and eliminating the use of the less secure authentication methods before reducing the sign-in frequency. If you’re concerned about guest hygiene (in this case, how secure a guest account is), have a different and more restrictive conditional access policy for guest access while remembering the need to get work done through Azure B2B collaboration. And review guest accounts annually to remove unwanted and obsolete crud.

To me, bringing users along on the journey to better security is a better tactic than ramming heightened security down their throats. It’s always been that way.


So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

❌
❌