This post will show how to use Azure AD Domain Services (AAD-DS) with SUSE Linux Enterprise Server (SLES).
A customer asked how they might use AAD-DS with SLES 11 SP4 to test their product. I am very familiar with Windows but still very much a Linux novice, and there seems to be no easy documentation that shows how to walk through this end to end. There are steps for Red Hat Enterprise Linux (https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-admin-guide-join-rhel-linux-vm), but I couldn’t find steps to do this on other Linux distros. The package managers are different (SLES uses zypper, RHEL uses yum, Ubuntu uses apt-get), and the packages to use and instructions for configuring are cryptic and archaic. Turns out it’s really easy to domain join a machine using SLES.
What is Azure Active Directory Domain Services
The Azure Active Directory service does not directly provide NTLM, Kerberos, or LDAP, it provides WS-Trust, OpenID Connect, and OAuth capabilities. Applications hosted in Azure virtual machines may need these legacy authentication capabilities but can’t afford the latency of communicating back to on-premises infrastructure, requiring domain controllers to be hosted in the cloud. Many customers do not want to install their own domain controllers in cloud-hosted virtual machines, configure a VPN or ExpressRoute, and manage AD replication to on-premises domain controllers. This is exactly what Azure AD Domain Services (AAD-DS) provides: a managed domain controller with the same users and groups as your AAD directory. AAD-DS makes it easy to join a virtual machine to the managed domain so that your application can use NTLM, Kerberos, or LDAP with the same credentials that they use to log into Office 365 or Azure services.
Azure AD Domain Services will provision managed domain controllers into the Azure Virtual Network that you specify. In this image, the managed domain controller virtual machines are greyed out, indicating they are there but you can’t access them or do anything with the virtual machine directly, you simply use the familiar Windows Active Directory Domain Services (ADDS) as a service.
In this picture, AAD-DS is enabled for the directory, creating two virtual machines in the subnet of my choice. My application server can now communicate with those domain controllers to domain join the machine and enable authentication and authorization. Azure AD Domain Services works with either cloud-only or hybrid directories. If there is an existing ADDS infrastructure on-premises, you sync users to the AAD directory using HTTPS to enable single sign on to cloud resources such as O365.
The documentation to set up Azure AD Domain Services is pretty easy to follow, including screen shots. Nothing to install on your machine, nothing to configure locally, just go to the Azure portal and follow the directions:
The result is an Azure classic virtual network with the settings you chose.
Editor: At the time of this writing, AAD-DS only supports classic vnets. I don’t have insight to the product team’s plans if they are going to enable ARM-based VNets, but I sure hope so.
If I need to add users or groups, I do this using Azure AD.
I also have a group that contains the users who are administrators of the AAD-DS domain, enabling them to configure things like service principals and constrained delegation.
I can now add a Windows virtual machine to the same virtual network and join the machine to the domain blueskyabove.onmicrosoft.com. Note that I am using a cloud-only directory, there are no users sourced from on-premises, so when I am prompted by Windows for the credentials to join a machine to the domain, I use my cloud-only account firstname.lastname@example.org, and when I RDP to my new WIndows VM I use the same credentials.
Once logged in, open PowerShell and run the command:
Add-WindowsFeature -Name RSAT-ADDS-Tools
This command will add the Active Directory tools such as Users and Computers. Now you can view the domain information from your new Windows virtual machine.
OK, enough Windows, let’s go look at the Linux stuff we promised in the beginning of the post!
Create a SUSE Linux Enterprise Server Virtual Machine
In the Azure portal, create a new SUSE Linux Enterprise Server virtual machine in the same VNet that you used previously. Filter for “SUSE” and choose your starting image. I chose SLES 11 SP4.
IMPORTANT!!! Make sure to create a VM using the Classic deployment model so that it can be placed in the same VNet!
The next step enables you to provide your SSH login information and SSH public key (for more information, see https://docs.microsoft.com/en-us/azure/virtual-machines/linux/mac-create-ssh-keys).
Choose a size. A DS1_v2 machine is plenty for my quick demo.
Create or choose a storage account and cloud service (I used the same cloud service I used with my Windows VM above). The important point here is that you use the same virtual network that is configured for Azure AD Domain Services.
After a few minutes, the VM is created and I can SSH into it. I am using the Windows Subsystem for Linux, just open a command prompt and type “bash” to open the bash shell, and then I can run my SSH commands.
Editor: I received a few weird errors while trying to provision the VM, mentioning something about a certificate thumbprint cannot be found. I kept trying and it finally worked. Sometimes I guess you have to click harder.
SSH Using Your Certificate
We haven’t yet joined the VM to the domain, so we will SSH using the details we provided when creating the Azure VM. Once the VM is created, open the VM to see its public IP address.
Note that the public IP can change if you restart the Azure virtual machine. Now, go to the Endpoints property of the VM to see which port to use for SSH.
Finally, SSH: ssh -i azure_ssh email@example.com -p 60252
Domain Join SLES Using YaST
The last bit we need to do is to join to the domain controller that Azure AD Domain Services provides for us. Since the VM is in the same VNet and we have updated the DNS settings for the VNet, the new Linux machine can locate the domain controller by name without any further configuration with “sudo /sbin/yast”.
This opens up the YaST control center. Choose Network Services / Windows Domain Membership.
You are prompted to install the Samba client packages.
Next, provide your domain as all capital letters, and enable the settings in the top section to enable users to SSH to the machine using their credentials from Azure AD. Note that I am using a cloud-only directory without a custom domain. If you added and verified a custom domain, and have users from that custom domain in your AAD directory from a sync, then you should use your custom domain.
Editor: Backspace doesn’t work for me, I had to use CTRL+H to backspace. Dunno.
Once you are done, exit and reboot the VM.
You may be wondering what the YaST tool just did for us. For a comprehensive look at the files it edited and the values it used, see https://jreypo.wordpress.com/2012/02/01/how-to-integrate-suse-linux-enterprise-11-with-windows-active-directory/.
You can now log in using the same credentials that you use to log into Azure AD.
ssh blueskyabove\\firstname.lastname@example.org -p 62075
You can now SSH using your credentials from Azure AD and the user has a home directory that was created.
The user is not in the sudoers group. It is possible to enable users from a particular Active Directory group to use sudo.