Configure Conditional Access Token Protection (CATP) with Conditional Access Policy (CAP)

Token protection creates secure cryptography between the token and the device it’s issued to, and without the client’s secret, the bound token is useless. When users register a Windows device and higher in Azure AD, their primary identity is bound to the device.

This connection means that any issued sign-in token is tied to the device, significantly reducing the chance of theft and replay attacks. These sign-in tokens are the session cookies in Microsoft Edge and most Microsoft product refresh tokens in this preview release.

When users sign in to Exchange Online or SharePoint Online using Windows devices, they must use a token bound to their device. Once the token is used from another device, it will be blocked.


Source: Microsoft Tech Community

More about the Token Protection and first impressions in the post attached below.

Azure AD Conditional Access Token protection (CATP) First Impressions

How to Configure CAP for Token Protection

To use token protection, you must create a CAP that requires token protection for sign-in tokens for specific services. Currently, this feature supports Exchange Online and SharePoint Online applications on Windows 10 devices and later. To configure the Token Protection policy in Azure AD Conditional Access, run the following actions:

Deployment Tips

The CAP settings that enforce token protection should be invisible when using compatible client platforms on registered devices and compatible applications. To minimize the possibility of user disruption due to the app or device incompatibility, it’s highly recommended to stick the highlights below, like in any other scenario:

  • Use a pilot group and expand over time.
  • Add friendly end-users to an enforcement policy.
  • Create a CAP in report-only mode and monitor any interruptions.
  • Move to the “ON” mode to enforce token protection when you have no interruptions.
  • Monitor interactive and non-interactive sign-in logs.
  • Analyze access behavior to cover everydayay use.

This process enables you to assess the user’s behavior and app compatibility for token protection.

Configure CAP

The following steps help create a token protection policy for Exchange Online and SharePoint Online on Windows devices only.

  • Browse to Azure AD Conditional Access.
  • Select New Policy, and under Assignments, select Users or workload identities.
    • Under Include – choose the required users or groups.
    • Under Exclude – choose Users and Groups, and pick the break-glass account.
  • Under Cloud apps or actions > Include, select Select apps. Under Select, choose the following applications:
    • Office 365 Exchange Online
    • Office 365 SharePoint Online

  • Under Conditions:
    • Under Device platforms:
      • Set Configure to Yes.
      • Include > Select device platforms > Windows.
      • Select Done.

    • Under Client apps:
      • Set Configure to Yes.
      • Under Modern authentication, clients choose Mobile apps and desktop clients.
      • Then, choose Done.

  • Under Access controls > Session, select Require token protection for sign-in sessions and select Select.
  • Confirm settings and set Enable policy to Report-only.
  • Select Save to create and enable CAP.

After confirming the settings using the report-only mode, you should enable the policy.

WARNING – CAP should only be configured for specific applications. If you choose the Office 365 application, you may have unintended failures.

Requirements

This mode supports the following settings:

  • Windows 10 devices and higher
  • Windows device joins types – Azure AD joined, hybrid Azure AD joined, or Azure AD registered.
  • OneDrive client with version 22.217 or later.
  • Microsoft Teams client version 1.6.00.1331 or later.
  • Supported application

Known limitations

  • Azure AD B2B (external users) aren’t supported and shouldn’t be included in CAP.
  • The following applications don’t support signing in using protected token flows, and users are blocked when accessing Exchange and SharePoint:
    • Power BI Desktop client.
    • PowerShell modules accessing the supported application.
    • PowerQuery extension for Excel.
    • VSCode extensions with Exchange or SharePoint access.
  • Office Perpetual clients aren’t supported.
  • The following Windows client devices aren’t supported:
    • Windows Server
    • Surface Hub

Simulate Token Theft

There are various ways to play with token theft. Like any other CAP, you should check if the security controls behave as they need. For this scenario, we can check with the TokenTactics tool. In this post, the simulation action will be simple and go like this:

Generate Device Code with AzureToken. Once the user has logged in, you’ll be presented with the JWT, and it will be saved in the $response variable. To access the token, use $response.access_token to display the token. You might display the refresh token with $response.refresh_token.

Run Device Code with the command: Get-AzureToken -Client Outlook

If the policy is set correctly, you should receive the following message. Therefore you cannot proceed with the simulation and its commands.

The rest of the flow with the command RefreshTo-OutlookToken or $OutlookToken.access_token is useless because the token cannot be received.

Visibility and Logs

Quick visibility with Sign-in logs provides information about the login process and the failed attempts. What should we take from these records?

  • Authentication requirement – Multifactor authentication
  • Status – Failure
  • Sign-in error – code 53003
  • Failure reason Access has been blocked by Conditional Access policies. The access policy does not allow token issuance.
  • Application – Microsoft Office
  • Resource – Office 365 Exchange Online
  • Client app – Mobile Apps and Desktop clients
  • Device info Operating System Windows

From a defense perspective (Blue Team, SOC, etc.) I can say that Token Protection it’s good news because it provides new security controls to fight token theft again. As we know, it still covers only specific applications, but once it covers additional applications, token theft will be much harder to initiate from the attacker’s perspective.

You may also like...

Leave a Reply

error: Content is Protected !!
%d bloggers like this: