Azure ArmClient not finding subscriptions for one of my accounts

I'm building an application to manage some resources in Azure. I'm using the .NET SDK to accomplish this. At the very start of the workflow, I need to allow the user to select the subscription within which to operate. The following works for my main work account:

var authOptions = new DefaultAzureCredentialOptions
{   // Force an interactive login to make the experience as explicit as possible - no surprises!
    ExcludeEnvironmentCredential = true,
    ExcludeAzureCliCredential = true,
    ExcludeAzurePowerShellCredential = true,
    ExcludeManagedIdentityCredential = true,
    ExcludeSharedTokenCacheCredential = true,
    ExcludeVisualStudioCodeCredential = true,
    ExcludeVisualStudioCredential = true,

    ExcludeInteractiveBrowserCredential = false
};

var armClient = new ArmClient(new DefaultAzureCredential(authOptions));

var subs = armClient.GetSubscriptions().ToList();

When I run this, I'm prompted with a browser-based interactive login (as expected) and if I select my work account, I'm then given all the subscriptions in a list. Great!

I noticed a problem when I accidentally selected my personal Azure account on the interactive authentication screen. Despite having (at that point) a single pay-as-you-go subscription on my account, visible in the portal, I was getting zero through the above code.

Whilst playing around, I changed the last line to:

var defSub = armClient.GetDefaultSubscription();

Which, again, works for my work account. For my personal account, however, I now get an exception which reads:

No subscriptions found for the given credentials

Searching for this message lead me to a likely looking question, where the highest voted answer (sadly not accepted) seems to suggest it could be to do with my RBAC role in the subscription. On the one hand, this seems possible, since I'm seeing differential behaviour between the two accounts. On the other hand, I don't think my personal account is old enough to have been created before RBAC was a thing.

Nevertheless, I have tried the following on my personal Azure account:

1. Fiddled with my role/permissions - I am now a service admin and an owner for the subscription.
2. Created a brand new PAYG subscription in the same account
3. Verified I have only a single directory
4. Signed out and in again, multiple times

I'm starting to tear my hair out! What on earth could be causing this?

---

Update 1 DeepDave-MT linked to a bug report which seems to match my experience. To dig deeper, I ran the following code suggested in the linked thread:

using AzureEventSourceListener listener = AzureEventSourceListener.CreateConsoleLogger();
var options = new InteractiveBrowserCredentialOptions();
options.Diagnostics.IsAccountIdentifierLoggingEnabled = true;
var armClient = new ArmClient(new InteractiveBrowserCredential(options));

This revealed that the tenant ID used by the ARM Client does not match the tenant ID of my subscriptions. The latter can be confirmed by running:

az account list --all

I suppose now the big question is how to control which tenant is being used...

I've found a workaround! Full credit to DeepDave-MT for nudging me in the right direction. I'll post this here, but leave it unaccepted for a while in case a better approach turns up...

The central issue here is that the my personal user is my normal MS account, which is "external" to the tenant. To get things to work as expected, I had to create a new user within my default AD directory.

Steps I took:

1. Go to the Azure Portal and navigate to the Active Directory blade
2. Add a new user within the domain
3. In an incognito window, log into the portal using the new credentials and change the password
4. Back in the main window (logged in as the original user), navigate to the subscription(s) of interest
5. Go to the IAM page and
   • Press the "Add" button to add the new user as a co-admin
   • Press the "Add" button again to add the "Owner" role to the new user
6. Try interactive auth again, but this time use the new user

It all clicked into place when I looked at the table of AD users:

Note that the topmost row is the newly created one, with a value in the "Identities" column matching the tenant. The one below it was my original user, which has "EXT" in the username and "MicrosoftAccount" as the Identity. Clicking this identity opens a pane with further details:

Which makes it clear this is a federated login rather than a "first party" user.

Not an ideal user experience, but at leave I have a workaround now.