<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=2923012&amp;fmt=gif">

What to Know About Using Azure Bastion to Connect to Azure AD Joined Servers

    

 

In January, Microsoft published an article that explores connecting to an Azure VM via Bastion. The appeal of Bastion is that you can RDP/SSH into a server via the portal without punching holes through firewalls. For environments looking to shift their servers to an Azure AD joined model, which is only supported within the Azure cloud at this time (as noted in Azure AD joined devices), having the means to securely connect to the console is crucial. Originally when Azure Bastion was released, authentication to Azure AD was not supported. And while this is progress, there are some caveats that admins should be made aware of. Before we explore those caveats, let’s break down some of the Azure tech stack.

What is Azure AD Join?

The name of the game with Azure AD joined devices is simplification—it allows you to join devices to your Azure Active Directory (Azure AD) tenant by offering a single sign-on (SSO), centralized management experience.

What is Azure Bastion?

Azure Bastion allows you to connect to a virtual machine (VM) using your browser and the Azure portal, or via the native SSH or RDP client already installed on your local computer. Bastion was created to allow secure and seamless remote access within an Azure virtual network by providing a remote desktop protocol (RDP) and secure shell (SSH) connectivity to VMs using SSL encryption.

Azure Bastion eliminates the need for a public IP address, virtual private network (VPN), or Jump server—replacing that process with just a few clicks of a button. The benefits of Azure Bastion are intended to be:

  • Secure remote access
  • Simplified network configuration
  • Centralized management of VMs
  • Audit trails for complianceAzure Bastion

Caveats: Azure Ad Join, Azure Bastion & Azure CLI

As of the time this article was written, connecting to Azure Bastion is required for Azure CLI.

What is Azure CLI?

The Azure Command-Line Interface (CLI) is a command-line tool you can use to connect and streamline Microsoft Azure resources through the use of an interactive command-line. These commands are designed to simplify the management of resources by automating common tasks and providing a consistent interface across Azure services. Azure CLI supports multiple operating systems, including Windows, macOS, and Linux.

Azure CLI can also help you perform tasks like:

  • Querying and managing resource groups, subscriptions, and tenants.
  • Deploying and managing Azure Resource Manager templates.
  • Managing Azure Active Directory, including users, groups, and applications.

Part of this Azure Bastion/Azure CLI connection process means knowing the “VMResourceID” of the virtual machine as noted in this VM connection article from Microsoft.  As noted in the article:

“The VM's Resource ID. The Resource ID can be easily located in the Azure portal. Go to the Overview page for your VM and select the JSON View link to open the Resource JSON. Copy the Resource ID at the top of the page to your clipboard to use later when connecting to your VM.”
 
When executed from Azure CLI, the VM will connect to Azure Bastion. However, it is impossible to do this from the Azure portal. For an admin dealing with many servers, it can become a tiresome exercise to identify the VM Resource ID per VM, in order to connect. Additionally, the Azure CLI needed to execute this will not work with the one offered online through cloud shell (at the time this article was written). Rather it is recommended to use the latest release of Azure CLI, which is linked here.

MFA & Azure Bastion

Another caveat admins should be aware of is Multi-factor authentication (MFA). If conditional access rules are in place to require MFA for all cloud applications, an exclusion would need to be set for “Azure Windows VM Sign-In”. Below is another excerpt from the Microsoft article:

“If you require MFA as a control for granting access to the Azure Windows VM Sign-In app, then you must supply an MFA claim as part of the client that initiates the RDP session to the target Windows VM in Azure. The only way to achieve this on a Windows 10 or later client is to use a Windows Hello for Business PIN or biometric authentication with the RDP client. Support for biometric authentication was added to the RDP client in Windows 10 version 1809.”

For audiences not using that degree of MFA (such as the Microsoft authenticator), the exception will be needed. This also means if legacy MFA is enabled on accounts (participating with Azure Bastion connecting to Azure AD joined machines) they would need to be turned off, making conditional access the determining factor. Users will get the error "The sign-in method you're trying to use isn't allowed. Try a different sign-in method or contact your system administrator." This error reflects legacy MFA needs to be disabled for the connection to continue.

While Azure Bastion historically provides a secure and nimble methodology to connect Azure VMs, environments looking to shift servers to Azure AD joined systems as an avenue to diminish the footprint of AD need to adjust their expectations. The portal is off the table today, and Azure CLI must be used with knowledge of VM Resource ID at the ready. If MFA is not tuned right, admins will hit a roadblock in connecting to their VMs. This will likely be a combination of legacy MFA as well as conditional access rules.

If you need an expert to help you explore Azure Bastion, troubleshoot these roadblocks, or answer questions about your business’s Azure setup, contact us today. To help your company innovate through Azure, download our eBook below.

Download Azure eBook

Comments