Authentication fails with entra ID (personal account)

[weikanglim]

Describe the bug We've received a few reports of users failing to deploy Aspire projects using azd because of auth failures to ACR.

After investigating further, it seems that users logging in with personal accounts to Azure subscriptions are affected. A minimal repro is provided below to use az to reproduce the issue.

To Reproduce Steps to reproduce the behavior:

1. Log in with personal account with an Azure subscription
2. Create an ACR
3. az acr login --expose-token -n <ACR>
4. Receive error:

   Unable to get AAD authorization tokens with message: 2023-12-05 21:52:08.405811 An error occurred: CONNECTIVITY_REFRESH_TOKEN_ERROR
   Access to registry '<acr>.azurecr.io' was denied. Response code: 401. Please try running 'az login' again to refresh permissions.

Expected behavior Login succeeds, token is printed out.

Screenshots

An example response error occuring at 2023-12-05T22:19:27:

 POST https://acrrjdeqels63jda.azurecr.io/oauth2/exchange
--------------------------------------------------------------------------------
RESPONSE 401: 401 Unauthorized
ERROR CODE UNAVAILABLE
--------------------------------------------------------------------------------
Response contained no body
--------------------------------------------------------------------------------

x-ms-correlation-request-id: 549b20a24cef3a6f4d60d87a386e0776

Additional context Can provide specific JWT exchange tokens if needed.

[northtyphoon]

@weikanglim can you check if you are the classic admin on the subscription? If yes, you can work around it by granting your account the own role on the subscription.

[weikanglim]

@northtyphoon Thanks for the suggestion. I did verify indeed that I was a service administrator, likely that this subscription was created awhile back.

And after assigning myself an "Owner" role of the subscription this is addressed.

However, this ends up impacting a lot of users with existing long-lived subscriptions. Would there be an alternative that doesn't require a workaround?

[northtyphoon]

@weikanglim we plan to rollout a fix to support the classic administrators by Jan. However, classic administers is deprecated. It will be great to recommend your customer to take the chance to migrate to standard Azure RBAC.

https://learn.microsoft.com/en-us/azure/role-based-access-control/classic-administrators

Important

Classic resources and classic administrators will be [retired on August 31, 2024](https://azure.microsoft.com/updates/cloud-services-retirement-announcement/). Remove unnecessary Co-Administrators and use Azure RBAC for fine-grained access control.

[shanselman]

@weikanglim we plan to rollout a fix to support the classic administrators by Jan. However, classic administers is deprecated. It will be great to recommend your customer to take the chance to migrate to standard Azure RBAC.

https://learn.microsoft.com/en-us/azure/role-based-access-control/classic-administrators

Important

Classic resources and classic administrators will be [retired on August 31, 2024](https://azure.microsoft.com/updates/cloud-services-retirement-announcement/). Remove unnecessary Co-Administrators and use Azure RBAC for fine-grained access control.

Are there any ramifications to this migration? We can still login with our MSAs, right?

[northtyphoon]

@shanselman you are right, you still login with MSA. For ACR, there should be no side-effect after you grant owner role. You can still keep the co-admin in case you have a concern on other services. Azure will retire it after 8/31/2024.

[efd7887]

@weikanglim can you check if you are the classic admin on the subscription? If yes, you can work around it by granting your account the own role on the subscription.

This is just a terrible idea in practice

[efd7887]

Still not fixed.....par for the course with you guys