Protected Actions are a New Method to Highlight Specific Administrative Actions

Over the last year or so, Microsoft has pumped out a set of enhancements to make Azure AD conditional access policies more flexible and powerful. Changes such as token protection (to help address the threat of token theft) and authentication strength (to insist on a specific form of multi-factor authentication for a connection) are good examples of what’s going on.

The latest preview defines a set of “Protected actions” for use with conditional access. The preview associates an authentication context (previously used to mark sensitive SharePoint Online sites) with administrator actions in a conditional access policy. When active, the policy insists that administrators who wish to perform actions specified in the policy must meet specific requirements. For example, instead of satisfying a multi-factor authentication challenge with the Microsoft authenticator app, the policy might force administrator to use a FIDO2 key before Azure AD allows them to perform an action.

Limited Set of Protected Actions for Preview

For now, the preview supports seven protected actions. Three are related to named locations; four cover management of conditional access policies. The set is enough to let people understand the concept of what Microsoft is trying to do and I expect Microsoft to add more protected actions over time.

Using Protected Actions

To start, go to the Conditional Access section of the Microsoft Entra admin center and define an authentication context. The easiest way to think about an authentication context is to regard it as a tag to mark something to protect with a conditional access policy. In this case, the tag links some protected actions with a policy. When Azure AD assesses connections, it knows that anytime accounts within the scope of the policy try to perform a protected action, their connection must meet the conditions set in the policy. A tenant can define up to 25 authentication contexts to use as they wish. To test protected actions, I created an authentication context called CAPolicy.

Next, create a conditional access policy to use the new authentication context. Figure 1 shows what I used. The policy covers some selected users and specifies the newly-created authentication context. The access control requires passwordless MFA.

The next step is to add protected actions to the authentication context. Open the Roles & Admins section of the Entra admin center and select Protected actions. Select the authentication context and then add protected actions (referred to as permissions in the GUI). You only need to add a single action to make the conditional access policy effective. I chose the four actions related to conditional access policies (Figure 2).

Testing Protected Actions

Now sign in as one of the accounts within the scope of the conditional access policy without using passwordless authentication and try to amend the settings of a conditional access policy (one of the four protected actions selected above). You can amend settings like adding a new authentication context or changing the accounts and groups within the scope of the policy, but you can’t save updates to a conditional access policy through the GUI (Figure 3) or with PowerShell (using the Microsoft Graph PowerShell SDK).

If the account is enabled for multi-factor authentication and can satisfy the challenge requirements set by the policy, Azure AD displays a “click here to reauthenticate” banner to allow the user to go through “step-up authentication” and meet the requirements. In the example shown in Figure 3, the account isn’t MFA-enabled and therefore cannot authenticate in the manner set by the policy, which is why Azure AD simply disables updates.

For more information, consult the online documentation.

Solid if Limited Concept (for Now)

Protected actions is a preview, with limited capabilities due toa small set of selectable actions. However, there’s enough there to see how valuable this concept might be if Microsoft expands the set of protectable actions to cover more features available through the Microsoft Entra admin center and perhaps even the Azure admin center.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Microsoft 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.

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.

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).

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.