Active Directory Authentication with CentOS

Active directory authentication for CentOS is quite easy to configure. Active directory is a central authentication system and organisations all over the world have relied on it for years. This is super easy to set up for your Windows and Mac desktops but is sometimes a little harder with a Linux workstation. This is all done on a CentOS 6.5 minimal install with nothing but a LAMP stack installed.

There are is one step you need to take to get your machine ready for configuration. Install the following packages, if they aren’t already.

# yum -y install authconfig krb5-workstation pam_krb5 samba-common oddjob-mkhomedir

This will install everything you need to get up and running. There is two ways you can configure the authentication. From the command line (authconfig) or via a console GUI (authconfig-tui). It all works just depends on which version you are comfortable with.


# authconfig --disablecache --enablewinbind --enablewinbindauth --smbsecurity=ads --smbworkgroup=DOMAIN --smbrealm=DOMAIN.COM.AU --enablewinbindusedefaultdomain --winbindtemplatehomedir=/home/DOMAIN/%U --winbindtemplateshell=/bin/bash --enablekrb5 --krb5realm=DOMAIN.COM.AU --enablekrb5kdcdns --enablekrb5realmdns --enablelocauthorize --enablemkhomedir --enablepamaccess --updateall

This will setup the necessary config files for both Kerberos and Samba. There is more config files to update from here. 

Please Note: When I ran this I got an error with Oddjobd not being able to start. You can read the details in this post. Just make sure that the messagebus service is running.

Kerberos (/etc/krb5.conf

Check that the file was generated and then add the relevant realms and domain_realm for your domain to the file. If you have multiple domain controllers you can add extra kdc lines like below.

 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

 default_realm = DOMAIN.COM.AU
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true

 kdc =
 admin_server =

admin_server =
kdc =
kdc =


Save the file and test that it works using the kinit command.

# kinit someaduser

A password prompt will be displayed, type in the active directory password for that user and it should return to the prompt with no messages. You can then check that you have your kerberos ticket by running the klist command. It should output something like the following.

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [email protected]

Valid starting Expires Service principal
02/27/14 12:23:21 02/27/14 22:23:21 krbtgt/[email protected]
 renew until 03/06/14 12:23:19

Join the Domain

You’re now ready to join the machine to the domain. You can use the trusty net command to join the machine to the domain.

# net ads join -U someadadmin

You can test that this worked running the following command

# net ads testjoin
Join is OK

Console GUI

The other option to configure AD authentication is to use the console GUI version of authconfig. This will pop up a familiar looking interface (think console RedHat installer) that is pretty straight forward when it comes to configuration. Start the GUI tool

# authconfig-tui

You will get a screen like the following, make sure that only the items checked are the same as below.


User Information

  • Use Winbind


  • Use Shadow Passwords
  • Use Kerberos
  • Local authorization is enough

Make the above selections then next and you’ll be on the kerberos settings screen


Settings for this screen are as follows:

Admin Server:

On the next screen you will find the Winbind Settings


Settings for this screen are as follows:

Security Model: ads
Domain: DOMAIN
Domain Controllers:,
Template Shell: /bin/bash (you can change to sh if you’d like)

Select Join Domain

You’ll be prompted to save the details


This will overwrite any other settings you would have had configured for this machine. You will then be prompted to provide domain admin credentials.


This will run the following command behind the scenes and then join you to the domain.

/usr/bin/net join -w DOMAIN -S -U Administrator

Note: If for any reason this doesn’t work in authconfig-tui. Select OK and return to the prompt and manually run the command above.

Home Directories

You don’t really need to do this step but I find it’s a nice clean way to make sure you separate domain users from your local users. Back in the authconfig step for the console configuration you used the following switch

--winbindtemplatehomedir=/home/DOMAIN/%U --enablemkhomedir

These switches enabled automatic creation of home directories. For this to work with the GUI version you will need to run authconfig with those 2 switches.

authconfig --winbindtemplatehomedir=/home/DOMAIN/%U --enablemkhomedir --update

This is telling oddjobd to put any new home directories at the path /home/yourdomain/username. You will need to create the /home/yourdomain path and make sure you’ve got your permissions correct. I’ll be using ACLs as you’re able to configure much finer grain permissions. ACLs ship with pretty much all modern linux distributions these days.

# mkdir /home/DOMAIN
# setfacl -m group:"Domain Users":rwx /home/DOMAIN

Please Note: There is a bug in oddjobd-mkhomedir that is creating the home directory with the 755 permissions which allows group and world to read every home directory. You can read the bug on Red Hats Bugzilla.

Restrict AD Logins (Optional) 

In my environment I only want to allow the linux admins to use their AD logins to SSH to the servers I have configured. You can restrict which AD groups can login to the machine by adding the AllowGroups directive to the sshd_config and restarting sshd.

# echo 'AllowGroups linuxadmins' >> /etc/ssh/sshd_config
# service sshd restart

This will echo the required groups into the sshd config and then restart the service. This will now restrict ssh logins to those specific groups. If you’d like to configure AD access to more services you will have to check elsewhere. If I find the need to do this myself I’ll update this documentation to include it.

Share :

Related Posts

Join me as I unveil my ultimate developer workspace for 2024. Discover how I've transformed a basic setup into a cosy, productivity-boosting environment from tech to ergonomics.

I have been struggling for a couple of days working with Google Cloud Scheduler and Cloud functions for a project I’m working on. I’ve been working with functions for a while now. It’s a good idea to secure all your functions so that only other cloud services can access them. This can be done using […]