[Bug]: Authentication with Azure Managed Redis fails because an incorrect tenant is used

[GuusRaaphorst]

Preconditions (Any important steps we need to know)

Setup done on Azure tenant 'YYY'' using Azure setup guide

Steps to reproduce (How to reproduce what you found step by step)

• Used docker run -d --name redisinsight -p 5540:5540 redis/redisinsight:latest to get the latest image and start redisinsight
• Opened the ui in a browser on http://localhost:5540/
• Selected "Connect existing database"
• Pressed button for "Azure Managed Redis"
• Selected my user
• An error messages was shown that the service principal was not found on organization 'XXX'.

Actual behavior (A short description of what you found)

An error message pops up after selecting my account.

AADSTS650052: The app is trying to access a service 'acca5fbb-b7e4-4009-81f1-37e38fd66d78'(AzureRedisCacheAadApp) that your organization 'XXX' lacks a service principal for. Contact your IT Admin to review the configuration of your service subscriptions or consent to the application in order to create the required service principal.

This makes sense, because the setup was done on Azure tenant/organization 'YYY'. Tenant 'YYY' is the tenant of one of our customers where we have several Azure Managed Redis instances. Tenant 'XXX' is the tenant of my own company.

Expected behavior (A short description of what you expected to find)

That I can login with my user. Perhaps having some way to select or set the desired tenant, to help login succeed.

Additional context (Operating system, version of Redis Insight, Redis database version, Redis module version, database type, connection type, logs, or any other information)

• using latest redis insight from docker
• Azure Managed Redis with Entra authentication

[vladislav-karamfilov]

I have a similar issue to this one. My account has access to 2 Azure tenants/directories XXX and YYY. We have Azure Managed Redis resources in both tenants/directories. I successfully access Azure Managed Redis resources in subscriptions of Azure tenant/directory XXX but I cannot see the subscriptions of Azure tenant/directory YYY and thus cannot access Azure Managed Redis resources from it. I'm admin in both Azure tenants/directories but in 1 of them (in YYY) I'm an external user (ExternalAzureAD identity in Microsoft Entra ID). The described procedure Azure Managed Redis Setup has been followed in both Azure tenants/directories.

[pawelangelow]

Thanks for the detailed report - and to @vladislav-karamfilov for the related case.

We think both reports come down to the same root cause and we'd like to confirm the scenario with you before discussing the proposed fix internally.

What's happening

RedisInsight currently signs in via the multi-tenant /common endpoint (https://login.microsoftonline.com/common/oauth2/v2.0/authorize?...)

Azure resolves /common to the user's home tenant and issues the access token there. The https://redis.azure.com/.default scope then requires the AzureRedisCacheAadApp service principal (acca5fbb-b7e4-4009-81f1-37e38fd66d78) and consent grants to exist in that home tenant - which is what AADSTS650052 is complaining about.

So in your case (@GuusRaaphorst):

• AMR resources live in tenant YYY.
• You ran the setup in YYY.
• You sign in with a user whose home tenant is XXX.
• Token is issued against XXX, where the service principal does not exist → error.

For @vladislav-karamfilov: since the token is always issued against your home tenant XXX, the subsequent ARM /subscriptions call also returns only subscriptions in XXX, which is why YYY (where you're a guest) never shows up.

Could you confirm with a quick check?

To confirm we've nailed the scenario, could you run the setup commands from azure-setup.md in the user's home tenant (i.e. XXX for @GuusRaaphorst) and try logging in again? If the AADSTS650052 disappears, that confirms the root cause and we'll take the proposed fix below to the next team sync.

For the guest-user case, this workaround won't help on its own - but please confirm whether the behavior you see matches the description above (i.e., you only see subscriptions of your home tenant after sign-in).

[vladislav-karamfilov]

@pawelangelow , I can confirm that this is exactly what I'm observing in my case.