Overview of Direct Integration Options

As mentioned in my previous post there are multiple ways to connect a Linux system to Active Directory (AD) directly. With this in mind, let us review the following list of options...

• The legacy integration option: this is a solution where (likely older) native Linux tools are used to connect to an LDAP server of your choice (e.g. AD).
• The traditional integration option: this is a solution based on Samba winbind.
• The third-party integration option: this is a solution based on (proprietary) commercial software.
• The contemporary integration option: this is a solution based on SSSD.

Legacy Integration Option

In the case of the legacy integration option (see figure above), a Linux system is connected to AD using LDAP for identity lookup and LDAP or Kerberos for authentication. It pretty much solves the problem of basic user authentication. That said, such a solution has the following significant limitations:

• Only one LDAP namespace or Kerberos domain can be configured. This is very limiting as users nowadays are scattered across multiple domains and potentially even across forests.
• It is very hard to configure these tools in a secure way leading to high-level admin passwords being stored on the systems in an accessible way.
• There is no caching of the identities so when a connection to the central server is lost the system is unable to operate (i.e. it's unable to do much of anything).
• The client does not take advantage of non-standard AD extensions. This leads to poor performance and more data “flying” over the wire than is needed.
• The client can’t easily discover and failover to other AD instances in the same domain.
• The setup requires storing and managing Linux identity attributes (POSIX attributes) inside AD.
• Policies are not managed centrally.

At the end of the day, there are not many benefits to the legacy integration option other than it being free. Unsurprisingly, over the last several years, I have not come across any deployment that was using this option with Active Directory.

Traditional Integration Option

The traditional option (see figure above), using Samba winbind, has a set of significant advantages over the basic legacy solution, including:

• Winbind assumes that it connects to AD and takes advantage of the native Windows protocols and LDAP protocol extensions.
• It not only understands the concept of domains and forests but also works with trusts between domains and forests.
• It can detect servers using DNS.
• It can fail over to a different server if an AD domain controller instance becomes unavailable.
• It can complete identity mapping dynamically based on the AD object identifiers (SIDs) or use POSIX attributes as stored in AD (if these extensions were loaded).
• It integrates well with Samba FS and CIFs client.
• The security of the connection is good and is based on the identity of the client system and Kerberos keys issued to that system.

While Samba winbind has the above listed a set of advantages and is a step forward as compared to the legacy integration solution, it also has some limitations:

• Policies are (still) not centrally managed and have to be distributed out of band.
• Samba winbind can connect to AD only, while the legacy solution could work with any LDAP and Kerberos server implementation.

Overall, Samba winbind served its purpose for over a decade enabling a sufficient level of integration and propelling Linux into the modern datacenter.

Third Party Integration Option

Third party solutions (see figure above) can do pretty much everything the traditional solution (i.e. Samba winbind) can do but also have a couple of significant advantages over it, for example:

• Third party client management consoles often allow for central management of the client systems and related policies via the same management interfaces as used to manage Windows clients.
• Policies like host based access control and user privilege escalation (sudo), can be centrally managed; this is done via a mechanism called Group Policy Objects (GPO). The same mechanism is used for central policy management of Windows clients.
• The installation and configuration of the client is usually a simple command rather than a series of configuration steps each of which creates an opportunity for human error.

In addition to advantages as mentioned above the third party solutions also have advanced features that are not necessarily needed for the majority of the deployments but create a nice differentiation between commercial software and open source solutions.

Third party solutions are convenient and mature, however they are loosing ground to the modern integration option (see below) because they are not native and are not a part of the underlying Linux OS. Nevertheless, companies in this segment will most likely continue to be relevant as long as they provide a consistent advanced experience over a variety of operating systems not limited to just Linux.

Modern Integration Option

The modern integration option (see figure below) is based on the component called SSSD. SSSD stands for Systems Security Services Daemon. It is actually a group of services that are a part of the core Linux OS working together to provide authentication, identity lookup, and access control capabilities for a Linux system. SSSD acts as a connector between the operating system and a central identity server. SSSD can interoperate with AD, FreeIPA (also known is “Identity Management” or simply IdM in Red Hat Enterprise Linux or CentOS), Samba DC or any other standard LDAP and/or Kerberos server implementations.

Recent versions of Linux carry a component called “realmd”. This component acts as a configurator for SSSD. It allows detecting the presence of a central identity server by querying DNS. Realmd can configure SSSD to work with AD, FreeIPA (IdM) or MIT Kerberos making installation and configuration as smooth and simple as with third party solutions.

In comparison to Samba winbind SSSD can now do pretty much everything that winbind does. The only major limitation is the support of the (old) NTLM protocol. SSSD does not implement this protocol because by modern standards NTLM is no longer secure to deploy. It is a best security practice to eliminate the use of NTLM in the enterprise, however some organizations may find this to be challenging given historical reasons and/or the complexity of their environment.

Also of note, up until recently, SSSD lacked integration with Samba FS and CIFS client but the latest version of SSSD covers this gap. In addition to all the modern features of Samba Winbind SSSD introduces a series of features that make Samba winbind less relevant:

• Ability to download and apply host based access control policies using group policy objects managed in AD.
• SSSD, as it was mentioned earlier, can interoperate with different identity sources, not only AD.
• SSSD supports DNS scavenging (i.e. it detects if DNS entries for servers that have been removed or refreshed).
• SSSD exposes advanced identity interfaces on the local message bus called the D-Bus. This interface can be used for better integration of the applications running on top of Linux OS with the enterprise identity sources like AD and FreeIPA (IdM).

SSSD is being actively developed and has a clear roadmap of delivering more integration with other modern components like Docker, Cockpit, GSS Proxy, and others.
In comparison to commercial solutions, the SSSD based direct integration might still seem to have some limitations, however, most of those limitations are addressed by my topic for next time - indirect integration solutions. For your viewing pleasure, I've included (below) a summary table to help you compare and contrast the four direct integration options. Questions or comments about direct integration? Feel free to reply using the comments section below.

Summary of the Direct Integration Options