Testing out Azure AD protected actions for securing conditional access policy management

Azure AD protected actions, currently in public preview, is a feature where certain actions (currently a very limited set of actions revolving conditinal access) can require a specific authentication context before being allowed. Let’s have a look at what we can use this for. We are going to try out creating a policy to ensure that only users using a phishing resistant form of authentication can actually manage conditional access policies and named locations. The feature can also be used to, say, require the user to be in a trusted location to manage conditional access, or to require a compliant device.

What is an authentication context?

Ok, so let’s start by defining what an authentication context is, as most readers might not know that. Strongly simplified, when you sign into an Azure AD integrated application, you will identify yourself to the application using an ID token signed by Azure AD. The application then checks that the ID token is signed by the expected Azure AD app registration, and that it is not expired.

After the token is validated, you’re granted access to the application. Ignoring roles, claims, etc. for simplicity. Know, imagine you have an application where you want your users to be able to read everything by using any kind of sign-in, but require a step-up using FIDO 2 keys for all write actions.

This is where authentication contexts comes into play. In Azure AD, we can now first define a conditional access policy that is our default go-to CA policy that is always in action:

• Assignments
  • Target all users
  • Target a single app (or all cloud apps)
  • No conditions
• Grant
  • Require any kind of Multi-Factor Authentication

Now, we can also create our first authentication context in Azure AD, that requires a FIDO 2 key:

And now target a conditional access policy to it:

• Assignments
  • Target all users
  • Target the authentication context “High assurance authentication” (that we just created)
  • No conditions
• Grant
  • Require FIDO 2 Multi-Factor Authentication

Now, whenever the user tries to access an operation in the application, that requires more the the default read permission, the application can check whether the user’s ID token ACRS claims contains “c1” (the id of the authentication context that we created). If the c1 value is not there, send the user to Azure AD authentication with a parameter that I have blogged about earlier.

Azure AD will then see this parameter and include all conditional access policies that targets that particular authentication context on the list of authentication requirements that the user must satisfy, before the user is sent back to the application with the correct value in the ACRS claim.

Now, what if the application we talk about is the Azure portal?

This is what the protected actions feature actually is. Essentially it enabled you to require a certain authentication context in order to access certain operations!

Let’s test it out!

To remind ourselves of our goal: Require a phishing resistant authentication method in order to manage conditional access policies.

Well, while explaining authentication context, we already did two things:

1. Created an authentication context c1, named High assurance authentication. Just FYI, this is just a name, and you can name it whatever you’d like.
2. Created a conditional access policy also named High assurance authentication, that requires a passwordless MFA for all users accessing the High assurance authentication authentication context (I guess it would’ve been clearer if the name was different…)

So, we can now simply use this authentication context, and we should be done? Let’s do it.

Under the Roles and administrators pane in Azure AD, we can now find Protected actions:

Clicking Add protected actions and selecting all available actions (as there are currently very few), leaves us here:

So, we should be ready to test it out already. Navigating back to conditional access policies, we can now see a new message, asking us to reauthenticate:

Same thing when editing a conditional access policy:

I am currently signed in with MFA using the authenticator app, which is not good enough, and we are now told to sign in with a phishing resistant MFA. Also, notice that the same claims parameter as documented in my blogpost is used, so the Azure Portal does the same thing as any other application:

Back in and the step up authentication message is gone and everything works!

What about other ways of editing, such as Microsoft Graph?

Good question, let’s try a patch:

Now THIS was cool, Graph Explorer actually redirected us to sign in with a proper credential!

And it worked fine:

If we use jwt.ms to analyze our access token, we can also see that c1 is in the acrs claim, as previsouly explained:

Using the access token before the step up authentication in another tool, such as PowerShell, shows us what happens error message wise:

And what is this “eJhY2….” value you say?

It is the value we need to send in the claims parameter, which base 64 decodes to this:

{"access_token":{"acrs":{"essential":true,"values":["c1"]}}}

What I think is really cool, is that Microsoft is using authentication contexts in a way that anyone can actually do in their own applications, not through some weird closed API or anything. Well done Microsoft!

A go do for you as a reader? Go test it out!