Archives for March 2014

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.

</p>
<p># yum -y install authconfig krb5-workstation pam_krb5 samba-common oddjob-mkhomedir</p>
<p>

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

<br />
# 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</p>
<p>

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.

<br />
[logging]<br />
 default = FILE:/var/log/krb5libs.log<br />
 kdc = FILE:/var/log/krb5kdc.log<br />
 admin_server = FILE:/var/log/kadmind.log</p>
<p>[libdefaults]<br />
 default_realm = DOMAIN.COM.AU<br />
 dns_lookup_realm = false<br />
 dns_lookup_kdc = false<br />
 ticket_lifetime = 24h<br />
 renew_lifetime = 7d<br />
 forwardable = true</p>
<p>[realms]<br />
 EXAMPLE.COM = {<br />
 kdc = kerberos.example.com<br />
 admin_server = kerberos.example.com<br />
 }</p>
<p>DOMAIN.COM.AU = {<br />
admin_server = domain.com.au<br />
kdc = dc1.domain.com.au<br />
kdc = dc2.domain.com.au<br />
}</p>
<p>[domain_realm]<br />
 .example.com = EXAMPLE.COM<br />
 example.com = EXAMPLE.COM<br />
 domain.com.au = DOMAIN.COM.AU<br />
 .domain.com.au = DOMAIN.COM.AU</p>
<p>

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

</p>
<p># kinit someaduser</p>
<p>

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.

</p>
<p>Ticket cache: FILE:/tmp/krb5cc_0<br />
Default principal: someaduser@DOMAIN.COM.AU</p>
<p>Valid starting Expires Service principal<br />
02/27/14 12:23:21 02/27/14 22:23:21 krbtgt/DOMAIN.COM.AU@DOMAIN.COM.AU<br />
 renew until 03/06/14 12:23:19</p>
<p>

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.

</p>
<p># net ads join domain.com.au -U someadadmin</p>
<p>

You can test that this worked running the following command

</p>
<p># net ads testjoin<br />
Join is OK</p>
<p>

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

</p>
<p># authconfig-tui</p>
<p>

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

User Information

• Use Winbind

Authentication

• 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:

Realm: DOMAIN.COM.AU
KDC: dc1.domain.com.au,dc2.domain.com.au
Admin Server: domain.com.au

On the next screen you will find the Winbind Settings

Settings for this screen are as follows:

Security Model: ads
Domain: DOMAIN
Domain Controllers: dc1.domain.com.au,dc2.domain.com.au
ADS Realm: DOMAIN.COM.AU
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.

</p>
<p>/usr/bin/net join -w DOMAIN -S dc1.domain.com.au -U Administrator</p>
<p>

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

<br />
--winbindtemplatehomedir=/home/DOMAIN/%U --enablemkhomedir<br />

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.

</p>
<p>authconfig --winbindtemplatehomedir=/home/DOMAIN/%U --enablemkhomedir --update</p>
<p>

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.

</p>
<p># mkdir /home/DOMAIN<br />
# setfacl -m group:&quot;Domain Users&quot;:rwx /home/DOMAIN</p>
<p>

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.

</p>
<p># echo 'AllowGroups linuxadmins' &gt;&gt; /etc/ssh/sshd_config<br />
# service sshd restart</p>
<p>

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.