Azure AD Login for Azure Linux VMs
This post will discuss what Azure Active Directory Authentication for Azure Linux virtual machines is, how to configure it, and how to login.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
Note that this is a preview feature. Most of the time, preview features are supported for production workloads but this time, Microsoft has stated:
This feature is in preview and is not recommended for use with production virtual machines or workloads. Use this feature on a test virtual machine that you expect to discard after testing.
It is a cool new feature and it is worth having a look at. At this time, it only works with the following Linux distributions but in all regions, except for the sovereign/government clouds:
- CentOS 9 and 7.4
- RedHat Enterprise Linux RHEL 7
- Ubuntu 14.04 LTS, 16.04, and 17.10
Windows Server support is scheduled for later this year.
Microsoft’s documentation explains how you can deploy the setting using CLI (an alternative to PowerShell) but it is possible to deploy using the Azure Portal, as I will show here.
What Is Azure AD Authentication
Normally you sign into a Linux virtual machine using a local username with a password or SSH key. It is possible to join machines to a central authority, such as Active Directory Domain Services (or Azure AD Domain Services), but Active Directory is not always suitable. With this new preview feature, you can get server/application administrators/developers to sign in using their corporate credentials via Azure AD without any kind of domain join. Benefits include:
- Single sign-on: A user has only 1 username to remember.
- Improved auditing: Auditing in the guest OS will identify users, not just “admin”.
- Stronger credentials: Passwords aren’t shared and/or documented and are more likely to be stronger over time.
- Reduced operational workloads: You don’t need to create an account for every user on every machine.
- Azure AD features: Multi-factor authentication, auditing, self-service password reset all become possible, assuming you have sufficient per-user licensing for Azure AD.
An extension (AADLoginForLinux) is installed in the virtual machine to enable integration with Azure AD.
To be able to sign into a virtual machine, an administrator’s or user’s account (or a group they are a member of) must have been granted access via Role-Based Access Control – being an owner/contributor over the virtual machine is not enough!
Deploying Azure AD Authentication
There are two ways that you can deploy the AADLoginForLinux extension into an Azure virtual machine. The first is to enable it in the Basics blade while creating the virtual machine:
Another option is to add the AADLoginForLinux extension to an existing Linux virtual machine using CLI. The easiest way to run CLI is to launch the (Linux) Cloud Shell from the Azure Portal – click the >_ button in the top-right of the portal. Then run the following command, swapping your virtual machine name and its resource group name:
az vm extension set --publisher Microsoft.Azure.ActiveDirectory.LinuxSSH --name AADLoginForLinux --resource-group petri --vm-name vm-linux-01
It will take a minute or two for this installation to complete.
Role-Based Access Control (RBAC)
You will need to grant people rights to sign into the virtual machine. This is the case even for subscription owners and contributors because being a subscription owner doesn’t mean you should have rights to the guest OS!
Authentication is done using Azure AD user accounts/group and resource permissions. Since the days of Windows NT, the best way to do permissions is users > groups > permission. I have created a group with some member users.
You can assign permissions at three levels:
- Subscription or global access
- Resource group, application or logical grouping access, and easy to manage
- Virtual machine (resource), with very granular control but difficult to manage
In my example, I will set permissions at the resource group level. I have opened the resource group that contains my Linux virtual machines and clicked Access Control (IAM). A popup blade called Add Permissions appears when I click + Add.
There are two possible roles/permissions that I can grant:
- Virtual Machine Administrator Login: The logged-in user is granted local administrator rights in the guest OS – Windows Administrator for Windows and root for Linux.
- Virtual Machine User Rights: The logged-in user has no administrator rights.
In my example, I am granting Virtual Machine Administrator Login rights to the group that I created earlier:
When I attempt to sign into the Linux virtual machine now, I can use my Azure AD user account. This can be seen in the login command that the Connect To Virtual Machine popup blade shares when you click Connect in a Linux virtual machine’s blade.
I am using PuTTY in my example. When the Sign In prompt appears in the SSH session, I will enter my Azure AD username. At this time, I am prompted to browse to https://microsoft.com/devicelogin and enter a one-time code. I will then be asked to sign into Azure AD (your Azure sign-in) if I am not already signed in.
I was already signed into the browser because I had a tab open in the Azure Portal. I didn’t have to enter my password at all!
Once I am signed in, I can close the browser tab and press Enter in the SSH session. I will be signed into the Linux guest OS at that point: