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.
