Introduction

This article provides the details needed to solve a real use case used to allow a user to authenticate to an Oracle Public Cloud Linux server in SaaS using a single or multiple LDAP Identity store that could be Active Directory 2012R2 (AD) or better, Oracle Internet Directory (OID), Oracle Unified Directory (OUD), Oracle Directory Services Enterprise Edition (ODSEE), or OpenLDAP. The use case stems from the need to authenticate and authorize users to OPC Linux servers using an existing LDAP identity store. Historically, this problem has been done using pam_ldap, a pluggable authentication module used on Linux, but unfortunately PAM will only work with a single identity store.

The goals for such a solution are as follows:

• Leverage a single or multiple LDAP identity stores that can support one or many AD, OID, OUD, ODSEE, and OpenLDAP LDAP identity stores.
• Authenticate users using credentials stored in existing LDAP identity store(s).
• Authorize access to Linux files and folders permissions based on existing groups managed in the LDAP identity store(s).
• Provide offline authentication if a LDAP identity store is unavailable.
• Provide high authentication and authorization performance.
• Provide a high availability to authentication and authorization.

This integration is actually not terribly complicated, but there are quite a few steps and it can get into a lot of detail the more you take advantage of many of SSSD features. This is why I am going to break this article into several parts so you can go through it in chunks.

SSSD Solution Requirements

This solution uses existing technology that comes with Linux which leverages the following components:

• System Security Services Daemon 1.13.3+ (SSSD)
• TLS Configured on either the LDAP servers or LBR (Required by SSSD)
• Proper LDAP Schema Mapping for SSSD Configuration
• SSSD Tools Utilities (Optional)
• Microsoft Identity Management for UNIX package (optional for AD)

The remaining content of this article and following provides the technical guidelines needed to implement the solution. The key component to this solution is SSSD (System Security Service Daemon), which improves and extends problems that exist with PAM and NSS. SSSD can provide authentication and caching services for thousands of users across different identity stores using a unified configuration, and integrate natively with those stores. Besides caching to greatly reduce authentication workloads, it offers offline authentication. So this is a truly enterprise solution to authenticating users to Linux servers using multiple Identity stores.

This article explains how to implement an example use case for the sake of simplification, but SSSD can be expanded as needed to leverage other rich features it has to offer such as fingerprint authentication, one-time-password (OTP), and other options.

Pre-Install Guideline Overview

This section is for the purpose of pre-installation implementation details that should be known before going forward with SSSD installation and configure.

Assumptions

In order to implement this solution, it assumes the following.

• A working Linux server version 6 or 7.
• A working LDAP identity store; e.g. Active Directory 2012R2 domain (Kerberos is not required), Oracle Internet Directory 11g, etc.
• TLS Certificates configured on all LDAP identity stores or its load balancer end point.
• Minimal working knowledge of UNIX and LDAP
• Root access to the Linux server

SSSD Architecture

Before getting into the implementation of SSSD it is important to understand the basics of the architecture. This will not only help learn the flow of authentication, but help for the purposes of troubleshooting. The first thing to keep in mind is SSSD is more than just a module. Unlike pam_ldap or nss_ldap, SSSD is a daemon that communicates with multiple modules, which provides a type of NSS and PAM interface to Linux in order to provide authentication and authorization for different identity and authentication providers.

Let’s do a quick introduction into what happens with SSSD when a request for a user is executed.  Take the following diagram:

1. When a user executes getent passwd larry, libc opens the nss_sss module per nsswitch.conf and passes in the request.
2. The nss_sss memory-mapped cache is consulted first, which is extremely fast.
3. If not found in nss_sss cache the request is passed to the sssd_nss module.
4. Then sssd_nss checks the SSSD on-disk LDB cache. If the data is present in the cache and valid, the nss responder returns it.
5. If the data is not present in the LDB cache or it is expired, it connects to the remote server and runs the search.
6. The sssd.conf is configured with multiple domains; “domains = AD, OID”.
a. Active Directory is searched first, and if not found…
b. OID is searched next.
7. When the search is finished the LDB cache is updated
8. The sssd_be provider signals back to the NSS responder to check the cache again
9. The sssd_nss responder returns the cached data. If there is no data in cache then no data is returned.
Based on our diagram and the explanation of the flow through all the components of SSSD, the take way can be summarized with the following feature highlights.

• Support for Multiple Identity Domains
SSSD can work with multiple identity and authentication sources, which is something pam_ldap cannot do.

• Offline Authentication
In flow 4 any response including credentials are cached, so therefore if there is an identity or authentication source that is unavailable, and as long as it is in the LDB cache, things will still work. What this means is say Active Directory is down, users can still authenticate and work as long as the LDB cache has the data and is not expired.

• Performance
SSSD helps reduce the load on the identification servers. Where nss_ldap, lets every client that needs to request user information open its own connection for each request, SSSD only communicates to the LDAP server using the Data Provider reducing the load to one connection per client.

• High Availability
Besides the LDB cache in order to improve reliability, SSSD provides a way to include redundancy for identity and authentication sources by using comma delimited values or backup parameters such as ldap_backup_uri in the sssd.conf file as an example. This provides a high availability solution.

• Isolated Troubleshooting
There is a lists services in the sssd.conf; e.g. services = nss, pam, autofs. Each service has its own section including domain sections; e.g. [domain/AD]. Since there is no global debug level, each section needs debugging turned on, debug_level = 9, which creates individual debug logs, for example sssd_nss.log, sssd_pam.log, sssd_AD.log, sssd_OID.log, etc. So the flow outlined in the diagram is helpful when troubleshooting. In the event you need to troubleshoot issues you would follow the same flow in the diagram and look inside each isolated log to troubleshoot issues.

SSSD simply provides better performance, high availability, offline authentication, and better isolated debugging for troubleshooting. Finally, and more importantly for this solution, SSSD is also extensible so that it can be configure to use additional identity sources and authentication mechanisms at the same time.

Summary

This concludes Part 1 --- I have covered the introduction of SSSD, the architecture, and how the flow works, critical knowledge needed for troubleshooting. Although this article covered the basics, this implementation can be tricky so knowing the basics is very important when it comes to troubleshooting issues.  In Part 2 of 4 – SSSD Linux Authentication: LDAP Identity Store Requirements, I will cover the LDAP Identity Store requirements and integration details.  In that article I will explore important details you need to know about what SSSD needs of the Identity Store and attribute mapping information.