Setting up LDAP and Kerberos Client Authentication on RHEL 7 (using sssd)

We are going to configure a RHEL 7 system to authenticate against FreeIPA using LDAP/Kerberos.


To get Kerberos running, NTP synchronisation and DNS resolution must be working.

We are going to use the FreeIPA server which we set up previously. Check this post for how to setup a FreeIPA server on RHEL 7.


The System Security Services Daemon (SSSD) provides access to different identity and authentication providers.

What SSSD does is allow a local service to check with a local cache in SSSD, but that cache may be taken from any variety of remote identity providers — an LDAP directory, an Identity Management domain, even a Kerberos realm.

Configure LDAP Authetication

We use a RHEL 7.0 server (instructions were also tested on a RHEL 7.2) with SELinux set to enforcing mode.

DNS is configured to point to the FreeIPA server:

# cat /etc/resolv.conf
search rhce.local
# host domain name pointer ipa.rhce.local.


# yum install -y sssd nss-pam-ldapd wget

Download the CA certificate from the IPA server to our local server:

# mkdir /etc/openldap/cacerts
# wget -P /etc/openldap/cacerts/ ftp://ipa.rhce.local/pub/cacert.p12


Open the file /etc/sysconfig/authconfig and ensure the following are set:


Once done, run the authconfig utility.

# authconfig-tui

In User Information, select Use LDAP, and under Authentication, select Use LDAP Authentication. In the LDAP Settings screen, select Use TLS and specify the following:

Server: ipa.rhce.local
Base DN: dc=rhce,dc=local

Open the file /etc/sssd/sssd.conf and add the following line:

ldap_tls_reqcert = never

Check man sssd-ldap for more options that are available.

Make sure nslcd is disabled, and sssd enabled:

# systemctl stop nslcd; systemctl disable nslcd
# systemctl enable sssd; systemctl restart sssd

Verify by logging in with an LDAP user:

# su - alice
su: warning: cannot change directory to /home/alice: No such file or directory
$ id
uid=1219400005(alice) gid=1219400005(alice) groups=1219400005(alice) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Configure Kerberos Authentication


# yum install -y pam_krb5 krb5-workstation


I found erasing the file’s /etc/krb5.conf content helpful when configuring Kerberos authentication from scratch:

# > /etc/krb5.conf

Run the authconfig in a text mode:

# authconfig-tui

On the authentication Configuration screen, under Authentication, select Use Kerberos to enable Kerberos authorisation. In the LDAP Settings screen, do not change anything. In the Kerberos settings screen, specify the following:

KDC: ipa.rhce.local
Admin Server: ipa.rhce.local

Obtain a Kerberos ticket for the Kerberos alice user:

# kinit alice

Verify the ticket:

# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [email protected]

Valid starting     Expires            Service principal
07/05/16 11:21:27  08/05/16 11:21:25  [email protected]

These are for references.

# cat /etc/krb5.conf
 default_realm = RHCE.LOCAL
 dns_lookup_realm = false
 dns_lookup_kdc = false
  kdc = ipa.rhce.local
  admin_server = ipa.rhce.local

 rhce.local = RHCE.LOCAL
 .rhce.local = RHCE.LOCAL
# cat /etc/sssd/sssd.conf

autofs_provider = ldap
cache_credentials = True
krb5_realm = RHCE.LOCAL
ldap_search_base = dc=rhce,dc=local
id_provider = ldap
auth_provider = krb5
chpass_provider = krb5
ldap_uri = ldap://ipa.rhce.local/
ldap_id_use_start_tls = True
ldap_tls_cacertdir = /etc/openldap/cacerts
ldap_tls_reqcert = never
krb5_server = ipa.rhce.local
krb5_store_password_if_offline = True
krb5_kpasswd = ipa.rhce.local
services = nss, pam, autofs
config_file_version = 2

domains = default

Test Kerberos Configuration

# su - alice
su: warning: cannot change directory to /home/alice: No such file or directory
$ hostname
$ kinit
Password for [email protected]:
$ klist
Ticket cache: FILE:/tmp/krb5cc_1219400005
Default principal: [email protected]

Valid starting     Expires            Service principal
07/05/16 12:04:44  87/05/16 12:04:42  [email protected]

We should be able to reconnect without giving any password:

$ ssh ipa.rhce.local
Could not create directory '/home/alice/.ssh'.
Could not chdir to home directory /home/alice: No such file or directory
$ hostname

4 thoughts on “Setting up LDAP and Kerberos Client Authentication on RHEL 7 (using sssd)

  1. Hi,
    i have noticed the use of
    tls_reqcert never in /etc/nslcd.conf for nslcd
    ldap_tls_reqcert = never in /etc/sssd/sssd.conf for sssd.

    If I’m not wrong, this disable the use of tsl certificate. You can check this deleting the certification authority certificate (ca.crt) in /etc/openldap/cacerts.
    This because the authconfig-tui does not properly create hash link for the ca.crt.
    Instead authconfig-gtk properly create the hash link.
    Then I think is better to configure ldap authentication using authconfig-gtk.
    If you want to configure ldap/kerberos authentication using authconfig-tui, without disabling tls, you need to:

    Configure authentication ldap/kerberos using authconfig-tui. At end authconfig-tui warn you to copy the CA certificate in /etc/openldap/cacerts.

    cd /etc/openldap/cacerts

    IPA server CA certificate is /etc/ipa/ca.crt you can copy it in the pub ftp directory:
    – cp /etc/ipa.crt /var/ftp/pub/
    Then dowload it using wget:
    – wget -O ca.crt
    The we need to get the certificate hash:
    – /etc/pki/tls/misc/c_hash ca.crt
    example : 45e037a3.0 => ca.crt
    Now we need to properly create the hash link:
    – ln -s ca.crt 45e037a3.0

    then restart sssd

    • I’m afraid you misunderstood. It does not disable the TLS certificate.

      Setting ldap_tls_reqcert to “never” means that the client does not “request” a server certificate. Now whether the server sends its certificate or not is not under the client’s control, but setting it to “never” just tells the client to do no checking of the server certificate, if any, that is received.

    • Hi,
      yes but if I set tls_reqcert never or ldap_tls_reqcert never
      in nslcd or sssd I don’t need to dowload the CA certificate.

Leave a Reply

Your email address will not be published. Required fields are marked *