Active Directory Authentication in RedHat

A while ago, I wrote a Gist about how to bind a Red Hat or CentOS server to a Windows domain. I figured it I would feature it here on the blog as well.

Winbind

The process of linking Linux with Winbind has become increasingly straightforward, but there are some redundant pieces involved.

Installing Dependencies

We need to make sure winbind and friends are installed so there are no issues later on down the line:

yum install -y samba-common samba-winbind-clients samba-winbind nscd ntp ntpdate

Updating the Time

Keeping in sync with time is very important in an AD environment. Without the correct time, a machine will not even be able to join the domain.

ntpdate pool.ntp.org
/sbin/chkconfig --level 35 ntpd on
/sbin/service ntpd start

Authconfig

Authconfig is Red Hat’s utility for configuring PAM authentication. We will utilize it to do the bulk of our configuration for us. Run authconfig-tui and select Winbind for both User Information and Authentiction. Also, Cache Information should be checked. Make sure that local authorization is sufficient is selected in case there are problems! Do not select Join Domain in this dialog, as it will be done later.

• Security Model: ads
• Domain: The WORKGROUP of your domain.
• Domain Controllers: Specified in {server}
• ADS Realm: {DOMAIN}
• Template Shell: /bin/bash

We should also enable home directory auto creation, unless special provisioning for such things is already in place (shared filesystem for example):

authconfig --enablemkhomedir --update

Kerberos Configuration

The authconfig script sets this up for us, but we want to verify the script did it’s job correctly.

The Kerberos configuration file is used to join the machine to the domain as well as to reference it later on. I’ve provided an example configuration file, however some of the items need to be replaced with customized values:

• {DOMAIN} Your AD domain in all caps.
• {domainname} Your AD domain in all lowercase.
• {server} The IP address of your DC.

Example

vi /etc/krb5.conf

[libdefaults]
default_realm = {DOMAIN}

[realms]
{DOMAIN} = {
    admin_server   = {server}
    default_domain = {domainname}
    kdc            = {server}
}

[domain_realm]
{domainname}  = {DOMAIN}
.{domainname} = {DOMAIN}

Samba Configuration

Authconfig sets up the smb.conf file as well, but a few things must be changed for a easier to use solution. There is one variable in the example configuration that must be changed to suit your environment:

• {name} The base hostname of the system. In the case of test.example.com, it’s TEST.

Example

vi /etc/smb.conf

[global]
netbios name = {name}
winbind use default domain = true
add machine script = /usr/sbin/useradd -s /sbin/nologin -M %u

[homes]
valid users = %S

Connecting to Active Directory

Now comes the fun part, connecting our server with Active Directory, joining it to the domain.

We will then need to add a user account that is linked to the value set in {name}.

useradd -s /sbin/nologin -M {name}$
passwd -l {name}$

Finally, join the machine to the domain. To do this, you need access to an account with enough permissions (Usually a member of the Domain Admins group).

net join -w {domain} -S {server} -U {user}

PAM

From here, we must configure PAM itself. There are two main files to modify here, password-auth, which handles SSHd (and a few others) authentication, and system-auth, which deals with everything else.

Authconfig makes this pretty easy to do, but if not done right, modifications will be overwritten if something is changed. The good news is, this can be solved via changing the symlink from system-auth-ac to a custom file, system-auth-custom and using some include statements to link back to system-auth-ac:

password-auth-custom

# This file is designed to be used with authconfig. It adds functionality
# while still allowing authconfig to generate configuration.  The symlink
# password-auth -> password-auth-ac was replaced with this file.

# The listsep argument is important as Windows groups may contain spaces
account required pam_access.so listsep=,

# Include authconfig file
auth include password-auth-ac
account include password-auth-ac
password include password-auth-ac
session include password-auth-ac

system-auth-custom

# This file is designed to be used with authconfig.  It adds functionality
# while still allowing authconfig to generate configuration.  The symlink
# system-auth -> system-auth-ac was replaced with this file.

# The listsep argument is important as Windows groups may contain spaces
account required pam_access.so debug listsep=,

# Include authconfig file
auth include system-auth-ac
account include system-auth-ac
password include system-auth-ac
session include system-auth-ac

Changing the Symlinks

rm system-auth password-auth
ln -s system-auth-custom system-auth
ln -s password-auth-custom password-auth

Now we’ve got a custom authentication piece that won’t be overwritten when authconfig does it’s magic!

Configuring Authorization With pam_access.so

Because of the previous step, the contents of /etc/security/access.conf are no longer valid as they assume lists are separated with spaces. Since Active Directory allows spaces in group names, (and encourages it), we’ve changed it to a comma.

To allow only members of Domain Admins, and wheel access to the system we would do the following:

vi /etc/security/access.conf
+:root,Domain Admins,wheel:ALL
-:ALL:ALL

Sudoers

Well, Domain Admins can log in, but they don’t have any privileges. How do we fix that? Sudoers of course! Warning: Whitespace characters must be escaped in the sudoers file or a syntax error will be thrown:

visudo
%domain\ admins ALL=(ALL) ALL