AD Authentication with RHEL 6

We’ve been using AD authentication with our RHEL and CENTOS 4 and 5 systems for some time, now, so I was anxious to see what kinds of changes might have come up with RHEL6. Not much, happily, but there was one change that took a little while to figure out. We’ll run through all the steps, from beginning to end, here.

Install the prerequisites

We’re using samba and samba-winbind for this, so make sure these are installed.

yum install samba samba-winbind

If you’re running RHEL5 and a Windows 2008 R2 domain, you’ll want to use samba3x, instead of the samba. See this article for more information on that front.

Edit the Configuration Files

you’ll want to have the following settings. I’ve grouped them here to make it all more readable. Changes from the default are in blue.

/etc/krb5.conf

default_realm = EXAMPLE.COM dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h renew_lifetime = 7d forwardable = yes [realms] EXAMPLE.COM = { default_domain = example.com } [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM

Here we’re defining the kerberos realm and domains. “example.com” will be replaced with your AD domain name. Do note the capitalization; it matters.

/etc/samba/smb.conf

workgroup = example realm = EXAMPLE.COM security = ads idmap uid = 10000-500000 idmap gid = 10000-500000 template shell = /bin/bash winbind use default domain = true winbind offline logon = false winbind nested groups = yes encrypt passwords = yes

Here we’ve told samba to use the kerberos realm EXAMPLE.COM (you’ll substitute your domain from the krb5.conf file). We’re using ads for security (Windows-style), and we’re allocating a bunch of UIDs and GIDs for mapping the domain users and groups to the Linux equivalents.

/etc/nsswitch.conf

passwd: files winbind shadow: files group: files winbind

Here we’re telling the system to look not only in the /etc/passwd and /etc/group files for authentication, but also to use winbind.

Join the Domain

Now’s the fun part: we can join the system to the domain.

chkconfig smb on service smb restart net ads join –U username

where username is a domain user who has permissions to join a computer to the domain. You should get a response that the server has joined your realm.
Depending on your DNS configuration, you might get some errors like the following:

[root@linuxserver1]# net ads join -U username Enter username's password: Using short domain name – EXAMPLE Joined 'LINUXSERVER1' to realm 'example.com' [2010/11/29 16:11:20.643445, 0] libads/kerberos.c:333(ads_kinit_password) kerberos_kinit_password LINUXSERVER1$@EXAMPLE.COM failed: Client not found in Kerberos database [2010/11/29 16:11:20.644894, 0] utils/net_ads.c:1147(net_update_dns_internal) net_update_dns_internal: Failed to connect to our DC! DNS update failed!

So long as your server created a machine account in the domain, you can ignore the above errors. It’s trying to update your DNS server, and if you’re not using a Microsoft DNS server as a part of your domain, it will fail. That’s OK.
Once you’ve joined the domain, we need to start winbind

chkconfig winbind on service winbind start

Assuming winbind starts without any errors, you can test your membership and domain communication with the wbinfo command:

wbinfo –g

This command should list out all of the groups you’ve got configured in your domain.

Configure the home directories

We’ll first want to edit the /etc/oddjobd.conf.d/oddjobd-mkhomedir.conf file; this defaults to creating home directories that are group- and world-readable. We don’t want that. This, BTW, is a change from what we did in RHEL 5 and below.
There are two lines in the /etc/oddjobd.conf.d/oddjobd-mkhomedir.conf file that look like this:

<helper exec="/usr/libexec/oddjob/mkhomedir -u 0022"

Change them to read:

<helper exec="/usr/libexec/oddjob/mkhomedir -u 0077"

Then restart the oddjobd service

service oddjobd restart

Set the domain home permissions

*Note:  the behavior below is reported as fixed in advisory RHBA-2011:0339-2, but I'm leaving the information here for posterity's sake.  
There's a curiousity with the way oddjobd works, here: it seems to be assuming that the default umask is 0022 (644 permissions equivalent). When we change the umask 0077 (700), it not only creates the users' home directories with these permissions, but *also the domain home*. As it turns out, the domain home (/home/DOMAIN) is owned by root. This prevents anyone from being able to get to their home directory.
Unless we change this, users will receive the following error:

Could not chdir to home directory /home/DOMAIN/user: Permission denied -bash: /home/DOMAIN/user/.bash_profile: Permission denied

But if we pre-create the domain home, we should be in good shape:

mkdir /home/DOMAIN chmod 711 /home/DOMAIN

Where DOMAIN is the short name of your AD domain.
There's a bug for this behavior, BTW, at https://bugzilla.redhat.com/show_bug.cgi?id=666418, if you're interested in such things.
This should set you up so that everyone can change directories to this, but no one can read or write to this directory. If you prefer users to be able to enumerate the contents of your DOMAIN directory, change the permissions to 755 instead of 711.

Restrict Logins

We’ll first edit the /etc/pam.d/password-auth file (you can have the OS do this with a GUI front-end for you, if you run authconfig-gtk). This tells pam to use, in addition to the local user store, winbind for authentication.

Domain authentication isn’t that useful unless you can use it to control who can and cannot log in to your server.

#%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_winbind.so use_first_pass auth required pam_deny.so account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_winbind.so account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_winbind.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_oddjob_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so

The mkhomedir line has PAM create a home directory (defaulting to /home/DOMAIN/username). That’s usually a good idea.
It’s possible to put login restrictions here in the system-auth file, but it’s usually considered best practices to put those in the individual files for the connection methods. We’ll do that now.

/etc/pam.d/sshd

#%PAM-1.0 auth required pam_sepermit.so auth include password-auth auth include system-auth account required pam_nologin.so account include system-auth account sufficient pam_localuser.so account required pam_succeed_if.so user ingroup DOMAIN\linuxadmins password include system-auth # pam_selinux.so close should be the first session rule session required pam_selinux.so close session required pam_loginuid.so # pam_selinux.so open should only be followed by sessions to be executed in the user context session required pam_selinux.so open env_params session optional pam_keyinit.so force revoke session include password-auth

Here we’re telling pam that only users who are in the group linuxadmins are allowed to connect to our server though ssh.

/etc/pam.d/gdm

#%PAM-1.0 auth [success=done ignore=ignore default=bad] pam_selinux_permit.so auth required pam_succeed_if.so user != root quiet auth required pam_env.so auth substack system-auth auth optional pam_gnome_keyring.so account required pam_nologin.so account include system-auth account sufficient pam_succeed_if.so user = DOMAIN\user34 account sufficient pam_succeed_if.so user ingroup DOMAIN\linuxadmins account required pam_succeed_if.so user ingroup DOMAIN\domainadmins password include system-auth session required pam_selinux.so close session required pam_loginuid.so session optional pam_console.so session required pam_selinux.so open session optional pam_keyinit.so force revoke session required pam_namespace.so session optional pam_gnome_keyring.so auto_start session include system-auth

We’re giving more people access to the GUI login, though. Notice that we’re allowing user34, linuxadmins, and domainadmins to log in through GDM.

Posted 30th November 2010 by Lane Duncan