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).

  1. I completely understand and support all your points above with the benefits of using external authentication via apache modules vs. ldap configuration.

    But I think there’s a critical small thing missing, and that is *the beautiful login screen*.

    If one is using apache authentication, then usually *the browser* will popup a standard OS window asking for credentials. On the other hand, using the app’s ldap auth mechanism will show you a “beautiful” page, themed like the rest of the app, with a nice logo on top, some text explaining what this is, a few links to help pages etc.
    This is what freeipa does on it’s self-service portal, on the password migration portal etc.
    This is how people want their application to look like to their users.

    Thank you and all the teams for your hard work on IDM solutions.

    1. Thank you very much for bringing it up!
      Yes the login screen is very important. The browser popup is not nice and actually not secure.
      To address this problem we provide mod_intercept_form_submit module that uses login page provided by application to perform authentication. Please take a look at https://github.com/adelton/mod_intercept_form_submit
      With this module you use the page provided by application but hook in PAM stack to perform authentication.

      Thank you,
      Dmitri

  2. Hello,

    Regarding the point, “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.”

    How can I make use of Loadbalancing feature from SSSD?
    I tried searching it on sssd, sssd.conf, sssd-ldap man pages.

    Thanks & Regards,
    Sasikumar K, RHCA

    1. Hello, please see man sssd-ldap and search for FAILOVER and SERVICE DISCOVERY. These terms are mentioned in some keys but also there are special sections at the bottom.

      Thank you,
      Dmitri

      1. Hi, thanks for responding.
        As far as I understood, the points on FAILOVER and SERVICE DISCOVERY are meant for HA. It’s hard to relate it with Load Balancing feature. We have keepalived in our env. Can SSSD replace a load-balancer (not fully but with some basic features like spreading the queries)?

      2. Hello,

        SSSD does caching so it does not connect to the central server on every request. It does not need to. Thus the general load is reduced.
        It will stick to a server until the connection is lost or response times out which might indicate that the server is busy.
        Once it is lost it will get a server based on the DNS service discovery.
        If your DNS serves your DNS SRV records in round robin fashion then SSSD will pick another server based on DNS. If you have multiple clients in such configuration you get a balanced solution across. Keep in mind that SSSD is not only for login into application but also to login into your Fedora/RHEL/CentOS/FreeBSD/Ubuntu/Debian/… Linux systems.

  3. Hello,

    Regards to this statement: “An SSSD based solution hides all of this complexity and allows users from different domains and forests to access an application” . Would this as well work between two separate Active Directory Forests with One-Way Trust ?

    Thank you in advance.
    Sam

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s