Taking a look under the hood of the Linux VM Authentication

Introduction

Today we’ll do a deep-dive into how you can log into an Azure Linux VM with Azure Active Directory (AAD). In essence, we’ll go through the following documentation flow, and then take a look how that looks under the hood.

 

Part one : “Creation”

The part on creating & integrating the VM is VERY straightforward…

  • Create a resource group
  • Create a Linux virtual machine
  • Add the “Azure AD login VM”-extension

And that’s it! Really, that’s it…

 

Part Two : “Plain Login”

First let’s try a “plain” login via the local user we setup during creation… As we generated certificates, we did not need to enter any password (manually). And as you can see, that went smooth.

 

Part Two : “Configuring AAD Users”

When we added the “Azure AD login VM”-extension, we enabled to ability to login from AAD to this system. As you can imagine, by default nobody can login… So we’ll need to grant users permissions to do so. How can you do this? Simply by adding the user with one of the following roles to the virtual machine’s IAM ;

  • Virtual Machine Administrator Login: Users with this role assigned can log in to an Azure virtual machine with Windows Administrator or Linux root user privileges.
  • Virtual Machine User Login: Users with this role assigned can log in to an Azure virtual machine with regular user privileges.

 

So how would that look? Let’s see… When following the example, we can go via the CLI commands.

After which you’ll see the user being added to the IAM / Access Control ;

Where you could have done this via the Portal or any other means you wanted…

 

Part Three : “Testing AAD Integration”

What about we’ll test this part?

Which does what is needs to do… No surprise there I guess? 😉

 

Part Four : “Looking under the hood”

If we would take a look under the hood… We’ll notice that “the magic” happens to be a pam module (Pluggable Authentication Modules for Linux). Where can you see this? Check out the following file /etc/pam.d/common-auth ;

And you’ll notice that the first intercept is by a module called “pam_aad.so”.

As you can also notice, when doing a “whoami”, you’ll get back the “UPN” (user principal name ~ email) of the logged in user. Now let’s do a quick test to see what uid/gid we have… When I created a test file, I notice that I’m given the uid “7235647”.

Here I’m still not sure how I can tweak this and how portable this is over systems… Though be aware of this behaviour.

 

Closing Thoughts

The AAD integration has proven to be very easy to implement. The integration is done via the common PAM (Pluggable Authentication Modules for Linux) architecture, where authorization is also done by leveraging the IAM / Access Roles of the Azure VM itself. The latter makes it nice and easy to do central management (in my humble opinion). If you have any comments, feel free to provide feedback to the team on this!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.