Tag: IaaS

Azure

Azure Bastion – End of the Jumpbox?

A common headache facing customers migrating workloads to the public cloud is deciding how best to provide secure remote access to Windows and Linux VMs.

This is normally achieved using Remote Desktop Protocol (RDP) and Secure Shell (SSH) sessions connected over public IP addresses, either directly assigned to individual hosts or a shared Jumpbox. Another option is to only allow remote access from a trusted private network over an inter-site connection such as a site-to-site VPN or ExpressRoute.

Either way, enterprises are forced to compromise security or impact the user’s experience, limiting where they can access from or by forcing them to traverse numerous network levels to gain access to the required service.

The problem with adding public endpoints directly to a host or even to a Jumpbox is that it makes them susceptible to malicious attacks. Amongst other things, it’s possible to use port scanning to discover the public IP and then brute force attacks to compromise the machine.

In efforts to reduce risk, security features such as MFA, Just in Time Access (JiT) and ACL can be implemented, but this can be difficult to manage and not totally infallible.

Azure Bastion

In answer to this problem, Microsoft has released in public preview the Azure Bastion service. Bastion is a new managed PaaS service that provides seamless RDP and SSH connectivity for your VMs over Secure Socket Layer (SSL). The service does this without having to configure each VM with its own public endpoint.

Key features available during the public preview include:

  • RDP and SSH from the Azure portal: Initiate RDP and SSH sessions directly in the Azure portal with a single-click seamless experience
  • Remote session over SSL and firewall traversal for RDP/SSH: HTML5 based web clients are automatically streamed to your local device providing the RDP/SSH session over SSL on port 443
  • No public IP required on Azure Virtual Machines: Azure Bastion opens the RDP/SSH connection to your Azure virtual machine using a private IP, limiting exposure of your infrastructure to the public Internet
  • Simplified secure rules management: Simple one-time configuration of Network Security Groups (NSGs) to allow RDP/SSH from only Azure Bastion
  • Increased protection against port scanning: The limited exposure of virtual machines to the public Internet will help protect against threats, such as external port scanning
  • Hardening in one place to protect against zero-day exploits: Azure Bastion is a managed service maintained by Microsoft. It’s continuously hardened by automatically patching and keeping up to date against known vulnerabilities.

Is it ready for the Enterprise customer?

Whether VNets have been implemented due to project segmentation, business unit, location and so on, it’s very rare to encounter an enterprise customer that does not have to control VMs sprawled over multiple VNets.

At the time of writing, limitations of the Bastion service mean that it does not yet support VNet peering. It is also only possible to deploy a Bastion host within a single VNet.

The service roadmap highlights plans to add great capabilities like Azure AD integration, Seamless Single-Sign-on and Multi-Factor Authentication to the service. Further research of various blogs and community chat suggest that support for peered VNets is another feature also being explored.

For now, when trying to access VMs attached to VNets in unsupported regions or for customers that don’t wish to deploy a Bastion host for each VNet, the workaround is to simply adopt a hub-spoke network architecture. The Bastion host sits in the hub VNet which it shares with a Jumpbox, in essence replacing the need for a secure VPN connection. It’s then from the Jumpbox that remote access can be gained across the network peerings.

Before configuring the service, there are a couple of things with the public preview to bear in mind.

  • During the public preview, the service can only be deployed from the Azure Marketplace when accessed through the Bastion preview portal: https://aka.ms/BastionHost
  • The service requires a dedicated subnet called AzureBastionSubnet of at least /27 in size
  • The preview is limited to West US, East US, West Europe, South Central US, Australia East and Japan East
  • Supported browsers are limited to Microsoft Edge (Windows), Google Chrome (Windows, Mac) and Microsoft Edge Chromium (Windows, Mac).

Configuring a Bastion Host

1. Log in to the Bastion preview portal and from the homepage, click on +Create a resource.

2. On the New page, type Bastion in the Search the Marketplace box and then press Enter.

3. Select the Bastion (preview) offering, then click on Create.

4. Fill in the Create a bastion web form and finally click Review + create

Connecting to a VM

1. Now the service has been created, simply choose a VM and click on the Connect button as normal.

2. A new BASTION tab is now active on the Connect to virtual machine blade. Select the tab, fill in the username and password details before finally clicking Connect.

The following image shows the RDP session running within the boundaries of the web browser and the Azure portal.

The user experience is the same for SSH sessions.

Conclusion

With console access lacking in Azure and many planned features on the road map, for the most part, I’m really excited about the service. Whether it completely replaces customers needs for a Jumpbox or just offers an alternative to a secure connection to a Jumpbox in place of the normal VPN or ExpressRoute offering, it’s definitely a big step in the right direction.

The one slight concern I have is that Windows or Linux admins who have previously only had access to the client OS and may know little or nothing about Azure, are suddenly going to be exposed to the Azure portal rather than accessing the client directly. Making sure the portal is locked down and security features are configured and in place will be essential. I’m sure though as the service matures, it’s likely that improvements will address this.

To answer the question above, is the Jumpbox dead? My gut feeling is that for now, probably not. In the not too distant future, well it’s looking possible.

To learn more about the Azure Bastion service, head over to Microsoft docs: https://docs.microsoft.com/en-gb/azure/bastion/bastion-overview

Azure

Azure: Cost Optimisation – Enabling Hybrid Use Benefit (HUB)

I used to spend most of my time discussing with customers the benefits of moving business services to the cloud. Most no longer need to be convinced, in fact many have already dabbled with services and instead are looking for guidance on how to enforce governance and better manage costs.

Cost optimisation in Azure is a large topic and by adopting a number of technologies and processes it is possible to make rewarding cost savings.

Along with investing in reserved instances one of the biggest cost savers for Windows VMs can be make through the use of the Microsoft Hybrid Use Benefit (HUB).

What is Hybrid Use Benefit (HUB)

The Azure Hybrid Benefit helps you get more value from your Windows Server licences and save up to 40 per cent* on virtual machines. You can use the benefit with Windows Server Data Centre and Standard edition licences covered with Software Assurance or Windows Server Subscriptions. Depending on the edition, you can convert or re-use your licences to run Windows Server virtual machines in Azure and pay a lower base compute rate (Linux virtual machine rates).

* Actual savings may vary based on region, instance type or usage.

Paragraph from HUB FAQ

It’s worth noting that licensing entitlement is different between Windows Server Datacentre and Windows Server Standard editions.

  • Windows Server Datacentre with Software Assurance allows you to use the license on-premises and simultaneously in Azure
  • Windows Server Standard with Software Assurance allows you to use the license on-premises or in Azure

With both editions, each two-processor licence or each set of 16-core licences are entitled to two instances of up to 8 cores, or one instance of up to 16 cores.

Enabling Hybrid Use Benefit 

Hybrid Use Benefit can be enabled when deploying a Windows VM either from the marketplace, as part of an ARM template or PowerShell script. It can also be enabled post deployment.

I’ve focused on PowerShell and outlined below are a few commands that might be of use. Its also worth mentioning that its possible to do the majority of this through the portal or Azure CLI.

Dependencies

The first thing to do is make sure that you have the Azure PowerShell module installed.

If you already have the module installed, I would suggest checking that you are running the latest version. This can be done by running the following command.

How do I know if Hybrid Use Benefit is enabled on a VM?

Its possible to check if Hybrid Use Benefit is enabled on a machine by looking at the virtual machines blade in the Azure Portal.

Browse to the virtual machine blade, from the top ribbon select Edit columns and then add Azure Hybrid Benefit to the selected columns list.

Once the Hybrid Use Benefit column has been added to the blade view, its easy to scan down and see which machines have been enabled or not.


As you would expect, its also straight forward to pull back the same information across all machines using a simple PowerShell command.

The following PowerShell snippet outputs just the Windows machines that HUB is enabled for and ignores the rest.

This screenshot is of the above PowerShell snippet being run from within Azure Cloud Shell.

Converting an already deployed VM

For Windows machines deployed with Pay-as-you-go licensing, its a simple process to convert them to Hybrid Use Benefit. As before this can either be done from within the Azure portal or using a simple PowerShell command such as the one below.

NOTE: Changing the license type only updates the machines metadata flag. This means there is no downtime or service interruption to the system. 

Converting back to Pay-as-you-go Licensing

Reverting the VM to Pay-as-you-go licensing is done using the same command. This time, the licensing type needs to be changed to None before running.

Change the license type of every Windows VM in the subscription

Updating the license type of multiple VMs one at a time can be very time consuming. To speed things up, I would recommend reviewing the following script created by Neil Bird a Premier Field Engineer at Microsoft.

The script not only allows you to change the licensing type across all Windows VMs but it also offers a Simulate Mode where no changes are actually made. Instead, LOG and CSV export files are generated to show what changes the script would make if ran in Update Mode.

https://gallery.technet.microsoft.com/Azure-Enable-Hybrid-Use-1977e089

 

For more details checkout the Microsoft document site https://azure.microsoft.com/en-gb/pricing/hybrid-benefit/

Azure

Azure: Installing GNOME desktop and xRDP to access an Ubuntu 17.10 Server

Microsoft is continually working with different Linux communities to add evermore distributions to the Azure Marketplace. Running Linux machines in the cloud brings with it a number of benefits such as additional stability, security and affordability over that of its Windows counterpart. With Linux now running on two out of every five server instances on Azure, interaction with Linux based systems is becoming an ever increasing occurrence for system administrators.

SSH is the default method when connecting to an Ubuntu server deployed from the Azure Marketplace. For seasoned Linux admin this is fine but for anyone new to the operating system or looking for a quick method of troubleshooting, this style of administration can initially seem daunting or time consuming.

This article shows the steps involved in installing the GNOME desktop and xRDP package on an Ubuntu virtual machine running in Azure. This makes available a more familiar and user friendly remote desktop style connection.

Assumptions

The following assumptions have been made:

    • Ubuntu Server version 17.10 has been deployed from the Azure Marketplace
    • GNOME will be the chosen desktop interface
    • SSH access is available
    • PuTTY will be used as the SSH client
    • Azure Portal access is available.

Installing Gnome Desktop

Although Ubuntu 17.10 “Artful Aardvark” has dropped the Unity 7 desktop, instead of switching to GNOME Shell, the Azure Marketplace image is deployed without the desktop package installed. It is worth noting that it’s possible to install xRDP without installing a desktop first, however, the user experience would be similar to that of the terminal experience offered when connecting by an SSH client.

Installing GNOME desktop over a terminal session might sound difficult, although in reality, it’s actually a relatively straightforward task. The first step of the process is to remotely connect to the server using an SSH client such as PuTTY and then install the applications from the Official Ubuntu Repository.

Open up PuTTY and using the IP address of the server which can be found on the Overview blade in Azure, configure and establish an SSH connection.


Once the SSH session has been established, go ahead and log in to the server.


Before we look to install the desktop, let’s go ahead and update the package list to make sure we have information on the newest versions of the packages and their dependencies. To accomplish this, we run the following command.

sudo apt-get update


We can now begin the desktop install. This is again done by issuing a fairly simple apt-get command from within the terminal session.

sudo apt-get install ubuntu-gnome-desktop


Installing xRDP

Now the desktop has been installed, it’s time to install xRDP. This is an open source remote desktop protocol (RDP) server, which allows you to RDP to your Linux server from a Windows machine. It is capable of accepting connections from rdesktop, freerdp, and remote desktop clients.

To install the package, run the following command.

sudo apt-get install -y xrdp


Configuring  Console Access

Console access is restricted to root by default which essentially means that without making any further changes, connections by anyone else will be dropped. This is obviously not the required user experience, therefore access to the console will need to be configured for all users.

To change access from root only to all users we simply edit the file /etc/X11/Xwrapper.config

This can be done by using an editor such as nano to manually change the line allowed_users=console to allowed_users=anybody.

Alternatively, it can also be updated by running the following command to make the changes.

sudo sed -i 's/allowed_users=console/allowed_users=anybody/' /etc/X11/Xwrapper.config


Adding a Network Security Group rule for RDP traffic

This article is based on an Ubuntu server that has been deployed from the Marketplace. As such, the machine will have been deployed with an NSG that has been configured to manage inbound and outbound traffic. By default, this will only allow port 22 inbound for SSH communication, not 3389 which is required for an RDP connection.

From within the portal, select the servers networking settings before then clicking on “Add inbound port rule”


At this point you will be presented with a new blade in which the following settings need to be configured.

  • Service
  • Priority
  • Name
  • Description


As with most things in Azure, it is worth noting that this could also be done through PowerShell or Azure CLI.

Connecting via RDP

Now it’s time to check if the server is configured correctly and allowing RDP connections.

If you’re connecting from a Windows machine, go ahead and start up the Remote Desktop Connection client. Enter the public IP address of the Ubuntu Server and click on connect.


At this point, the xRDP login screen should appear. Go ahead and provide user credentials before selecting OK.


The first time you remotely login to the Ubuntu desktop, you will be presented with the following Authentication Required popup.


Clicking the cancel button a number of times will close the message and allow access to the desktop, although it will return on the next login. To subdue the message permanently, changes to the polkit configuration will need to be made.

To make the required changes, use the following command to create a file called 02-allow-colord.conf in the following location /etc/polkit-1/localauthority.conf.d/ remembering to use admin privileges.

sudo nano /etc/polkit-1/localauthority.conf.d/02-allow-colord.conf


Once nano has created and opened the file for editing, paste the following text into the file, before exiting and saving.

polkit.addRule(function(action, subject) {
if ((action.id == "org.freedesktop.color-manager.create-device" ||
action.id == "org.freedesktop.color-manager.create-profile" ||
action.id == "org.freedesktop.color-manager.delete-device" ||
action.id == "org.freedesktop.color-manager.delete-profile" ||
action.id == "org.freedesktop.color-manager.modify-device" ||
action.id == "org.freedesktop.color-manager.modify-profile") &&
subject.isInGroup("{group}")) {
return polkit.Result.YES;
}
});


If everything has gone to plan, the next time you login, no authentication message should be displayed.


Missing Gnome Desktop Dock

The other thing that you may notice when connecting remotely, is that the Ubuntu Dock is not visible. Having searched around the internet for a fix for this, the best solution I came across, was actually to install the Gnome Tweak tool which in turn then made it possible to enable both the Ubuntu appindicators and Ubuntu dock extensions. For some reason, the extensions tab appears to be missing from the default Systems Settings menu.

To install the Gnome Tweak tool, run the following command.

sudo apt-get install gnome-tweak-tool -y

Once installed, simply open the Tweak tool, select the Extensions tab and enable both the appindicators and dock extensions.


Now when connecting to the GNOME desktop, the Dock should be visible on the left-hand side of the screen.


That’s it!

In this post, we took an Ubuntu server running in Azure, installed the GNOME desktop and xRDP package, then followed up by making the necessary tweaks required for more streamlined user experience. Connecting to an Ubuntu server by remote desktop connection may not be enabled out of the box but hopefully, this article goes to show that it is still an option when administering Linux based machines in the cloud.

Azure

Azure: Disabling the Windows Firewall on an virtual machine from the portal

The RDP client is one of the most heavily utilised tools in a system administrator’s toolkit. There are alternatives, for example, console access, PowerShell, iLO or in the case of a physical machine the locally connected keyboard and monitor. This is fine for on-premise machines but for machines running in the cloud, most of the alternative methods are not an option and RDP becomes a critical method of connectivity.

Over the past months I have seen an increase in the number of customers that have adjusted the guest Windows OS firewall, inadvertently locking themselves out and making it impossible to manage their Azure virtual machines.


The following article outlines one of the methods I have successfully used when restoring access. This method makes use of the Azure virtual machine Custom Script Extension and a snippet of PowerShell.

1. The first step is to open your preferred PowerShell editor and paste in the following code.

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\services\SharedAccess\Parameters\FirewallPolicy
\DomainProfile' -name "EnableFirewall" -Value 0

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\services\SharedAccess\Parameters\FirewallPolicy\
PublicProfile' -name "EnableFirewall" -Value 0

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\services\SharedAccess\Parameters\FirewallPolicy\
Standardprofile' -name "EnableFirewall" -Value 0

These commands update local registry values which in turn disables the three firewall profiles on the next machine reboot.

A copy of the file can be downloaded from my GitHub disablefw.ps1.


2. Save the file as <filename>.ps1

3. Now login to the Azure portal and browse to the virtual machine that is having connectivity problems.

4. From the blade of the virtual machine, select Extensions


5. Click the +Add button and select Custom Script Extension from the popup menu.


6. Click on the folder icon to browse to where the <filename>.ps1 file has been stored and after selecting the file, click Open to upload it.


7. The virtual machine extension can now be installed by clicking OK.

NOTE: Additional Arguments are optional and for this task should be left blank.

8. Once the extension is installed, the Azure portal will report that provisioning has been successful.


9. It’s now time to restart the virtual machine before retrying an RDP connection.


This has proven to be very useful to me on a number of occasions, hopefully it will be of assistance to others.

As always, if any mistakes are spotted, feel free to leave me a comment.

IaaS

Azure IaaS: Resize VM disks in Azure

I have recently encountered a couple of situations where it has been necessary to resize disks attached to Azure virtual machines. Generally it has been on machines that have previously been migrated to Azure from their original on-premises infrastructure where storage was more of a premium.

When deploying machines directly in Azure its generally felt that deploying the largest disk possible is the best option. This is because regardless of the disk size, charge is only made for the actual amount of data written to the disk and not the size of the disk itself. The exception to the rule is when using premium storage which is the reverse and charged on the size of the disk and not the amount of data written in it.

In this example the operating system disk is nearly full and needs to be increased in size.

diskresize001
The easiest way to achieve this is to use our old friend PowerShell and the Update-AzureDisk cmdlet.

The first thing that must be done is to work out the disk name of the disk that needs to be resized. This can be done in various ways but generally its easiest to use either the Azure Portal or PowerShell.

Open the Azure portal then select Virtual Machines > Machine Name > All Settings > Disks and locate the disk name.

diskresize002
As mentioned its also possible to use PowerShell to pull back a list of all disks deployed in the current subscription from which their names and other attributes can be gathered. The first step is to connect to Azure and check that we are connected to the correct subscription.

Add-AzureAccount

Get-AzureSubscription -Current

To select an alternative subscription use the following PowerShell command.

Select AzureSubscription -SubscriptionID "Subscription ID"

Now connected to the subscription we require, its possible to search for a list of disks and the virtual machines that they are associated with.

Get-AzureDisk | fl Label, AttachedTo, DiskName

diskresize004
Having collected all the details required, it’s possible to use the next PowerShell command to resize the disk.

Update-AzureDisk -DiskName <diskname> –ResizedSizeInGB <size in GB> –label <labelname>

For Example:

Update-AzureDisk -DiskName TechKB-SVR01-TechKB-SVR01-0-201601281807180110 –ResizedSizeInGB 500 –label sysDrive

diskresize005
NOTE: The size of the updated disk must be between 20-1023GB and the Azure virtual machine must be powered off and in the deallocated state for the command to complete successfully.

diskresize003
After the command runs successfully its possible to view the resized disk in the Azure portal.

diskresize006
Once the disk has been successfully resized, the guest OS needs to be configured to use the additional space now available on the disk.

From within the guest open Disk Manager > Right Click System Volume > Expand Volume and follow the wizard through to add the extra space to the system volume.

diskresize007
Now when browsing in File Explorer the system drives displays the new volume size.

diskresize008