Last Thursday a new preview feature in Azure was announced for which I was very excited about: AAD Authentication to Windows/Linux VM’s on Azure.
What does this mean exactly? If you want to login into a VM with AAD credentials, why don’t you just join it to Azure Active Directory? Well…, this is true for Windows 10 but this is not supported for Windows Server & Linux servers. This is why this announcement is pretty huge for customers that don’t have any on-prem servers (and want to avoid AADDS).
This preview is currently in preview for the following Operating Systems:
- Windows 10 1809
- Windows Server 2019 Datacenter
- CentOS 6/7
- Debian 9
- OpenSUSE Leap 42.3
- RHEL 6/7
- SLES 12
- Ubuntu 14.04 LTS
- Ubuntu Server 16.04/18.04
Before going any further: remember that this feature is still in preview and shouldn’t be used in production.
Configuring this for new machines is actually pretty easy!
While creating a VM, go to the management tab and select ‘On’ next to ‘Login with AAD Credentials’.
If you choose a template that does not contain one of the supported OS, you will receive the following error message:
But what exactly is happening in the background while we enable this? The process itself is pretty simple, there isn’t anything configured within the template itself. There is just an extra extension ‘AADLoginForWindows’ that is installed on every VM.
Because we know that this extension needs to be installed for this feature to work. Enabling this for existing machines is pretty easy. Installing this extension through the GUI is not possible (probably because this is a preview feature). Enabling it goes through the Azure CLI with the following command:
az vm extension set --publisher Microsoft.Azure.ActiveDirectory --name AADLoginForWindows --resource-group VMTemp --vm-name DCTest123
After you run this command, a reboot of the VM is needed before the extension is fully deployed.
Remember that this feature only works with a few supported Operating Systems (mentioned in the beginning of this post)
There are two different role assignments that come with this feature:
- Virtual Machine Administrator Login
- Virtual Machine User Login
These roles are pretty self-explanatory:
- The first one gives the user the permissions to log into the machine. When he logs in, he will be a local administrator on the server.
- With the ‘VM User Login’ a user can log into the VM as a regular (non-admin) user.
Be aware that an owner doesn’t receive these permissions by default. If you, as a resource owner, want to log into the VM through AAD you need to explicitly grant yourself this permission.
Logging into a Windows Machine
Logging into the VM through AAD is pretty simple, just open up an RDP file, fill in the IP address and authenticate through Azure Active directory.
If we check the account settings, we can check that we are logged in through AAD.
Logging into a Linux machine
Logging into a Linux machine happens through a device login through Azure CLI. Just start an SSH command, specify your UPN & correct IP.
This process is really easy and seamless! The real downside to this method is that no SSO is possible.
What is going on in the background?
But what is exactly happening in the background that is making this process possible?
If we run the dsregcmd /status command on a Windows Server VM, we will see that this device is Azure AD Joined:
We can also view this same device in the AAD portal:
When doing this process for a Linux machine, the Linux VM does not show as AAD Joined in AAD.
If we check the local administrators group, we can see that two (nameless) groups are created.
Be reminded that logging to in AAD joined machine is only possible from a machine that is (hybrid joined) to the same AAD domain.
In Windows 10 20H1 support will be added to support signing-in from Azure AD registered devices. I have tested this on my WIP machine, but didn’t get this to work.
The beauty of logging into a VM through AAD is that we can utilize Conditional Access to limit access to these machines.
In the background an ‘Azure Windows/Linux VM Sign-in’ application is created. We can use this application in Conditional Access to require extra conditions.
If you require MFA and log into a Windows VM, you need to log into the computer from where you will connect with Windows Hello For Business. Because that is registered as a second factor (next to your password). Otherwise you will receive the following error:
Requiring MFA to log into Linux VM’s is seamless because logging in can be done through device login.
Because of the ability to require MFA or limit connections to a certain physical location, this set-up is really interesting for a Priviliged Access Workstation set-up.
Future of this feature
This preview is really looking good at the moment. I haven’t had any issues with it myself and I really like where this is going.
The missing piece in the puzzle for me is Azure Bastion support. This would be users could log into an Azure VM with AAD through a browser!