• Azure Virtual Machine Remote Desktop Login
• Enable Remote Desktop Azure Vm

This video demonstrates how to create and deploy a windows server virtual machine on Microsoft Azure cloud using Azure portal.This method provides a browser. Set up and Configure a new Azure Resource Manager VM to RDP via port 3389 to the Remote Desktop Access. However, I do not seem to be able to use the Windows Remote Desktop. Freddy, would u please confirm first if your Windows Azure Virtual Machine is.

How can you keep your entire Azure Virtual Network easily accessible and secure at the same time? Many an IT professional has had sleepless nights trying to figure it out. Now, let us help you avoid them!

Luckily there are some great solutions like Just-In-Time VM Access without risking port scanning and brute force attacks. We will cover the Azure VM connectivity options – including the new Azure Bastion – here.

The Azure cloud services have helped companies around the world move from on premises servers to Virtual Machines available at a moments notice. This has undoubtedly made it possible for a lot of small & medium businesses to scale fast
and saved established companies fortunes. But with new solutions come new challenges. Hackers are always searching for vulnerabilities via ports connected to public IP addresses. So when you need to connect to your Azure Virtual Machines to manage them, there are a range of security and connectivity issues.

Remote Desktop Protocol (RDP) is well-known and commonly used to access remote computers and servers. This lets IT administrators support a huge organization from the comforts of their own desk. Microsoft developed RDP and includes two administrator accounts for simultaneous RDP onto a server in Windows Server. For more users you can add CALs (RDS Client Access Licenses).

There are several challenges facing the IT professionals who need to expose their virtual machines to the public internet by opening ports (RDP/SSH):

1) Brute force attacks target management ports as a means to gain access to a VM
2) DDoS attacks by flooding the bandwidth or resources of a targeted system
3) Port scanning – finding an active port and discovering exploitable communication channels

So let’s look at the different options for connecting to your VMs with RDP and how you can mitigate these risks

RDP using a Private IP address across a Site to Site VPN

The ideal form of RDP connection is RDP across a Site to Site VPN connection. This keeps your communication with the Virtual Machine off the public internet granting protection against port scanning, brute force and DdoS attacks. With a VPN gateway from the Azure network to the on premises network Azure VMs can be RDP’ed using a private IP address – protected from the prying eyes of the public internet.

The public IP address can be removed all together if you don’t need it. If you do need to use it for something, the RDP port (usually 3389) will be closed. This is an effective and seamless approach to connect to Azure VM without public IP addresses, reducing the threat of attacks.

However, if you don’t have a Site to Site VPN to your Azure network, there are other options.

Lock down RDP to a source IP or IP Range

The default RDP port – 3389 – allows RDP connection from any IP in the world. When enabled it is therefore a security risk. You can mitigate this by restricting RDP access to a specified source IP address or range with Azure NSG’s (Network Security Groups).

Every Virtual Machine will have its own NSG when deployed through Azure. You should apply these two Inbound Port rules:

• Allowing RDP from a specific IP address or range
• Denying all other RDP traffic

Pros: This effectively reduces outside threats by only allowing the specified on premises machines to RDP into the Azure Virtual Machines.

Cons: The port is still visible on the internet. This method is best suited for smaller organizations and also involves management of Network Security Group Port rules

Just-in-time VM access:

Brute force attacks can take days and even weeks to complete. An astounding number of attempts need to be made to connect through the RDP/SSH ports. So if you only have the port open when you need it, you reduce the vulnerability. Just-in-time (JIT) VM access only opens the ports when you need them and locks them down to your IP address / range. After you have finished what you were doing on the VM, it closes the port again.

You can enable JIT easily from Azure Security Center, configure it through an Azure Virtual Machine blade or configure a JIT policy on a VM programmatically.

Pros: Reduces the risk of succesfull brute force attacks as the port is only open when you need it

Cons: You still need to open port 3389 to public internet leaving you vulnerable within the allotted time frame.

Public Load Balancer with Network Address Translation (NAT)

A Public Load Balancer has a public IP address, and a Network Address Translation (NAT) rule forwards traffic from a specific port of the front-end IP address to a specific port of a back-end VM on its Private IP. So, the VM you want to access with RDP doesn’t have to have a Public IP and its private IP isn’t visible.

Pros: Minimizes the number of Azure Public IP addresses, obfuscates management ports of virtual machines, load balances traffic across the virtual machines configured under it

Cons: This approach has certain limitations so it may not be suitable in some scenarios. The load-balancing rules and inbound NAT rules support TCP and UDP but not other IP protocols like ICMP. The load balancer doesn’t terminate, respond or interact with the payload of a UDP or TCP flow.

Provision a Jumphost VM

Rather than exposing all your virtual machines to public internet, you can use the Jumphost solution. This creates a single VM – called the Jumphost – in Azure with RDP connection to the internet. From this box you connect to your other VMs in your virtual network.

An NSG can be used to restrict the IP addresses that can communicate with the Jumphost. Monitoring and logging can also only be done on this one VM. You can easily turn it off to stop all RDP when needed.

Jumphosts are easy to deploy and greatly increase security on the overall Azure VM infrastructure maintenance. You can find CIS Hardened images ready for easy deployment and management in the Microsoft Azure marketplace.

Pros: Access your VMs through one locked down, hardened jumphost. Your VMs don’t need Public IPs.

Cons: Jumphost still involves opening one VM to public internet without eliminating outside threats completely. The additional cost of one VM, configuration, ACLs, monitoring and auditing can make this a costly solution.

Azure Bastion – a jump host PaaS service

In late 2019 Microsoft released Azure Bastion into General Availability. It is a new fully platform-managed PaaS service which provides secure and seamless RDP/SSH connectivity to your virtual machines directly in the Azure portal over SSL.

Azure Bastion provisions directly in your Azure Virtual Network acting like a jump server as-a-service. You don’t need Public IPs to access your VMs over RDP/SSH.

Additionally, Azure Bastion provides integrated connectivity using RDP/SSH directly from your browser and the Azure portal experience. You don’t need an additional client, agent, or piece of software.

Deployment of Azure Bastion is per virtual network, thus, once deployed in a virtual network, it is available to all VMs in the virtual network.

Bastion host servers are designed and configured to withstand attacks. Azure Bastion is also reinforced by automatic patching, handled by Microsoft, to best guard customers against zero-day exploits.

Pros: You don’t need public IP addresses on your virtual machines, get the benefits of a jumphost without the overhead, RDP and SSH directly in Azure portal.

Cons: The disadvantages of Azure Bastion are hard to find. This PaaS Service is not yet available worldwide, but can currently be used in 29 regions. Please ask one of our consultants for the current availability outside the UK, if this is relevant to your business.

Overall Azure Bastion is the ideal solution that IT professionals have been waiting for. It provides an easy and fool proof solution to eliminate outside threats with minimal maintenance overhead. You get all the benefits of RDP but connect to Azure VM without Remote Desktop client.

Future capabilities and features of Azure Bastion

Microsoft is still developing Azure Bastion to meet user needs. Along with the expansion to all regions the following updates are expected:

1. Azure Active Directory integration and Azure MFA (Multi-Factor Authentication)
2. Extending two-factor authentication to RDP/SSH connections
3. Added support for native RDP/SSH clients so that you can use your favourite client applications to securely connect to Azure Virtual Machines using Azure Bastion
4. Enhanced auditing experience for RDP sessions with full session video recording.

Want to know more? Give us a ring!

Provisioning Azure RemoteApp collections requires the administrator to us a preconfigured Server 2012 R2 image. In the same way as with RDS on-premises the image is preinstalled and configured with all of the applications that are to be published to the remote users.

There are three image sources an administrator can currently use when provisioning a collection.

• Use one of the preconfigured images Microsoft makes available
• Create an image from a virtual machine built on-premises
• Create an image from a virtual machine running in Azure

The preconfigured images that Microsoft offer are great for having a quick PoC up and working in a matter of a couple of hours but the recommended option if creating your own is to use an Azure VM.

Azure Virtual Machine Remote Desktop Login

It goes without saying that plenty of planning should be done when looking to move forward with a production RemoteApp deployment. It is a great Azure service and there are improvements being made all the time but as with everything there are currently some limitations to work with.

For example:

A single user can currently only be assigned to a single collection. Therefore splitting applications such as Office and other LOB applications across multiple collections is not always going to be possible. (I could be wrong but if on-premises RDS is anything to go by, one reason for this could be that a user profile disk can only be used in a single collection and not across multiple.)

As with anything Azure, things change rapidly but as of today, RemoteApp limitations to be aware of during the design phase are:

** Currently timeouts cannot be managed by GPO or configured by the administrator. They are only managed by the RemoteApp service.

More information about RemoteApp and other Azure Service Limits, Quotas, and Constraints can be found by following this link Azure Subscription and Service Limits, Quotas, and Constraints

Building a RemoteApp Template image in Azure:

There are two steps to creating a RemoteApp Template from an Azure VM.

1. Create a Azure Virtual Machine image with all preinstalled and configured applications
2. Import the Virtual Machine image in as an Azure RemoteApp Template

Creating a Azure Virtual Machine image

1. Create an Azure Virtual Machine using the “Windows Server Remote Desktop Session Host” image from the Azure Virtual Machine Gallery. This image contains the Windows Server 2012 R2 operating system with the Remote Desktop Session Host (RD Session Host) role installed and meets all the Azure RemoteApp Template image requirements.

2. Connect to the virtual machine and install and configure all of the applications that you plan to publish later on. (Check the image creation tips at the end of this post.)

3. Now all applications have been installed and configured as required, the image needs to be validated. Because the VM was created using the RDSH image from the Azure Virtual Machine Gallery, we have the luxury of double clicking on the “ValidateRemoteAppImage” shortcut on the desktop. This script validates the virtual machine is ready to be used as a RemoteApp image and checks that it is configured in line with all RemoteApp pre-requisites. If all checks pass successfully, the script even offers the option to run SYSPREP for you!

If the script reports back errors, make sure they are resolved before continuing to SYSPREP the image.

To manually SYSPREP the virtual machine open an elevated command prompt and run the following:

C:WindowsSystem32sysprepsysprep.exe /generalize /oobe /shutdown

(Do not use the /mode:vm switch even though this is a virtual machine)

4. Once SYSPREP has run and the VM has been shut down, capture the VM as a virtual machine image. To do this, select the correct VM from the list and click the capture button on the bottom menu.

5. When the capture wizard appears, give the image a name, description and check the box to say that SYSPREP has been run on the virtual machine. Doing this will remove the VM once it has been converted to an image. The final step to the process is to click on the tick to begin the import.

Once complete the image will appear under the virtual machine images tab.

Importing the Azure Virtual Machine image in as an Azure RemoteApp Template

1. Browse to the RemoteApp service and the TEMPLATE IMAGES tab at the top. If it’s the first image in the library click on IMPORT OR UPLOAD TEMPALTE IMAGE to open up the next wizard.

If an image already exists, click on the + on the bottom menu bar to begin adding a new image.

2. Select Import an image from your Virtual Machine library (Recommended).

3. Select the Virtual Machine image from the drop down list and check the box to confirm that all the correct steps were taken in creating the virtual machine image.

4. Give the RemoteApp template image a name and location and finish by clicking on the tick button.

When imported, the RemoteApp Template Image is available to the administrator when creating a new RemoteApp collection.

It is possible as mentioned earlier in the post to upload an image that has been created on-premises and I may cover this in a later post, but using an Azure Virtual Machine is a much easier process and Microsoft recommended approach.

The following are a few tips that Microsoft suggest to use when creating the Template image:

• Check all applications to be published have start menu shortcuts. This will make publishing the applications much simpler later.
• Disable automatic software updates for published applications.
• Install the RDSH role before installing applications to ensure that any issues with application compatibility are discovered before the image is uploaded to RemoteApp. (This is already the case with the Azure RDSH gallery image)
• Create a local user i.e. sysadmin and add them to the local administrators group and Remote Desktop.
• Scheduled tasks do persist after SYSPREP.
• Disable automatic software updates for published applications.
• Never store data on instances (c: drive).

Enable Remote Desktop Azure Vm

That’s it for this post, its quite a long one but hope people find it useful. 🙂