I had a request on Reddit to share a document I wrote about connect Red Hat Enterprise Linux with Active Directory. The original document I wrote is confidential, but I said I would write it up.
This works for both Server 2008(R2) and 2012. If I recall correctly it will also work with 2003, but may need to minor terminology changes on the Windows side. From the Linux side, it should be fine with RHEL 6 and similar (CentOS and Scientific Linux). It should also apply to Fedora, but your mileage may vary.
So without further ado, let’s dive in. To do this you need to know what is actually happening under the surface when you authenticate to AD from a client. The basic idea looks something like this:
Integration with AD requires the installation of a few services in Red Hat, along with some minor modifications on the Windows Domain Controllers. On the Linux side, everything revolves around the System Security Services Daemon (SSSD). All communication between the PAM and the various possible back-ends is brokered through this daemon. This is only one solution, there are several. The others involve Winbind (which I have found problematic), or LDAP/Kerberos directly (no offline authentication, more difficult to set up). Note that this does not give you any file sharing, but can easily be extended to do so using Samba.
PAM communicates with SSSD, which in turn talks to Active Directory via LDAP and Kerberos. Identification is performed via LDAP, with the user is authenticated using Kerberos. These different components have some prerequisites on Windows.
- DNS must be working fully - both forward and reverse lookups should be functional. If the Kerberos server (Windows Domain Controller) cannot identify the client via DNS, Kerberos will fail.
- Accurate time is essential – if the two systems have too larger difference in time (about 5 minutes), Kerberos will fail.
- The Active Directory needs to be extended to include the relevant information for *NIX systems (home directory, shell, UUID/GUID primarily).
- They are actually there, but empty and uneditable. The necessary GUI fields are part of “Identity Management for UNIX”
- It must be possible for the Linux client to perform an LDAP search. This could be either via an anonymous bind or authenticated.
- Anonymous is obviously not recommended.
- Simple binds (username/password) do work but are not recommended. Although I am not one to practise what I preach (see below).
- The best option is SASL/GSSAPI, using a keytab generated by Samba. This does not require Admin privileges on Windows, only permissions to join computers to the domain.
For both DNS and NTP I’m assuming that you are using the services provided by Active Directory. It is possible to break those out to other boxes, but it beyond my Windows Admin ability/desire to do so.
Preparing Active Directory
In Server Manager, add the Role Service “Identity Management for UNIX”. This is under the Role “Active Directory Domain Services” (took me a while to find that). When it asks, use your AD domain name as the NIS name. For example, with a AD domain of chriscowley.lab, use chriscowley.
Once that is installed, create a pair of groups. For the sake of argument, lets call them LinuxAdmin and LinuxUser. The intended roles of these 2 groups is left as an exercise for the reader. When you create these groups, you will see a new tab in the properties window for both groups and users: “UNIX Attributes”.
Now go ahead and create a user (or edit an existing one). Go into the UNIX tab and set the configure the user for UNIX access:
- Select the NIS domain you created earlier
- Set an approprate UUID (default should be fine)
- Set the login shell as
/bin/shshould be fine most of the time, but I have seen a few odd things happen (details escape me)
- Set the home directory. I seperate them out from local users to something like
Open up one of your groups (let’s start with LinuxAdmin) and add the user to that group. Note you have to do it 2 places (don’t blame me, I am just the messenger). Both in the standard Groups tab, but also in the UNIX attributes tab.
That should be everything on the Windows side.
Configure RHEL as a client
Most of the heavy lifting is done by the System Security Service Daemon (SSSD).
This should also pull in all the dependencies.
I’ve already said, this but I will repeat myself as getting it wrong will cause many lost hours.
- DNS must be working for both forward and reverse lookups
- Time must be in sync accross all the clients
Make sure that /etc/resolv.conf contains your domain controllers.
Gotcha: In RHEL/Fedora the DNS setting are defined in /etc/sysconfig/network-settings/ifcfg-eth0 (or whichever NIC comes first) by Anaconda. This will over-write /etc/resolv.conf on reboot. For no good reason other than stubbornness I tend to remove these entries and define resolv.conf myself (or via configuration management). Alternatively put DNS1 and DNS2 entries in the network configuration files.
/etc/krb5.conf change you servers to point at your Domain Controllers.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
You should now be able to run:
That should obtain a kerberos ticket (check with
klist) and you can move on. If it does not work fix it now - Kerberos is horrible to debug later.
Enable LDAP Searches
The best way to bind to AD is using SASL/GSSAPI as no passwords are needed.
1 2 3 4
You should now be able to get information about yourself from AD using ldapsearch:
Everything in SSSD revolves around a single config file (/etc/sssd/ssd.conf).
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
There is something wrong here. Note the lines:
1 2 3 4 5 6 7
Instead of doing the SASL/GSSAPI bind I would prefer to do I have chickened out and done a simple bind. Why? Because I am weak… :-(
Try with kerberos first, if it works then awesome, if not then create a service account in AD that can do nothing other than perform a search and use that to perform the bind. Make sure its path matches that of the ldap_default_bind_dn path, also make sure the password is more complex than “Welcome_2014”.
For now this does nothing, we need to tell PAM to use it. The easiest way to enable this on RHEL is to use the authconfig command:
This will update
/etc/nsswitch.conf and various files in
/etc/pam.d to tell the system to authenticate against SSSD. SSSD will in turn talk to Active Directory, using LDAP for Identification and Kerberos for authentication.
Finally you can enable your LinuxAdmin’s to use sudo. Run the command visudo and add the line:
Now your admin’s can run commands as root by prefacing them with sudo. For an encore, I would suggest disabling root login via SSH. Log in as your AD user (leave your root session open, just in case) and run: