Hi!
Sorry for reviving this thread, but I came across your post while dealing with the exact same error message.
I couldn't find a workaround posted anywhere, so I thought I'd write a reply.
If you also use a proxy on your servers, the cause is likely the same.
1. Problem
- I also installed via WAC via Azure portal, and faced the same error message, despite RBAC roles being set correctly.
- In the browser network trace captured during a failed attempt, the portal request to the session-specific WAC
manifest.json endpoint returned HTTP 403 after approximately 60 seconds.
Couldn't start Windows Admin Center.
You are not authorized to access this tool. If you were recently given access, please wait a few minutes and try again. Learn more .
Error:You are not authorized to access this site. Please contact your administrator.
2. Cause
What I found was that the WindowsAdminCenterAccountManagement service does not use the proxy, the proxy only seems to apply WindowsAdminCenter (WAC installed via Azure portal inherits proxy settings from the Arc Agent).
At the time of a failed portal connection, the WindowsAdminCenter Event Viewer log recorded an AccountManagement Event ID 704 error:
PrivilegedAccountService: PoP Token validation was failed.
The exception chain included:
IDX20804: Unable to retrieve document from:
https://login.microsoftonline.com/common/.well-known/openid-configuration
The request was canceled due to the configured HttpClient.Timeout
of 30 seconds elapsing.
3a) Workaround
On a test server with no machine-level HTTP_PROXY, HTTPS_PROXY, or NO_PROXY variables, the following REG_MULTI_SZ value was added under the Account Management service key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WindowsAdminCenterAccountManagement
Value name: Environment
Value type: REG_MULTI_SZ
Containing one entry per line:
HTTP_PROXY=http://<proxy-server>:3128
HTTPS_PROXY=http://<proxy-server>:3128
NO_PROXY=localhost,127.0.0.1,169.254.169.254,<internal-domain>,.<internal-domain>
Restart services
Restart-Service WindowsAdminCenterAccountManagement -Force
Restart-Service WindowsAdminCenter -Force
After this service restart, Windows Admin Center could be opened from the Azure portal.
(Restarting the WindowsAdminCenter service is likely optional)
This test verified that the Account Management service honored the service-specific Environment value, therefore applying machine-level varibles isn't necessary. I will still list that alternative below
3b) Machine-level alternative
Before the service-scoped test, the following machine-level workaround was verified on affected servers:
[System.Environment]::SetEnvironmentVariable(
"HTTP_PROXY",
"http://<proxy-server>:<port>",
[System.EnvironmentVariableTarget]::Machine
)
[System.Environment]::SetEnvironmentVariable(
"HTTPS_PROXY",
"http://<proxy-server>:<port>",
[System.EnvironmentVariableTarget]::Machine
)
[System.Environment]::SetEnvironmentVariable(
"NO_PROXY",
"localhost,127.0.0.1,169.254.169.254,<internal-domain>,.<internal-domain>",
[System.EnvironmentVariableTarget]::Machine
)
Restart-Service WindowsAdminCenterAccountManagement -Force
Restart-Service WindowsAdminCenter -Force
This also restored portal access, including on an independently tested server after a fresh portal-initiated WAC installation. However, machine-level variables affect any service or application that later starts and honors these standard variables. The service-scoped registry workaround is preferred for limiting the routing change to the service that logged the timeout.
Best regards,
Erik