CAE causes Microsoft Graph API calls to fail

[g-psantos]

Describe the bug

The CLI is failing to communicate with the Microsoft Graph due to some issue with Continuous Access Evaluation. Below is an example of a command that returns a CAE challenge error message, though other commands have done the same.

This error is happening immediately after I authenticated with az login, so it's highly unlikely that any of the session's properties have changed (IP/location included).

Command Name
az ad app owner add

Errors:

Continuous access evaluation resulted in claims challenge with result: InteractionRequired and code: LocationConditionEvaluationSatisfied

To Reproduce:

1. Authenticate with az login
2. Run a command such as az ad app owner add --id {app id} --owner-object-id {owner oid}
3. Hopefully, voila!

Expected Behavior

Environment Summary

Windows-10-10.0.22621-SP0
Python 3.10.8
Installer: MSI

azure-cli 2.42.0

Additional Context

Confirmed that downgrading to v2.40 of the CLI (before CAE was introduced in v2.41) and logging out/back in is a workaround.

[yonzhan]

@jiasli for awareness

[jiasli]

CAE support was introduced by

• [Core] Support Continuous Access Evaluation #23635

I can't repro this issue on my tenant. I also can't find any official document for error code LocationConditionEvaluationSatisfied: https://www.google.com/search?q=%22LocationConditionEvaluationSatisfied%22

Similar issues have been reported to other CLI tools:

• Az AD cmdlets return a "Continuous Access Evaluation" error. azure-powershell#16766
• Continuous access evaluation error microsoftgraph/msgraph-sdk-powershell#1105

I will investigate it with Azure PowerShell team internally first.

Meanwhile, could you please try to

• Share the full error message, including the recommendation message
• Run the az ad app owner add command with --debug and share HTTP trace of the MS Graph API invocation
• Check if there is any CAE-related settings in your tenant
• Log in by explicitly specifying the scope: az login --scope https://graph.microsoft.com//.default
• If the above command still doesn't work, set AZURE_IDENTITY_DISABLE_CP1 to any non-empty value to disable CAE, then run az login again:

  azure-cli/src/azure-cli-core/azure/cli/core/auth/identity.py

  Line 103 in f0c87ca

  "client_capabilities": None if "AZURE_IDENTITY_DISABLE_CP1" in os.environ else ["CP1"]

[JustinGrote]

I ran into as well with terraform, same two conditions, AZURE_IDENTIY_DISABLE_CP1 did not help, only downgrading to 2.40

Possibly related to this tenant:

1. CAE is not enabled
2. The tenant is federated to Okta
3. My particular conditional access has an IP whitelist that lets my bypass needing a Azure AD joined device (MFA still applies however)

Can't think of anything unique outside of that.

[g-psantos]

The AZURE_IDENTITY_DISABLE_CP1 environment variable workaround worked for me on v2.42. @JustinGrote, you may need to set that variable before logging in with the CLI (otherwise, the token will already have been marked as CAE-enabled).

@jiasli -- I'll try to post the result of a command with --debug enabled later today. As far as I'm aware, we haven't made any CAE-specific configurations on our tenant. We do have a few Conditional Access Policies, one of which restricts which user countries can authenticate against the tenant.

[li-rishi]

I am seeing a similar issue on my side. az login works fine and I am able to see access token with az account get-access-token. From the access token, CAE is enabled.

az account get-access-token | jq .accessToken | cut -d '.' -f 2 | base64 -d | jq .xms_cc
[
"CP1"
]

Now when I try to run terraform plan it gives me this error - note that nothing has changed since I authenticated using az login in the previous step.

╷
│ Error: building account: getting authenticated object ID: parsing json result from the Azure CLI: waiting for the Azure CLI: exit status 1: ERROR: Continuous access evaluation resulted in claims challenge with result: InteractionRequired and code: LocationConditionEvaluationSatisfied
│
│ with provider["registry.terraform.io/hashicorp/azurerm"],
│ on auto_captions.tf line 12, in provider "azurerm":
│ 12: provider "azurerm" {

OR this command

az rest --method get --url https://graph.microsoft.com/beta/auditLogs/directoryAudits
Unauthorized({"error":{"code":"InvalidAuthenticationToken","message":"Continuous access evaluation resulted in claims challenge with result: InteractionRequired and code: LocationConditionEvaluationSatisfied","innerError":{"date":"2022-12-07T01:20:08","request-id":"b273ec64-18de-484f-8c3a-dd9e3b1f59c0","client-request-id":"b273ec64-18de-484f-8c3a-dd9e3b1f59c0"}}})
Interactive authentication is needed. Please run:
az logout
az login

CLI Version:
azure-cli 2.41.0 *

I tried doing az logout and az login but no success.

=============
Downgrading azure-cli to v2.34.1 and logging out/back fixes the issue.

[cdomansky]

I am experiencing the same issues with azure-cli-2.43.0 while working with Terraform

│ Error: building account: getting authenticated object ID: parsing json result from the Azure CLI: waiting for the Azure CLI: exit status 1: ERROR: Continuous access evaluation resulted in claims challenge with result: InteractionRequired and code: LocationConditionEvaluationSatisfied
│
│   with provider["registry.terraform.io/hashicorp/azurerm"].development,
│   on provider.tf line 30, in provider "azurerm":
│   30: provider "azurerm" {

az ad signed-in-user show results with the following error.

Continuous access evaluation resulted in claims challenge with result: InteractionRequired and code: LocationConditionEvaluationSatisfied

Downgraded to azure-cli-2.40.0 which fixed the issue upon re-login.

[jiasli]

@li-rishi, @cdomansky, do you know which command that Terraform is calling results in the mentioned error?

For now, could you try to use the latest Azrue CLI and set AZURE_IDENTITY_DISABLE_CP1 environemnt variable to any non-empty value to disable CAE, then run az login again?

Then the token won't have CP1 claim:

$ export AZURE_IDENTITY_DISABLE_CP1=1
$ az account clear
$ az login
$ az account get-access-token | jq --raw-output .accessToken | cut --delimiter '.' --fields 2 | base64 --decode | jq .xms_cc
base64: invalid input
null

[cdomansky]

@jiasli Both terraform init and terraform plan commands had returned the same error. I will try this the next time I need to update my CLI instance. Thanks!

[madforchili]

@cdomansky I have python 3.11.1 installed and down grading azure cli to 2.40.0 causing

raise ArgumentError(self, _('conflicting subparser: %s') % name)
argparse.ArgumentError: argument _command_package: conflicting subparser: login

do i need to donwgrade python as well? which version if you know

[mickey-stringer]

@li-rishi, @cdomansky, do you know which command that Terraform is calling results in the mentioned error?

For now, could you try to use the latest Azrue CLI and set AZURE_IDENTITY_DISABLE_CP1 environemnt variable to any non-empty value to disable CAE, then run az login again?

Then the token won't have CP1 claim:

$ export AZURE_IDENTITY_DISABLE_CP1=1
$ az account clear
$ az login
$ az account get-access-token | jq --raw-output .accessToken | cut --delimiter '.' --fields 2 | base64 --decode | jq .xms_cc
base64: invalid input
null

This did not work for me with the latest versions of AzureCLI and Terraform. I tried setting the variable at several different scopes. I get the error when running terraform apply.
Only downgrading AzureCLI to 2.4.0 works for me.

[PPACI]

The following work for me on AzureCli

{
  "azure-cli": "2.45.0",
  "azure-cli-core": "2.45.0",
  "azure-cli-telemetry": "1.0.8",
  "extensions": {
    "interactive": "0.4.6",
    "resource-graph": "2.1.0"
  }
}

export AZURE_IDENTITY_DISABLE_CP1=1
az account clear
az login --tenant "$TENANT_ID" 
az ad signed-in-user show 

And I was able to use terraform as well! I was still not able in CLI 2.44
In double, I still export the variable

export AZURE_IDENTITY_DISABLE_CP1=1
terraform apply

[mickey-stringer]

Ok, interesting.
I tried again because I really need 2.45 for some additional features... and my terraform apply is now working.

I followed your steps @PPACI - I think the only thing you had different was explicitly setting the --tenant parameter for az login, so maybe that's key (in addition to setting AZURE_IDENTITY_DISABLE_CP1)

CC: @li-rishi @cdomansky @jiasli

[PPACI]

Indeed I had issue in the past with conditional access and CAE while not explicitly setting —tenant. I work with multiple tenant and B2C tenant, so now I have the habit of setting it.I also had experience where switching tenant was not enough. I had to “az account clear” before “as login —tenant”.On 24 Feb 2023, at 22:43, mickey-stringer ***@***.***> wrote: Ok, interesting. I tried again because I really need 2.45 for some additional features... and my terraform apply is now working. I followed your steps @PPACI - I think the only thing you had different was explicitly setting the --tenant parameter for az login, so maybe that's key (in addition to setting AZURE_IDENTITY_DISABLE_CP1) CC: @li-rishi @cdomansky @jiasli —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[adnan-ashfaq]

@li-rishi, @cdomansky, do you know which command that Terraform is calling results in the mentioned error?

For now, could you try to use the latest Azrue CLI and set AZURE_IDENTITY_DISABLE_CP1 environemnt variable to any non-empty value to disable CAE, then run az login again?

Then the token won't have CP1 claim:

$ export AZURE_IDENTITY_DISABLE_CP1=1
$ az account clear
$ az login
$ az account get-access-token | jq --raw-output .accessToken | cut --delimiter '.' --fields 2 | base64 --decode | jq .xms_cc
base64: invalid input
null

I am having the same issue as others. and this workaround worked for me. Although it was reverted when the machine was rebooted.