ThorneLabs

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

• Updated January 31, 2022


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 describes the steps I took to set this 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:

yum update authconfig

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 am not aware of a process that will automatically create the /etc/sssd/sssd.conf file, so it will need 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, the userPrincipalName was 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