Azure Bastion Native RDP (Entra ID) via Azure CLI Fails with Python Errors Despite Meeting Configuration Prerequisites

Dre Vanhorn 0 Reputation points
2026-06-05T14:02:33.89+00:00

Description

I am attempting to validate Microsoft Entra ID authentication for Windows VM access via Azure Bastion using the Azure CLI native RDP method (az network bastion rdp).

While all known prerequisites for Entra ID login and Bastion integration appear to be satisfied, the CLI execution fails with Python-related errors, preventing further validation using the native client workflow.

Additionally, alternate validation methods (Bastion portal and native RDP with web authentication) are either failing or behaving inconsistently, making it difficult to isolate whether the issue is related to CLI tooling, Entra login configuration, or platform limitations.

Azure Bastion
Azure Bastion

An Azure service that provides private and fully managed Remote Desktop Protocol (RDP) and Secure Shell (SSH) access to virtual machines.

1 answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-06-05T14:03:16.77+00:00

    Azure Bastion Microsoft Entra ID authentication has specific support and limitation boundaries that explain most of the behavior described.

    Key points from documented behavior:

    1. Entra ID authentication support in Bastion
      • Entra ID authentication is supported for both RDP and SSH connections when:
        • Bastion is at least Basic SKU for portal connections.
        • Bastion is at least Standard SKU for native client connections using az network bastion rdp or az network bastion ssh.
      • When all requirements are met, Microsoft Entra ID appears as the default authentication option on the Bastion connection page in the Azure portal. If any requirement is not met, the Entra ID option does not appear.
      • For native client RDP, Entra ID sign-in uses a different flow than the portal: after MFA completes, the native RDP client still prompts for a password.
      • Entra ID authentication behavior and availability can differ between connection methods (portal vs native client) and between Windows and Linux VMs.
    2. Bastion authentication and connectivity troubleshooting
      • If Bastion cannot connect to the VM or the Bastion session fails, use the Connection Troubleshoot tab on the Bastion resource to validate TCP connectivity from a source VM to the target VM. This helps confirm that RDP traffic (TCP 3389) is not blocked by NSGs or other network controls.
      • If Just-In-Time (JIT) access is enabled, additional role assignments may be required to connect via Bastion. Missing JIT-related permissions can prevent Bastion connectivity even when other prerequisites appear satisfied.
      • A black screen or failed session in the portal often indicates NSG or firewall issues between Bastion and the VM, or WebSockets being blocked between the browser and Bastion.
    3. Domain-joined and Entra-joined sign-in constraints
      • Bastion supports domain-joined VM sign-in for username/password-based domain sign-in only, and requires UPN format (username@domain) rather than domain\username.
      • This support explicitly applies to domain-joined or hybrid-joined (domain-joined + Entra joined) VMs.
      • It is not supported for Microsoft Entra joined-only VMs.
      • This limitation explains scenarios where Entra users cannot be resolved or where sign-in methods are rejected, even if the VM is Entra joined and the AADLoginForWindows extension is present.
    4. SSH and RDP limitations (for completeness)
      • For SSH to Windows VMs via Bastion:
        • Only Azure portal connections are supported; native client (az network bastion ssh) and IP-based connections are not supported.
        • Microsoft Entra authentication is not supported for SSH connections to Windows VMs.
      • For RDP to Linux VMs via Bastion:
        • Only username/password authentication is supported; Entra ID and Kerberos are not supported.
        • az network bastion rdp is not supported for Linux VMs.

    Given the above documented behavior:

    • The absence of the Entra ID option in the Bastion portal indicates that at least one Entra ID requirement is not satisfied for that VM/Bastion combination. In particular, Entra ID-based Bastion sign-in is not supported for Entra-joined-only Windows VMs; support is documented for domain-joined or hybrid-joined VMs.
    • The “sign-in method is not allowed” error and failure to resolve Entra users into local groups are consistent with the documented limitation that Bastion sign-in support targets domain-joined/hybrid-joined scenarios, not Entra-joined-only scenarios.
    • The Python errors in the Azure CLI az network bastion rdp path are not covered in the available documentation. However, even if the CLI tooling issue were resolved, Entra ID-based Bastion sign-in would still be constrained by the documented platform limitations for Entra-joined-only Windows VMs.

    For further validation and troubleshooting within supported scenarios:

    1. Confirm Bastion SKU and provisioning
      • Ensure the Bastion resource is fully provisioned and in a Succeeded state.
      • Verify the Bastion tier is Basic, Standard, or Premium (Developer SKU does not support Entra ID auth).
    2. Validate connectivity and NSGs
      • Use Connection Troubleshoot on the Bastion resource to confirm RDP connectivity from Bastion to the VM.
      • Review NSGs on both the AzureBastionSubnet and the VM subnet to ensure RDP (TCP 3389) is allowed and no higher-priority deny rules block traffic.
    3. Align with supported join state
      • For Bastion Entra ID sign-in support as documented, use a domain-joined or hybrid-joined Windows VM and sign in with UPN format credentials.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.