Description
a365 setup all can fail with misleading Microsoft Graph permission errors when Windows Account Manager (WAM/MSAL) silently uses the wrong cached work account.
In this case, Azure CLI was logged into the correct tenant/subscription and the intended user had the required admin roles, but a365 still failed during permission grants and agent registration. The issue was resolved only after removing other cached Windows work accounts and ensuring the correct tenant account was used by the Windows sign-in prompt.
Environment
| Item |
Value |
| Tool |
a365 CLI |
| Versions observed |
1.1.184, then retried with 1.1.188 |
| OS |
Windows |
| Auth path |
Windows Account Manager / MSAL interactive authentication |
| Command |
a365 setup all --agent-name <agent-name> |
Symptoms
The setup partially succeeded: the blueprint and agent identity were created or reused, and inheritable permissions were configured.
Later steps failed with errors like:
OAuth2 permission grant failed ... Authorization_RequestDenied
Insufficient privileges to complete the operation.
Failed to assign app role 'Agent365.Observability.OtelWrite': HTTP 403 Forbidden
Agent registration failed (403 Forbidden).
Ensure the signed-in user has the required Entra role
(e.g., Agent Registry Administrator) and the tenant is enrolled
in the required preview program.
This was confusing because the intended account already had roles such as Global Administrator, Application Administrator, and Agent Registry Administrator.
Root cause
az login and a365 were not necessarily using the same account.
Azure CLI was pointed at the correct tenant, but a365 used Windows Account Manager/MSAL for Microsoft Graph authentication. WAM selected a different cached work account from Windows, so Graph calls were made with the wrong identity.
As a result, the CLI showed permission errors that looked like missing roles or tenant enrollment problems, even though the intended account was correctly privileged.
Resolution
The fix was to clean up the Windows account cache and force the correct account into the WAM/MSAL flow.
Steps taken:
- Removed other cached work/school accounts from Windows.
- Added the correct tenant account under Windows accounts.
- Re-ran the
a365 setup flow.
- Completed the Windows sign-in prompt with the intended tenant account.
After that, setup completed successfully:
A365-S2S-OK
S2S app role assignments completed via PowerShell.
Configuring delegated permissions...
- Delegated admin consent already granted for all required scopes
Registering agent...
Agent registered (...)
Setup completed successfully
Why this matters
The current failure mode points users toward Entra role assignments, admin consent, or tenant preview enrollment. Those may be valid causes in some cases, but in this case the real issue was account mismatch between Azure CLI authentication, Windows Account Manager/MSAL Graph authentication, and the configured target tenant.
This can waste debugging time because the user may repeatedly verify roles while the CLI is still authenticating Graph with the wrong cached account.
Suggested product improvements
a365 should make the Microsoft Graph authentication identity visible and validate it against the configured tenant.
Suggested diagnostics:
Graph authentication account: <UPN>
Graph authentication tenant: <tenant>
Azure CLI account: <UPN>
Azure CLI tenant: <tenant>
Configured tenant: <tenant>
If the accounts or tenants differ, fail fast with clear guidance:
The Microsoft Graph account selected by Windows Account Manager does not match the configured tenant/account.
Please choose the correct account in the sign-in prompt, remove stale Windows cached accounts, or rerun with an explicit account option.
Useful additional options could include:
a365 auth clear
a365 setup all --tenant-id <tenant-id> --account <upn>
Recommended troubleshooting note
If a365 setup all fails with Authorization_RequestDenied or 403 Forbidden despite the user having the required Entra roles, verify that the Windows Account Manager sign-in prompt is using the same account and tenant as Azure CLI.
Expected behavior
No response
SDK Version
1.1.184, 1.1.188
Language/Runtime
.net
OS
windows 11
How to Reproduce
Have >=4 number of work accounts in windows accounts already & try loggin in with newer work account.
Either it won't be prompted or will silently use wrong account!
Output
No response
Screenshots
No response
Code of Conduct
Description
a365 setup allcan fail with misleading Microsoft Graph permission errors when Windows Account Manager (WAM/MSAL) silently uses the wrong cached work account.In this case, Azure CLI was logged into the correct tenant/subscription and the intended user had the required admin roles, but
a365still failed during permission grants and agent registration. The issue was resolved only after removing other cached Windows work accounts and ensuring the correct tenant account was used by the Windows sign-in prompt.Environment
a365CLI1.1.184, then retried with1.1.188a365 setup all --agent-name <agent-name>Symptoms
The setup partially succeeded: the blueprint and agent identity were created or reused, and inheritable permissions were configured.
Later steps failed with errors like:
This was confusing because the intended account already had roles such as Global Administrator, Application Administrator, and Agent Registry Administrator.
Root cause
az loginanda365were not necessarily using the same account.Azure CLI was pointed at the correct tenant, but
a365used Windows Account Manager/MSAL for Microsoft Graph authentication. WAM selected a different cached work account from Windows, so Graph calls were made with the wrong identity.As a result, the CLI showed permission errors that looked like missing roles or tenant enrollment problems, even though the intended account was correctly privileged.
Resolution
The fix was to clean up the Windows account cache and force the correct account into the WAM/MSAL flow.
Steps taken:
a365setup flow.After that, setup completed successfully:
Why this matters
The current failure mode points users toward Entra role assignments, admin consent, or tenant preview enrollment. Those may be valid causes in some cases, but in this case the real issue was account mismatch between Azure CLI authentication, Windows Account Manager/MSAL Graph authentication, and the configured target tenant.
This can waste debugging time because the user may repeatedly verify roles while the CLI is still authenticating Graph with the wrong cached account.
Suggested product improvements
a365should make the Microsoft Graph authentication identity visible and validate it against the configured tenant.Suggested diagnostics:
If the accounts or tenants differ, fail fast with clear guidance:
Useful additional options could include:
Recommended troubleshooting note
If
a365 setup allfails withAuthorization_RequestDeniedor403 Forbiddendespite the user having the required Entra roles, verify that the Windows Account Manager sign-in prompt is using the same account and tenant as Azure CLI.Expected behavior
No response
SDK Version
1.1.184, 1.1.188
Language/Runtime
.net
OS
windows 11
How to Reproduce
Have >=4 number of work accounts in windows accounts already & try loggin in with newer work account.
Either it won't be prompted or will silently use wrong account!
Output
No response
Screenshots
No response
Code of Conduct