--- date: 2013-12-16 title: Integrating RHEL with Active Directory category: linux --- 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: {% img center %} 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: {% img right %} - Select the NIS domain you created earlier - Set an approprate UUID (default should be fine) - Set the login shell as `/bin/bash`, `/bin/sh` should 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 `/home//` 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). yum install sssd sssd-client krb5-workstation samba openldap-clients policycoreutils-python This should also pull in all the dependencies. ### Configure Kerberos 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. In `/etc/krb5.conf` change you servers to point at your Domain Controllers. [logging] default = FILE:/var/log/krb5libs.log [libdefaults] default_realm = AD.EXAMPLE.COM dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h renew_lifetime = 7d rdns = false forwardable = yes [realms] AD.EXAMPLE.COM = { # Define the server only if DNS lookups are not working # kdc = server.ad.example.com # admin_server = server.ad.example.com } [domain_realm] .ad.example.com = AD.EXAMPLE.COM ad.example.com = AD.EXAMPLE.COM You should now be able to run: kinit aduser@AD.EXAMPLE.COM 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. kinit Administrator@AD.EXAMPLE.COM net ads join createupn=host/client.ad.example.com@AD.EXAMPLE.COM –k net ads keytab create net ads keytab add host/client.ad.example.com@AD.EXAMPLE.COM You should now be able to get information about yourself from AD using ldapsearch: ldapsearch -H ldap://server.ad.example.com/ -Y GSSAPI -N -b "dc=ad,dc=example,dc=com" "(&(objectClass=user)(sAMAccountName=aduser))" ### Configure SSSD Everything in SSSD revolves around a single config file (/etc/sssd/ssd.conf). [sssd] config_file_version = 2 domains = ad.example.com services = nss, pam debug_level = 0 [nss] [pam] [domain/ad.example.com] id_provider = ldap auth_provider = krb5 chpass_provider = krb5 access_provider = ldap # To use Kerberos, un comment the next line #ldap_sasl_mech = GSSAPI # The following 3 lines bind to AD. Comment them out to use Kerberos ldap_default_bind_dn = CN=svc_unix,OU=useraccounts,DC=ad,DC=example,DC=com ldap_default_authtok_type = password ldap_default_authtok = Welcome_2014 ldap_schema = rfc2307bis ldap_user_search_base = ,dc=ad,dc=example,dc=com ldap_user_object_class = user ldap_user_home_directory = unixHomeDirectory ldap_user_principal = userPrincipalName ldap_group_search_base = ou=groups,dc=ad,dc=example,dc=com ldap_group_object_class = group ldap_access_order = expire ldap_account_expire_policy = ad ldap_force_upper_case_realm = true krb5_realm = AD.EXAMPLE.COM There is something wrong here. Note the lines: # To use Kerberos, un comment the next line #ldap_sasl_mech = GSSAPI # The following 3 lines bind to AD. Comment them out to use Kerberos ldap_default_bind_dn = CN=svc_unix,OU=useraccounts,DC=ad,DC=example,DC=com ldap_default_authtok_type = password ldap_default_authtok = Welcome_2014 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: authconfig --enablesssd --enablesssdauth --enablemkhomedir –update 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: %LinuxAdmin ALL=(ALL) ALL # note the % sign, the defines it as a group not a user 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: sudo sed -i 's/PermitRootLogin no/PermitRootLogin yes/' /etc/ssh/sshd_config sudo service sshd reload