Authenticate RHEL 5 and 6 SSSD Using Kerberos and LDAP Against Active Directory on Windows Server 2008 R2

Authenticate RHEL 5 and 6 SSSD Using Kerberos and LDAP Against Active Directory on Windows Server 2008 R2

Thursday, January 30, 2014

SSSD brought several authentication and authorization protocols under one roof.

Despite that, it can be tricky to configure RHEL 5 and 6 systems to authenticate with SSSD using Kerberos and LDAP against an Active Directory server. This post details the steps I took to set everything up.

Repository Packages Required

Because the SSSD daemon is being used, the nss-pam-ldapd and pam_ldap packages can be removed:

yum erase nss-pam-ldapd pam_ldap  

Then, install the following packages:

yum install sssd oddjob oddjob-mkhomedir  

authconfig Configuration

After installing the necessary packages, authconfig needs to be configured.

First, if you’re running RHEL 5, verify the authconfig package is fully updated, otherwise the authconfig command will not have the --enablesssd command line switch:

Then, run authconfig:

authconfig --enablesssd --enablesssdauth --disableldap --disableldapauth --disablekrb5 --update  

The authconfig command above will add the pam_sss.so module to the necessary lines in /etc/pam.d/system-auth on RHEL 5 and 6.

On RHEL 6, /etc/pam.d/password-auth is also updated.

#%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_sss.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_sss.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_sss.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  session     optional      pam_sss.so  

The authconfig command above will add the sss parameter to the necessary lines in /etc/nsswitch.conf on RHEL 5 and RHEL 6.

#  # /etc/nsswitch.conf  #    passwd:     files sss  shadow:     files sss  group:      files sss    hosts:      files dns    bootparams: nisplus [NOTFOUND=return] files    ethers:     files  netmasks:   files  networks:   files  protocols:  files  rpc:        files  services:   files sss    netgroup:   files sss    publickey:  nisplus    automount:  files  aliases:    files nisplus  

SSSD Configuration File

At the time of writing, I know of nothing to automatically create the /etc/sssd/sssd.conf file, so it will have to be created manually.

Create file /etc/sssd/sssd.conf and copy and paste the following contents:

[sssd]  config_file_version = 2    reconnection_retries = 3    sbus_timeout = 30  services = nss, pam    domains = EXAMPLE.COM    [nss]  filter_groups = root  filter_users = root  reconnection_retries = 3    [pam]  reconnection_retries = 3    [domain/EXAMPLE.COM]  debug_level = 0  cache_credentials = False    id_provider = ldap  auth_provider = krb5  chpass_provider = krb5  access_provider = ldap    ldap_uri = ldap://ad1.example.com    ldap_schema = rfc2307bis    ldap_referrals = False    ldap_search_base = dc=example,dc=com    ldap_user_search_base = cn=Users,dc=example,dc=com  ldap_user_object_class = user    ldap_group_search_base = ou=Groups,dc=example,dc=com  ldap_group_object_class = group    ldap_user_name = sAMAccountName    ldap_user_home_directory = unixHomeDirectory    ldap_user_member_of = memberOf    ldap_access_order = expire  ldap_account_expire_policy = ad  ldap_force_upper_case_realm = True    ldap_id_use_start_tls = False  ldap_default_bind_dn = cn=sssd,ou=Service Accounts,ou=Groups,dc=example,dc=com  ldap_default_authtok_type = password  ldap_default_authtok = $PASSWORD  ldap_tls_cacertdir = /etc/openldap/cacerts    krb5_realm = EXAMPLE.COM  krb5_canonicalize = False  krb5_server = ad1.example.com:88,ad2.example.com:88  krb5_kpasswd = ad1.example.com:88,ad2.example.com:88  

Kerberos Configuration File

Open /etc/krb5.conf and copy and paste the following contents:

[logging]   default = FILE:/var/log/krb5libs.log   kdc = FILE:/var/log/krb5kdc.log   admin_server = FILE:/var/log/kadmind.log    [libdefaults]   default_realm = EXAMPLE.COM   dns_lookup_realm = false   dns_lookup_kdc = false   ticket_lifetime = 24h   renew_lifetime = 7d   forwardable = true    [realms]     EXAMPLE.COM = {    kdc = ad1.example.com:88    kdc = ad2.example.com:88   }    [domain_realm]   example.com = EXAMPLE.COM   .example.com = EXAMPLE.COM  

Enable and Start the SSSD Service

Finally, enable the sssd service on boot and start it:

chkconfig sssd on  service sssd restart  

Test Everything

At this point, you should be able to use the id $USER command to lookup any user in Active Directory.

In addition, getent passwd $USER and getent group $GROUP can be used to lookup further user and group information in Active Directory.

Potential Problems

This is not reflected in the above configuration, but while going through the same set of steps above at a customer, I ran into login issues with SSH and GDM (i.e. logging in through the GNOME GUI) despite the SSSD configuration file being setup properly.

The issue turned out to be because of ldap_user_principal = userPrincipalName set in /etc/sssd/sssd.conf.

When I performed an ldapsearch on user1, I saw their userPrinciaplName set to user1@example.com, and SSSD would authenticate that user using the Kerberos Realm EXAMPLE.COM; most Kerberos configurations I have come across have their Kerberos Realm set to the FQDN, so this wouldn’t be an issue.

However, the customer had their Kerberos Realm set to LABS.EXAMPLE.COM. Because of this, Kerberos was throwing connection issues in /var/log/messages because the Kerberos Realm EXAMPLE.COM did not exist; the actual Kerberos Realm was LABS.EXAMPLE.COM. By removing the ldap_user_principal = userPrincipalName line, SSSD used the default realm set by the krb5_realm parameter, which was LABS.EXAMPLE.COM, and the problem went away.

References

SSSD KDC reply did not match expectations

CentOS Authentication and Naming Services with SSSD

Configuring sssd to authenticate with a Windows 2008 Domain Server

Linux SSH + PAM + LDAP + SSSD+ 2008 R2 AD Deployment

SSSD tries to resolve the users from wrong realm