Jan Hajek

Microsoft MVP, Technical Fellow

2 minute read

To be honest, managing authentication in Linux for multiple users/admins can be a huge pain. Different companies use various tools - generally, they use a centralized tool to distribute developer’s SSH keys. This can still be a pain, however if the company has Azure AD (or Office 365), why not to use those accounts for authentication? One of the SSH key distribution tools is Teleport SSH server for example.

Leveraging Device Code flow

If you ever used Azure CLI (or logged in to YouTube/Spotify/Facebook on Xbox), you have already experienced a device code flow. Basically, if the client cannot offer interactive login session, the server is going to generate a short-lived (15 minute) single use code, which you can use on another device to authenticate towards the requested resource. Device code is explained in-depth here for example or refer to the IETF’s draft. There are some solutions in the wild, which offer Azure AD authentication however, those don’t support MFA enabled users since they expect you to type your password directly into the SSH console and then try to authenticate with it in the plaintext (using password grant). Due to the password input and lack of support for MFA, I didn’t really like those solutions. Then suddenly, I discovered Cyclone Project’s implementation fo the PAM authentication. Built in Python and leveraging pam-python project, I decided to re-use some parts of their code. Their federation server doesn’t directly support the device code flow, so what they do is that they boot up a tiny web server which you then access from your device and use it to login which actually mimics the device code flow in Azure AD (Azure AD leverages polling rather than running a local webserver). Thanks to Azure AD, I could remove most parts of their code and leave the heavy-lifting to ADAL for Python.

Support in other apps

One of the very nice features is that this flow is even supported in applications like WinSCP! Thanks to that, your users can also access the files using SFTP protocol.

Next Steps

Since we would like to deploy this solution to our production servers the next steps are to add support for creating user accounts (eventually add support for temporary accounts as well) for incoming users from Azure AD and some advanced RBAC support.

Try it out!

You can find a working Proof of Concept on our GitHub. Please note that the code is not production ready, however I would welcome any Pull Requests and improvements.

Comments

noobient

AD login already works (and has been for years) with SSSD on Linux. Including sudo access controlled via AD sudoroles (the sudo source code actually includes the schema you need to extend AD with). If you don’t have local AD, you can also use SSSD to join to Azure AD:

https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-join-rhel-linux-vm

So I’m not quite sure what you’re trying to achieve here.

Jan Hajek

The point was to actually not having to use ADDS/Azure AD Domain Services at all and leverage modern authentication including conditional access and MFA which is not offered by any of the solutions you mentioned. Microsoft has already made their own implementation which allows you to do exactly this without having to have ADDS or AADDS - https://docs.microsoft.com/en-us/azure/virtual-machines/linux/login-using-aad and you simply assign permissions to that machine in the Azure Portal which is pretty cool. This was just an attempt to implement this before Microsoft built it on their own.

Anonymous Poster

Hi Jan, Thank you for posting this. It is most helpful as a starting point.There are not many clear documents that talk through Azure authentication and Linux in the wild so your effort is highly appreciated.

To submit comments, go to GitHub Discussions.

You May Also Enjoy