Linux Commands

How to Configure an LDAP Client to Use SSD

If you are tired of managing your user accounts and authentication on every single machine in your network and you are looking for a more centralized and secure way to handle these tasks, using SSSD to configure the LDAP authentication is your ultimate solution.

LDAP (Lightweight Directory Access Protocol) is an open-standard protocol for accessing and managing distributed directory information services over a network. It’s commonly used for centralized user management and authentication, as well as for storing other types of system and network configuration data.

On the other hand, SSSD provides access to identity and authentication providers such as LDAP, Kerberos, and Active Directory. It caches the user and group information locally, improving the system performance and availability.

Using SSSD to configure the LDAP authentication, you can authenticate the users with a central directory service, reducing the need for local user account management and improving security by centralizing the access control.

This article explores how to configure the LDAP Clients to use SSSD (System Security Services Daemon), a powerful centralized identity management and authentication solution.

Ensure that Your Machine Meets the Prerequisites

Before configuring SSSD for LDAP authentication, your system must meet the following prerequisites:

Network Connectivity: Make sure that your system has a working connection and can reach the LDAP server(s) over the network. You may need to configure the network settings such as DNS, routing, and firewall rules to allow the system to communicate with the LDAP server(s).

LDAP Server Details: You must also know the LDAP server hostname or IP address, port number, base DN, and administrator credentials to configure SSSD for LDAP authentication.

SSL/TLS Certificate: If you are using SSL/TLS to secure your LDAP communication, you need to obtain the SSL/TLS certificate from the LDAP server(s) and install it on your system. You may also need to configure SSSD to trust the certificate by specifying the ldap_tls_reqcert = demand or ldap_tls_reqcert = allow in the SSSD configuration file.

Install and Configure SSSD to Use the LDAP Authentication

Here are the steps to configure SSSD for LDAP authentication:

Step 1: Install the SSSD and Required LDAP Packages

You can install SSSD and required LDAP packages in Ubuntu or any Debian-based environment using the following command line:

sudo apt-get install sssd libnss-ldap libpam-ldap ldap-utils

The given command installs the SSSD package and required dependencies for LDAP authentication on Ubuntu or Debian systems. After running this command, the system will prompt you to enter the LDAP server details such as the LDAP server hostname or IP address, port number, base DN, and administrator credentials.

Step 2: Configure SSSD for LDAP

Edit the SSSD configuration file which is /etc/sssd/sssd.conf and add the following LDAP domain block to it:


config_file_version = 2

services = nss, pam

domains = ldap_example_com


id_provider = ldap

auth_provider = ldap

ldap_uri = ldaps://

ldap_search_base = dc=example,dc=com

ldap_tls_reqcert = demand

ldap_tls_cacert = /path/to/ca-cert.pem

In the previous code snippet, the domain name is ldap_example_com. Replace it with your domain name. Also, replace with your LDAP server FQDN or IP address and dc=example,dc=com with your LDAP base DN.

The ldap_tls_reqcert = demand specifies that SSSD should require a valid SSL/TLS certificate from the LDAP server. If you have a self-signed certificate or an intermediate CA, set ldap_tls_reqcert = allow.

The ldap_tls_cacert = /path/to/ca-cert.pem specifies the path to your system’s SSL/TLS CA certificate file.

Step 3: Restart SSSD

After making changes to the SSSD configuration file or any related configuration files, you need to restart the SSSD service to apply the changes.

You can use the following command:

sudo systemctl restart sssd

On some systems, you may need to reload the configuration file using the “sudo systemctl reload sssd” command instead of restarting the service. This reloads the SSSD configuration without interrupting any active sessions or processes.

Restarting or reloading the SSSD service temporarily interrupts any active user sessions or processes that rely on SSSD for authentication or authorization. That is why you should schedule the service restart during a maintenance window to minimize any potential user impact.

Step 4: Test the LDAP Authentication

Once done, proceed to test your authentication system using the following command:

getent passwd ldapuser1

The “getent passwd ldapuser1” command retrieves information about an LDAP user account from the system’s Name Service Switch (NSS) configuration, including the SSSD service.

When the command is executed, the system searches the NSS configuration for information about the “user ldapuser1”. If the user exists and is configured correctly in the LDAP directory and SSSD, the output will contain an information about the user’s account. Such information includes the username, user ID (UID), group ID (GID), home directory, and default shell.

Here’s an example output:ldapuser1:x:1001:1001:LDAP user:/home/ldapuser1:/bin/bash

In the previous example output, “ldapuser1” is the LDAP username, “1001” is the user ID (UID), “1001” is the group ID (GID), LDAP user is the user’s full name, /home/ldapuser1 is the home directory, and /bin/bash is the default shell.

If the user does not exist in your LDAP directory or there are configuration issues with the SSSD service, the “getent” command will not return any output.


Configuring an LDAP client to use SSSD provides a secure and efficient way to authenticate the users against an LDAP directory. With SSSD, you can centralize the user authentication and authorization, simplify the user management, and enhance the security. The provided steps will help you to successfully configure your SSSD on your system and start using the LDAP authentication.

About the author

Kennedy Brian

Brian is a computer scientist with a bias for software development, programming, and technical content development. He has been in the profession since 2015. He reads novels, jogs, or plays table tennis whenever not on gadgets. He is an expert in Python, SQL, Java, and data and network security.