Authenticating Linux with Amazon’s AWS Directory is Easy

Written by Rajat Bhargava on October 23, 2014

Share This Article

Yesterday, Amazon announced its Directory Service offering – a new service which assists AWS users who are growing their hybrid (on-prem/cloud) infrastructure by helping provision users on Virtual Private Clouds (VPCs). We decided to have a look at their new offering and walk through a standard use case which users of JumpCloud’s Directory-as-a-Service are very familiar with: provisioning users on Linux hosts.

It should be noted that AWS Directory Services is not yet aimed at Linux devices. In their announcement Amazon talked about supporting Windows devices, but since many AWS customers are leveraging Linux instances, we wanted to walk through the process and also understand how our JumpCloud’s DaaS offering could complement AWS’ offering when it comes to managing Linux users.

It wasn’t as easy as we’d hoped — AWS DS does not make it easy to integrate LDAP server authentication against your EC2 instances — but the positive takeaway from this exercise is that both solutions can work together nicely.

Getting Started with AWS Directory Services

Discovering the feature was easy, as it is now offered as a menu selection within the AWS console. We chose to leverage the creation of a new directory, versus connecting to an existing Microsoft Active Directory. Doing so will instantiate the creation of a SAMBA-based directory core.

Creating the AWS Directory

The process within AWS was fairly straight forward, assuming the sysadmin’s knowledge of the networking infrastructure.

Blog Image - 1

TECH NOTE: AWS Users outside of Amazon’s East Zone will not have access to Amazon’s Directory Service as it is limited to that Availability Zone.

Blog Image - 2-_Google_Docs
Blog Image - 3

With our new SAMBA-directory ‘created’, we were then in a holding pattern for the database/directory to be finalized and provisioned to our VPC, a process which took 11 minutes to complete.

Blog Image - 4

The SAMBA directory is now live and we were ready to begin our use case testing, getting a user provisioned to a Linux host…

Blog Image - 5

Detailed View:

Blog Image - 6

What we initially discovered was this: our sysadmin returned to the AWS console to look for User Administration interfaces but none were available. What we didn’t realize was: in establishing the SAMBA directory on AWS, we would still need to utilize other management tools in order to ‘operate’ it. As a result, we spun up another instance, with a Windows 2012 Server and used Microsoft’s Active Directory management tools to interface with our AWS/SAMBA Directory Service.

Configuring the AWS VPC DHCP

To get this process started, our sysadmin navigated through the AWS Dashboard, walking through the DHCP Option Sets to create a new DHCP Option Set.

authenticating linux aws directory services integration LDAP

Managing and Operating the AWS Directory Service

With DHCP set, we now needed to move to standing up tools to manage the AWS Directory Service. Our sysadmin went through the process to build out a Windows instance. This process demanded another block of time, 17 minutes, to perform to bring the Windows Server up live. We were curious as to why we weren’t prompted in this process to have the server auto join the domain, reducing misunderstanding in the connection process.

After concluding the Windows Server build and enabling the Active Directory tools, it was time to join the Windows client to the AWS Directory. In other words, have this new client join the domain in Windows AD parlance. This process required another 11 minutes, forcing a reboot to conclude the connection.

Finally, the Windows AD Tools needed to be employed to start building out Groups and adding in AD Users. Rather than show screen shots here, you can review this documentation on exactly how to do this if unfamiliar with Active Directory. Depending upon size and scope of users and groups in your org, plan on 15-30 minutes.

Configure the Linux Host for Authentication with AWS Directory Service

Now, we’re ready for the final part of our use case – establishing a user on Linux from the AWS Directory Service. First we needed to prep the instance and the following was done from a command standpoint by our sysadmin:

Linux Configuration

For this we used the stock Ubuntu 14.04 LTS build from Amazon.

We will be using realm to do most of the heavy lifting in connecting to the Amazon Directory and authentication configuration but there are some things that we need to prepare first.

Configure name resolution.

For a successful handshake, it is critical that the hostname of the server be resolvable.  According to our sysadmin, the easiest way to do this is to add it to /etc/hosts with its ip (not

As an example…

echo $( ifconfig eth0|grep inet\ addr|awk ‘{print $2}’|sed -e 
‘s/addr://g’ ) $( hostname ) $( hostname ) >> 

Install required packages

sudo apt-get update
sudo apt-get -y install sssd samba-common-bin samba-libs sssd-tools 
krb5-user adcli realmd

TECH NOTE: Users will be prompted for your Kerberos 5 realm. This is your domain name in all uppercase.  (e.g. TEST.JUMPCLOUD.COM)

With the above completed, it is now time to configure the AWS SAMBA instance we established initially above, but still requires further updating.

We need to prepare the ‘triple-S-D’ configuration file for realm.

SSSD Preconfigure

sudo vi /etc/sssd/sssd.conf

Copy the following in.

filter_groups = root
filter_users = root
reconnection_retries = 3


reconnection_retries = 3

And then fix the permissions on it.

sudo chown root:root /etc/sssd/sssd.conf
sudo chmod 600 /etc/sssd/sssd.conf

Next up, configuring Kerberos, an essential part of the authentication mechanism utilized in both Active Directory and AWS’s Directory Service. Our sysadmin included some explicit instructions for this to be done per below.

Configure kerberos for your AWS realm

In your …./etc/krb5.conf …. ensure that default_realm is set to your domain and is all uppercase:

default_realm = TEST.JUMPCLOUD.COM

Then find the section called [domain_realm] and add these lines, changing them to match your domain: = TEST.JUMPCLOUD.COM = TEST.JUMPCLOUD.COM

This configuration should now be tested as follows, this test is required for the next step with realm…

sudo kinit [email protected]
Password for [email protected]:
sudo klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [email protected]
Valid starting       Expires              Service principal
10/22/2014 23:19:19  10/23/2014 23:19:07  
krbtgt/[email protected]

With testing complete it is time to join with the Directory using realm, there is lots of output from realm that we have truncated, the important bit is the last line.

Join the Directory

sudo realm –verbose join 
–[email protected] –unattended
{ … Lots Of Output … }
* Successfully enrolled machine in realm

Now we need to go back and do some post configuration cleanup from what realm did as well as make sure our users have home directories and ssh access.

SSSD Postconfigure

We need to remove the line use_fully_qualified_names = True so that users don’t have to type [email protected], and then restart sssd.

sudo vi /etc/sssd/sssd.conf
sudo service sssd restart

At this point you can test that things are working by running this command:

id Administrator

It should return something similar to this.

uid=1533200500(administrator) gid=1533200513(domain users) 
groups=1533200513(domain users),1533200518(schema 
admins),1533200520(group policy creator owners),1533200572(denied 
rodc password replication group),1533200512(domain 
admins),1533200519(enterprise admins)

In the sssd.conf file you may have noticed that it is configured to put user’s home directories at /home/<domain>/<user>.  This is great but the system needs to know to create this.

Configure Home Directory Creation

You must create a file in … /usr/share/pam-configs/my_mkhomedir … and will essentially look like this:

Name: activate mkhomedir
Default: yes
Priority: 900
Session-Type: Additional
        required               umask=0022 

Once you have that file run pam-auth-update to activate and your directory users will get home directories just like your local users.

One final step remains if your user is going to ssh in, you will need to allow password authentication in ssh as Amazon DS does not have ssh keys in it.   With a restart of the ssh service your linux users can now authenticate against the Amazon DS.

So after some work and exploration with AWS Directory Service, we were eventually able to provision and authenticate a user on a Linux host in our VPC. It’s not trivial or easy — we discovered that the configuration required fairly in-depth expertise which we have on staff via our sysadmin to establish all of the low-level configurations between the Windows AD, the AWS Directory and of course the Linux instance where we wanted the user provisioned.

Total time for the process was roughly 5 hours, 20 minutes, including the configuration, machine builds and reboots, and ancillary research time required during the set-up. Now that we’ve worked out these issues subsequent machines would probably be quicker to get connected of course, but again… not trivial.

As we said at the outset, AWS does not claim that they support Linux systems yet. While they may in the future it appears that this solution is squarely aimed at Windows machines and the process we went through confirmed that. However, for users that are set on using their Linux instances with AWS Directory Services, it is possible but just requires time and expertise.

An alternative to this approach is to leverage JumpCloud’s Directory-as-a-Service solution in conjunction with AWS Directory Services. Linux user management can be done through the quick install of an agent via JumpCloud and users can be managed closely. The nice part is that it only takes a couple of minutes. If you would like to chat with us about how we can help you manage your users on AWS Linux instances, drop us a note and we’d be happy to discuss it with you.

We would like to thank these sites for their help in configuring our Linux host to authenticate against the Amazon Directory:

Rajat Bhargava

Rajat Bhargava is an entrepreneur, investor, author, and CEO and co-founder of JumpCloud. An MIT graduate with over two decades of high-tech experience, Rajat is a ten-time entrepreneur with six exits including two IPOs and four trade sales.

Continue Learning with our Newsletter