Occasionally I get asked by prospective customers how our Delinea Server Suite compares to a “free” offering such as Red Hat SSSD for the integration of Linux systems with Active Directory. Usually, this question pops up whenever a Linux OS vendor (e.g. Red Hat) introduces a new version of Linux (e.g. RHEL 7) that has a new or improved feature (e.g. SSSD) that claims “Improved Active Directory integration” in the “New Features” document for that release of the OS.
Having experienced this wave of inquiry every few years (e.g. search for “Active Directory” here for RHEL 5, here for RHEL 6, and here for RHEL 7), what I have typically seen is that in each wave these questions tend to die down a few months after the new OS release comes out when prospective customers either hear us describe the differences and/or realize after testing and researching the new Linux OS version that it is not sufficient from an AD integration perspective.
I have always been meaning to get around to summarizing my answers in written form, hence this particular blog post, so hopefully, this blog post will help customers make a more informed choice vis a vis Linux to Active Directory options.
But before I jump into this, I know some of you may have come upon this blog post via a Google search and/or may not be familiar with Delinea or me, so you may not be sure if the person writing this is credible on this subject. I would like to think I am somewhat credible in discussing the topic for two reasons:
- I have been CEO of Delinea that has been building technology in this area for 10+ years, with on average more than 100 engineers per year working on this problem for a 10 year period (equaling 1000 man-years of effort and easily $75+ million in cumulative R&D spend)
- My company has more than 5,000 customers who have deployed our “Linux to AD” software on millions of servers to do just that (and more), so I have literally had hundreds of conversations with customers on this very topic. I certainly have my biases towards my company’s offerings, but per above am not a newbie on this topic, and will try to paint an objective picture.
So here goes …
What we have found is that "rolling your own" via using free stuff like SSSD can work for some users to do basic AD bridging/integration BUT only if (a) they have a very simple (i.e. non-complex) environment and relatively basic functional requirements and a relatively small scale environment, and (b) they are willing to put enough manpower and effort into it and have the appropriate skillset to make rolling their own work.
In other words, we see something like SSSD for integrating Linux to Active Directory systems working only in environments where typically the customer has a small set of OS versions in a relatively small and “vanilla” environment, where they want only “authentication” versus “authentication & authorization & auditing” (the classic “Triple-A”s of secure access control), and where the business decision has been made to spend people resources building and maintaining an in-house Active Directory integration solution vs. spending time and money focusing on other things for the business.
Here’s a graphic that represents what I am saying in terms of what I think are the sweet spots for an SSSD or a Samba Winbind vis a vis Server Suite:
Let me go into detail on each axis of the graphic.
The complexity of the environment & functional requirements
If you have a complex environment and/or have complex functionality requirements, a freebie like an SSSD or a Samba Winbind will in all likelihood fall short. Here’s what I mean by “complexity” and why I make that claim:
- Most organizations have or will have many flavors and versions of Linux *and* AD which introduce complexity. Using SSSD or a Samba Winbind may work for a specific operating system, typically the latest and greatest version of one vendor's OS, but given that most customers have a mix of different vendor's operating systems and a wide mix of versions of the various OSes, getting a consistent cross-platform experience (let alone availability of the software itself) of an SSSD is not possible and/or easy to get. Then when you factor in different versions of Windows AD that a customer may have, or they may upgrade to in the near future, it gets even more complex — even when it comes to trying to do "basic" AD joining and integration — as again these “roll your own” solutions tend to be tested against a very small number of AD versions and are not time to support new versions.
Delinea supports more than 450 OSes and 12+ versions of Windows AD and it is our business to deliver the support of new OSes and versions of AD in a very timely manner (e.g. we have had Day 1 support for new Mac OS X versions for the past 7 years). So our testing matrix is in effect 450 x 12 that delivers a consistent cross-platform and cross-version experience no matter what you have or will have Linux- and AD-wise, versus a testing matrix of say 4 x 2 that you get with an SSSD.
- Many organizations will have complex deployments of AD and/or may have complex networks. We have also found that even for basic AD integration that the “roll their own” solutions do not support complex AD environments, e.g. multi-forest, one-way trusts, read-only domain controllers (RODC), etc. So the third-party AD integration utilities tend to break easily when AD complexity enters.
This may not be an issue now for an organization, but what if the organization wants to integrate with another department that has a different AD forest or domain, or if the organization now wants to implement RODCs … whoops that free stuff does not support that. The same applies to complex DNS environments. So even if the OS environment is simple and static, the complexity of your AD and/or your network may or will cause issues. We address this complexity of your AD and network, much like we address the complexity of your OS environments.
- Many organizations have large numbers of systems that “roll your own” solutions will not scale to. Say you are not worried about my first two points above — i.e. let’s assume you believe you have a very vanilla environment from an OS, AD, and network environment, and you are highly confident it will stay vanilla. But what if you have a lot of these vanilla systems that you want to integrate into AD?
At Delinea we have customers that have deployed our solution to many 10s of thousands of servers internally, so we know we can scale. And our product is used by more than 5000 organizations and we have been doing this for 10 years, so it is battle-tested and hardened. So our stuff can scale and you can read case studies on our website that attest to that.
The reality is that having done this for 10 years and with active dialogue with thousands of end user organizations, we are not familiar with other third-party offerings having similar-sized deployments at scale. In addition, it is interesting to note that Red Hat themselves actually recommends that you don’t deploy SSSD for “direct” AD integration to greater than 30 systems (see slide extract below). In other words, Red Hat themselves says that their solutions should not be deployed at scale.
Red Hat’s own recommendation of deploying SSSD, which clearly states that you should not deploy SSSD for tying more than 30 systems directly into AD
Instead, Red Hat recommends for more than 30 systems you deploy a separate directory for Linux (their IDM solution, with the corresponding cost to purchase and deploy) and set up a trust relationship between that and AD. Which in effect is a recommendation that in a large-scale environment you actually NOT “AD Bridge” directly and get the benefits of identity consolidation (single password policy, a single place to provision/de-provision users, etc.), but instead set up a parallel directory.
You may find this adds complexity and cost vs. simplifying things the way Delinea does by tying Linux systems into AD. So the resulting solution that they recommend requires duplicate directory infrastructure, processes, procedures, established synchronization, audit controls, automation, and management infrastructure.
This probably makes economic sense for Red Hat in that they want to sell you their own alternative products to Active Directory, so in my opinion, it is hard to see the motivation for them to deliver a truly high scale native/direct AD integration solution.
Delinea’s approach is to allow customers the ability to use what they already have, i.e. leverage the existing AD environment for not just authentication but also for privilege management, reporting, and policy enforcement while allowing the customers to collapse redundant and duplicative processes and procedures, minimizing the number of points that need to be audited. So a big philosophical difference and scalability are reflected in this difference.
- Solutions such as SSSD also don’t address Linux environments that may have complex UID namespaces. What we have also found is that the “roll your own” approach also does not take into account the fact that if you have multiple UIDs for a given user across multiple systems, you have to be in a situation of having to rationalize UIDs. Delinea covers that scenario with our Zoning technology — the ability to map multiple UIDs to a single user in AD, thereby avoiding the pain and hassle of having to rationalize.
Again maybe an organization has a perfect UID space, so maybe not a big issue, but for larger and more complex environments, or when departments come together and UID clashes begin, that won't be the case. So we address the complexity of disparate Unix namespaces and other solutions do not.
- Customers will have requirements to integrate other systems beyond Linux to Active Directory, i.e. their environment is not just Linux and Windows. Delinea also does this AD join stuff beyond *nix, e.g. we support iOS, Android, and Mac OS X. We also extend AD to on-premise apps (e.g. SAP, Apache, DB2, etc.) and also support thousands of SaaS apps to do AD integration. Again we deliver a consistent vendor experience for integrating AD beyond *nix with one throat to choke, etc. So if you believe in the value of integrating Linux to AD, why not include Mac, mobile, SaaS, etc.?
- Customers often have requirements for *nix systems that go beyond authentication. Up to this point, I have been comparing how Delinea is better just for AD integration. But the reality is that customers, especially ones in well-regulated industries, also need to address compliance or security regimens. Therefore they also need capabilities such as authorization and auditing as part of an AD Bridge solution. Here are some concrete examples of plus features we offer that we find more complex environments need:
- We provide an alternative to using sudo, in fact, a centralized Unix privileged management solution.
- We also provide user-level auditing of Unix user sessions. This is important because we have found that customers need rich user-level auditing, reporting, etc., to meet regulatory compliance requirements (PCI 10.2.2). Third parties who provide a freebie AD integration utility do not provide a solution for rich user-level auditing.
- We also provided AD optimized versions of Samba and SSH and PuTTY, and maintain current versions that address security vulnerabilities. And we test our solution against other third-party SSH tools
- We provide smart support for Red Hat, CentOS, and Mac OS X ala smartcard support you get with Windows. People want multi-factor authentication as they get more security conscious.
- We also provide authorization and auditing tools for Windows environments that plug into the management tools we use for AD/Unix. Vendors such as Red Hat don’t address security needs in your Windows environment.
I could list some more but hopefully, you get the feel.
Resources
Now let’s talk about that axis which I said “abundance of low cost and highly skilled resources.” What does that mean? Well, there is no doubt in my mind that there are a lot of smart people out there that can spend hours getting basic AD integration to work using something like SSSD. The question is how do you want to spend valuable (and often expensive) resources? Especially when there may be other projects that can be worked on since this problem has been solved in a comprehensive and cost-effective manner by a vendor such as Delinea.
What we have found is that most customers don’t have the expertise in building AD integration solutions or even if they do, they want to spend their time and money doing more strategic things. If you are fortunate (e.g. you are a college and have a bunch of interns and/or grad students), then certainly try a “free” solution out, as you have “A LOT” of talented people who are relatively low cost, but there are a few other things you should consider:
- Who is going to maintain this “roll your own” solution for AD integration? Now say after some effort you may in fact get something like Winbind to work in your environment, but the reality is you may need to go back and test it out if you upgrade to say R2 of Windows 2012. Or if now all of a sudden you want to bring in SUSE or Linux Mint (i.e. a different OS vendor than Red Hat) into your shop, you will find that those vendors may not even support say SSSD, and what you built say on RHEL to get AD integration working won’t easily “port” over.
Another scenario we see is that the person who built this homegrown and free "AD glue" leaves the organization, so the knowledge is now gone. Given all this, a typical question that arises in these scenarios is who in the organization are you going to call if there is something wrong or if a new OS or updated environment enters? Again not to say you or your organization can't do this, but is this where they want to spend your time? Alternatively, you can leverage Delinea who will maintain software that is guaranteed to work against basically any *nix OS and any AD you have — or will have — and you have a throat to choke and someone to call if it does not work, no matter how complex your OS and AD configuration is.
- Who is going to help you deploy? The fact is that most free AD join solutions out there are built by a small team of software developers with no professional services to help you deploy. We address making sure you are in fact successful in deploying our solution in a number of ways:
- We provide deployment tools optimized for AD that do a pre-install check to make sure the *nix environment can integrate with AD, can push out the software (new installs and upgrades), etc. We also provide reports on who can access what, what systems have our AD agent, what versions, etc. We also provide other management tools including plug-ins into ADUC. So there is a whole reporting and management layer for the AD integration you don't get with SSSD or Winbind. So we make the deployment and management and reporting simple.
- We have a community of thousands of admins who comment on our solution all the time and give us pointers and support each other, etc. We have bloggers who just blog on our solution. So we have an ecosystem around us to make our solution better.
- We have experienced professional services people who have done hundreds of successful deployments, each with years of experience doing just this.
- Who is going to support you? We find that customers want assurance or insurance. Who gets the phone call when something is not working? And when you pick up the phone, you want to speak to a specialist in this space. For example, when your car has transmission problems, do you want to take it to a general mechanic or a transmission specialist?
The fact is that many of these third parties offering free AD integration either don’t provide phone support (i.e. are community supported so no service level agreement to answer your questions to your satisfaction) and if they do, are not a security company or an IDM company, but they are a Linux company vs. one specializing in cross-platform security and Active Directory integration. We find that customers want a security company handling their security needs.
Clearly, there will always be an appeal of a “free” as in a new feature of a new version of an OS, but usually, customers quickly find out that it is “free“ as in “free puppies” — i.e. a lot of care and feeding is needed, and often this is ignored. Hopefully, this raises awareness for that aspect beyond the feature/function comparison.
Summary
So at the end of the day, it boils down to how/where you want to spend your time and money, and how big a need/concern is this for an organization, and how complex one's environment is. If you feel your environment could use a packaged solution, with a throat to choke in terms of tech support and updates, and you won't go beyond basic AD integration for *nix to include authorization and auditing, and/or you also want to go beyond *nix to Mac or Mobile or SaaS, etc., then I think we are a great choice for your Linux to Active Directory integration needs.