Closing the Integration Gap

This post is the second in a series of blog posts about integrating Linux systems into Active Directory environments. In the previous post we discussed dishwashers and, more seriously, some basic principles. In this post I will continue by exploring how the integration gap between Linux systems and Active Directory emerged, how it was formerly addressed, and what options are available now.

Let's start with a bit of history... before the advent of Active Directory, Linux and UNIX systems had developed ways to connect to, and interact with, a central LDAP server for identity look-up and authentication purposes. These connections were basic, but as the environments were not overly complex (in comparison to modern equivalents) - they were good enough for the time. Then... AD was born.

Active Directory not only integrated several services (namely: LDAP, Kerberos, and DNS) under one hood, but it also

allowed for more complex relationships between identity sets. For example, traditionally, we think about an LDAP server (or a group of LDAP servers sharing the same replicated data) as a single namespace. AD can not only handle different namespaces, but can also manage complex relationships between them. These capabilities solved real world problems and led to the following two major results: (1) AD became a dominant identity solution in the enterprise and (2) this allowed environments became much more complex. Identity data could now be organized into multiple different domains or (even) collections of domains called forests (see image below).

While AD was rapidly gaining momentum in enterprise data centers, the basic native Linux integration tools were becoming increasingly obsolete / insufficient. This created an opportunity for new tools to emerge. On the open source side, the most widely used integration solution became Samba winbind. The Samba project had a primary goal of re-implementing Microsoft technologies in open source. Samba is really a combination of related components and technologies. One part of Samba development focuses on implementing the SMB file server and acting as a CIFS server (Samba FS), another part focuses on building a domain controller equivalent to AD (Samba DC), while yet a third part pursued connecting Linux and other systems to AD (Samba winbind).

Early Samba winbind development created a baseline open source solution for Linux integration with AD that was sufficient for its time. (In fact, we will return to Samba winbind and its successor, SSSD, in subsequent blog posts on this topic. For now, we will continue with the high level overview of AD/Linux connectivity.)

On the commercial side, the market also responded with a series of startups like: Vintella, Likewise, and Centrify. The main goal of those solutions was to close the gap between the AD world and non-Windows systems like Linux, UNIX, and Mac, making non-Windows systems blend naturally into AD-dominated environments.

So, while Samba and commercial vendors were actively plugging the integration holes with their respective solutions, core Linux was not focusing on addressing this gap. However, in 2007, the FreeIPA project was started and subsequently, in 2009, a SSSD project was forked out from it. What is FreeIPA? FreeIPA is essentially an equivalent to AD, but focuses on the needs of Linux and UNIX systems. To be clear, FreeIPA is not a replacement for AD, it is rather an “overlord” for Linux/UNIX environments that can stand by itself or be a subordinate to Active Directory. (As with SSSD, I will talk more about FreeIPA in future blog posts.) It is important to emphasize that SSSD and FreeIPA are native Linux projects that close the interoperability gap. And while it did take awhile for these projects to mature and deliver features comparable to those of Samba and Centrify... nearly six years into their development (present day being January, 2015), both FreeIPA and SSSD are (now) well established solutions.

Looking at the timeline (above), it’s clear that over the last six (or seven) years Linux has steadily grown its native capabilities related to AD integration and has significantly reduced the need for commercial solutions. Going back to my dishwasher analogy (see my previous post)... why buy third party hoses, fittings, or adapters if they already come with the device? You buy the dishwasher and it has everything you need to connect it to any pipe you like! And, once again, using this as an analogy for the integration of Linux systems (in an existing enterprise IT environment), nearly everything you need to connect a Linux system to AD is included with / provided by SSSD and FreeIPA. If you need additional functionality, you can always order more hoses / fittings / adapaters from commercial vendors (albeit at an added cost). And while there can be good reasons to do so... as time goes by, the native capabilities of the Linux OS (e.g. Red Hat Enterprise Linux) will inevitably become more and more advanced – potentially eliminating the need for a third party solutions. So while it’s fair to say that commercial solutions are not dead yet – they are likely a dying breed.

In summary: Linux systems (again, like Red Hat Enterprise Linux) now come equipped with native AD integration tools – saving enterprise customers from having to spend extra money (and time) getting started. In my next post we will look into the aspects of integration because as it turn out... hooking up a Linux system in an AD environment is a little bit more complex that connecting a dishwasher. In the mean time, if you have questions or comments, do feel free to post them below.