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


Feature Legacy (LDAP/KRB) Traditional(Winbind) Third Party Contemporary(SSSD)

Authenticate Using Kerberos

Yes Yes Yes Yes
Authenticate Using LDAP Yes Yes Yes Yes
Support of multiple AD domains No Yes Yes Yes
Support of AD forests No Yes Yes Yes
Support of heterogeneous environments AD/FreeIPA (IdM) No No No Yes
Security Easy to configure securely No No Yes Yes
System has identity and its key is used to protect access to the central server No Yes Yes Yes
NTLM support No Yes Vendor specific No
Identity Lookup and mapping Requires AD POSIXS extensions (SFU/IMU) Yes No Vendor specific No
Dynamic ID mapping of AD SIDs No Yes Vendor specific Yes
Takes advantage of the AD specific extensions and protocols. No Yes Vendor specific Yes
DNS AD DNS Aging and Scavenging No No Vendor specific Yes
AD DNS Sites No Yes Vendor specific Yes
File Sharing Samba FS integration No Yes Vendor specific Yes
CIFS client integration No Yes Vendor specific Yes
Policy Centralized management of host based access control via GPO No No Yes Yes
Integration on the host with other services and applications Integration with core utilities like SSH, sudo, automount No No Vendor specific Yes
Extended identity interfaces over local message bus No No No Yes
Special features for applications No No No Yes
User Experience Simple installation No No Yes Yes
Cost Free Free $50-$100 per client Free

  1. Thanks for this post. I will be doing a lot more investigation of SSSD as there appears to be a a lot of out of date information online about having to use winbind if you want to do samba integration. Looks like I will not be taking that route.

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