Environment
- OS: Windows 11 Enterprise (Intune/MDM-enrolled, Entra ID joined)
- VS Code: latest
- Extension: ms-azuretools.vscode-azureappservice (latest)
- Azure tenant with Conditional Access policies enforcing compliant device or MFA-per-session
Description
On MDM-enrolled, Entra ID-joined Windows machines with Conditional Access (CA) policies, the extension's Azure authentication flow (via @azure/identity) may fail or loop because:
-
Device compliance not signaled: The extension uses the InteractiveBrowserCredential or AzureCliCredential code path, which opens a browser popup. If the CA policy requires a compliant device signal, the auth server may reject the token even after the browser flow completes, with a generic AADSTS50076 or AADSTS530003 error that the extension does not surface clearly.
-
Silent token refresh blocked: After the initial auth, CA-triggered MFA re-challenges can interrupt background token refresh, causing the extension to silently lose its authenticated state. The tree view then shows stale data or 401 errors without prompting for re-auth.
-
No Broker/WAM integration: Windows has a Web Account Manager (WAM) / Microsoft Authentication Broker that can satisfy CA policies transparently using device-level tokens. The extension does not use WAM, so it cannot leverage the device's existing Entra ID-joined state.
Expected vs Actual Behavior
Expected: Extension uses Windows WAM/broker for auth on Entra-joined devices, satisfying CA policies without extra prompts; CA-related errors surface actionable messages (not just HTTP 401/403).
Actual: Auth fails with opaque errors or silently degrades on CA-enforced tenants; users must disable CA policies or use a workaround.
Additional Context
The �zure-identity SDK has a VisualStudioCodeCredential and experimental broker support. Using the VS Code credential chain (which can leverage VS Code's own AAD session) or documented WAM integration would resolve this for Entra-joined Windows devices.
Environment
Description
On MDM-enrolled, Entra ID-joined Windows machines with Conditional Access (CA) policies, the extension's Azure authentication flow (via @azure/identity) may fail or loop because:
Device compliance not signaled: The extension uses the InteractiveBrowserCredential or AzureCliCredential code path, which opens a browser popup. If the CA policy requires a compliant device signal, the auth server may reject the token even after the browser flow completes, with a generic AADSTS50076 or AADSTS530003 error that the extension does not surface clearly.
Silent token refresh blocked: After the initial auth, CA-triggered MFA re-challenges can interrupt background token refresh, causing the extension to silently lose its authenticated state. The tree view then shows stale data or 401 errors without prompting for re-auth.
No Broker/WAM integration: Windows has a Web Account Manager (WAM) / Microsoft Authentication Broker that can satisfy CA policies transparently using device-level tokens. The extension does not use WAM, so it cannot leverage the device's existing Entra ID-joined state.
Expected vs Actual Behavior
Expected: Extension uses Windows WAM/broker for auth on Entra-joined devices, satisfying CA policies without extra prompts; CA-related errors surface actionable messages (not just HTTP 401/403).
Actual: Auth fails with opaque errors or silently degrades on CA-enforced tenants; users must disable CA policies or use a workaround.
Additional Context
The �zure-identity SDK has a VisualStudioCodeCredential and experimental broker support. Using the VS Code credential chain (which can leverage VS Code's own AAD session) or documented WAM integration would resolve this for Entra-joined Windows devices.