Why Use SSSD Instead of a Direct LDAP Configuration for Applications?

In my Identity Management and Application Integration blog post I talk about how applications can make the most of the identity ecosystem. For example, a number of applications have integrated Apache modules and SSSD to provide a more flexible authentication experience.  Despite this progress - some (people) remain unconvinced. They wonder why they should use Apache modules and SSSD in conjunction with, for example, Active Directory instead of using a simple LDAP configuration… essentially asking: why bother?

Let’s look at this scenario in greater detail.  If an application supports

direct LDAP configuration it might be good enough. Then again, is it?

Two reasons why a systems administrator might choose to use the LDAP configuration provided by an application:

• It is simple - you enter LDAP connection data and you are done.
• The application’s UI might provide assistance.

However, while SSSD involves a marginally more complex setup / configuration, using SSSD provides several benefits over a direct LDAP integration, namely:

• Enterprise SSO - using Apache modules and SSSD one can enable Kerberos based authentication so that users who authenticated against Active Directory can access an application without being prompted (again) for their username and password.

• Failover - a built-in LDAP solution usually does not have a built-in failover capability so if the connection to the central server is lost the application may fail to function properly. SSSD, on the other hand, will discover Active Directory servers and will use an explicit or DNS based failover mechanism (depending on its configuration) enabling an application to continue to function (even when the connection is lost).

• Offline support - if and when the connection to the central server is lost an application can continue to operate if it has a cache; SSSD provides such cache while a simple LDAP solution usually does not.

• Security - the security of the connection to the LDAP server is also very important. In the simple LDAP case, the connection requires a password that is stored in the application configuration files or in a database. This is not a best practice.  In fact, it is much safer to use Kerberos keytab to connect to the central servers. This is what SSSD and GSSproxy take care of in the proposed solution.

• Domain awareness - an Active Directory environment usually consists of multiple different domains combined into one or more forests. Users might be in different parts of the forest or in different forests altogether. An SSSD based solution hides all of this complexity and allows users from different domains and forests to access an application.  This is not possible with a simple LDAP configuration.

• Site awareness - Active Directory servers are usually bound to a specific location or datacenter. An SSSD based solution can pick the closest Active Directory server based on site affiliation. In the case of simple LDAP, there is usually just one server and no discovery or site affiliation. This becomes important when an application has multiple instances and there is a preference for the application to connect to the local identity servers instead of going over the wire to a completely different part of the world.

• Load balancing - an argument can be made that a direct LDAP connection is easily load balanced. It can be, but with an SSSD based solution you do not need a load balancer. Its discovery and failover capabilities save you time and money in terms of configuring and supporting yet another piece of hardware.

Overall, external authentication based on Apache modules adds a lot of flexibility in authentication methods, supports complex domain infrastructures, has better security properties, and raises the resiliency of the application without requiring extra equipment.

Of course, nothing comes for free. Configuring external authentication requires a little bit more understanding of the configuration challenges than does a simple LDAP configuration. It also adds some complexity, but this complexity is well worth the (small amount of) extra effort.  With SSSD, you get installation and configuration tools like ipa-client-install and realmd that make configuration both simple and easy. You also have access to the installation scripts or Puppet modules provided by the applications. These conveniences make SSSD based integration a very smooth process and give you access to all of the rich features inherent to SSSD.

As always - if you have thoughts or questions - feel free to reach out using the comments section (below).