What is the common wisdom in 2014 about Active Directory authentication/integration for Linux servers and modern Windows Server operating systems (CentOS/RHEL-focused)?

Over the years since my first attempts with integration in 2004, it seems like the best-practices around this have shifted. I'm not quite sure which method currently has the most momentum.

In the field, I've seen:

Straight-up LDAP
Sometimes LDAP + Kerberos
Microsoft Windows Services for Unix (SFU)
Microsoft Identity Management for Unix
Powerbroker (née Likewise)

Winbind always seemed terrible and unreliable. The commercial solutions like Centrify and Likewise always worked, but seemed unnecessary, since this capability is baked into the OS.

The last few installations I've done had the Microsoft Identity Management for Unix role feature added to a Windows 2008 R2 server and NSLCD on the Linux side (for RHEL5). This worked until RHEL6, where the lack of maintenance on NSLCD and memory resource management issues forced a change to SSSD. Red Hat also seemed to back the SSSD approach, so that's been fine for my use.

I'm working with a new installation where the domain controllers are Windows 2008 R2 Core systems and do not have the ability to add the Identity Management for Unix role feature. And I'm told that this feature is deprecated is no longer present in Windows Server 2012 R2.

The benefit of having this role installed is the presence of this GUI, while allows easy one-step administration of user attributes.


The Server for Network Information Service (NIS) Tools option of Remote Server Administration Tools (RSAT) is deprecated. Use native LDAP, Samba Client, Kerberos, or non-Microsoft options.

That makes it really difficult to rely on if it may break forward-compatibility. The customer wants to use Winbind, but everything I see from the Red Hat side points to the use of SSSD.

What's the right approach?
How do you handle this in your environment?

  • 1
    From what I understand RHEL 7 will have exactly two ways to do this: one through FreeIPA with a cross-domain trust to AD, and the other through AD via realmd and whatever it's a front end for (I don't have the time to look right now). Either way, you'll have a supported way to join the system to the domain right from the kickstart. Apr 17, 2014 at 18:00
  • 1
    We use Centrify for out Solaris and RHEL boxes. It's pretty straight forward to install, and have honestly had zero issues/complaints using it. Apr 17, 2014 at 18:02
  • 2
    This guide was just published last month. As such, it should contain relevant/current information. Apr 21, 2014 at 19:03
  • 1
    @AaronCopley You're welcome to post that as an answer. I hadn't seen this guide before.
    – ewwhite
    Apr 21, 2014 at 19:11
  • 2

5 Answers 5


In March 2014, Red Hat published a reference architecture for integrating Red Hat Enterprise Server with Active Directory. (This material should certainly be current and relevant.) I hate to post this as an answer, but it's really just too much material to transfer into the answer field.

This document (corrected) is hot off the press seems to focus on the new features of Red Hat Enterprise Linux (RHEL) 7. It was published for the Summit last week.

Should this link go stale, please let me know and I'll update the answer accordingly.

I have personally used WinBind fairly reliably for authentication. There's very infrequent service failure that requires someone with root or other local account to go in and bounce winbindd. This could probably be dealt with via proper monitoring if you care to put the effort into it.

It is worth noting that Centrify does have additional functionality, though this can be provided by separate configuration management. (Puppet, etc.)

Edit 6/16/14:

Red Hat Enterprise Linux 7 Windows Integration Guide

  • "This document" link appears to be invalid. Apr 23, 2014 at 12:39
  • Are you sure? I just cleared my history/cache and tried again. Then I even confirmed in another browser. Is anyone else having trouble? The file is linked from this page, under Road to RHEL 7, Interoperability update: Red Hat Enterprise Linux 7 beta & Microsoft Windows EDIT: I see there's a "final" version posted now, but the old link still works for me? Updating the answer anyway. Apr 23, 2014 at 14:30
  • I haven't had any trouble. I read the document and even compared to what I'd been doing. A few inconsistencies. The biggest issue: There's NO mention of Windows Server 2012 :( So I'm still seeing an opinion on that.
    – ewwhite
    Apr 23, 2014 at 14:42
  • Sorry, I don't know enough about the Windows side to know what if any implications there are for 2012 vs. 2008. :( (Other than what you said about Identity Management for Unix role -- which doesn't seem to be necessary.) Apr 23, 2014 at 14:44
  • @AaronCopley The role provides an administrative GUI to enable Unix attributes on a per-user basis.
    – ewwhite
    Apr 25, 2014 at 8:49

re: "The commercial solutions like Centrify and Likewise always worked, but seemed unnecessary, since this capability is baked into the OS."

Well I think most of us have been hearing for years that XYZ operating system finally cracks the AD integration puzzle. IMHO the problem is that for the OS vendor, AD integration is a checkbox feature, i.e. they need to deliver something that sorta kinda works to get that checkbox, and that checkbox typically only works on...

  1. their OS platform and
  2. the current version of that platform and
  3. against a more recent version of Active Directory.

The reality is that most environments are not monolithic in terms of OS vendor and OS version, and will have older versions of AD. That's why a vendor such as Centrify has to support 450+ flavors of UNIX/Linux/Mac/etc. against Windows 2000 to Windows 2012 R2, not just RHEL 7 again Windows 2012 R2.

In addition, you need to factor in how your AD is deployed, so does the OS vendor's AD integration support Read Only Domain Controllers (RODCs), one-way trusts, provide multi-forest support, etc. And what if you have pre-existing UID space (which you will), are there migration tools to migrate the UIDs into AD. And does the OS vendor's AD support address the ability to map multiple UIDs to a single AD in situations in which your UID space is not flat. And what about ... well you get the idea.

Then there's the question of support ...

Point is AD integration may seem easy conceptually and may be "free" with a vendor's latest OS, and can probably work if you have just one version of an OS from one vendor and have a vanilla AD that is the latest version, and you have a premium support contract with the OS vendor who will try their best to fix any problems that will come up. Otherwise you may want to consider a specialized third party solution.

  • +1 for this; my general experience is "they say it works but it's never clean". Apr 17, 2014 at 23:41
  • +Infinity to this. Centrify even has their Express version that's free if all you need is basic authentication support. Apr 28, 2015 at 22:28

The Server for Network Information Service (NIS) Tools option of Remote Server Administration Tools (RSAT) is deprecated.

This comes as no surprise to me -- NIS is evidence that Sun hated us and wanted us to be miserable.

Use native LDAP, Samba Client, Kerberos, or non-Microsoft options.

This is good advice. Given the choices I would say "Use native LDAP (over SSL, please)" - there are many options available for this, the two I'm most familiar with being pam_ldap + nss_ldap (from PADL), or the combined nss-pam-ldapd (which originated as a fork and has seen ongoing development and enhancements).

Since you're asking about RedHat specifically it's worth noting that RedHat provides you other alternatives using SSSD.
If your environment is all-RedHat (or just has a large number of RedHat systems) looking into the officially-supported "RedHat Way of Doing Things" would certainly be worth your time.

As I've no experience with RedHat/SSSD myself I'm just going by the docs, but it looks to be quite robust and well-designed.


Of the methods suggested, let me give you a pros/cons list:

Straight up Kerberos/LDAP

Pros: Works great when configured properly. Rarely breaks, resilient, will survive network glitches. No changes need in AD, no schema change, no Administrator access needed to the AD. Free.

Cons: Relatively difficult to configure. Multiple files need to be changed. Will not work if the authentication server (Kerberos/LDAP) is not available.


Pros: Easy to configure. Basic sudo functionality. Free.

Cons: Support intensive. Not network resilient. If there is a network issue, linux machines could get dropped out of the AD requiring re-registering the server, a support task. Access to administrator account of AD required. Might meed to make schema changes in AD.

Centrify/Likewise etc.

Pros: Relatively easy to configure.

Cons: Changes sudo functionality to proprietary, harder to support. License cost per server. Need additional skills to manage.


Pros: One config file, easy to configure. Works with all present and future authentication methods. Scalable, grows with the system. Will work in disconnected mode. Network resilient. No need to make any change to AD schema. No need for AD administrator credentials. Free, supported.

Cons: Does not have win services like automatic updates of DNS. Need to configure CIFS shares.


Looking at advantages and disadvantages, SSSD is the clear winner. If it is a new system, there is no reason to use anything other than SSSD. It is an integrator that works with all present authentication methods and can grow with system because new methods can be added when available. It uses native linux methods and is much more reliable and fast. If caching is turned on, the systems will work even in a completely disconnected systems with full network failure.

Winbind can be used for existing systems if there is too much work involved to change.

Centrify has had issues with integration which could get costly. Most of the bugs are fixed in the new release, but there still are some that cause headaches.

I have worked with all these methods and SSSD is the clear winner. Even for older systems, the ROI for converting from Winbind to SSSD is very high. Unless there is a specific reason not to use SSSD, always use SSSD.


Have to comment on this:

It is worth noting that Centrify does have additional functionality, though this can be provided by separate configuration management. (Puppet, etc.)

As someone who works with Centrify not sure where that comment comes from. Look at this and you can see that there is a boatload of features you don't get with a config mgmt tool ala Puppet. For example, support for mapping of multiple UIDs to a single AD account (Zones), support for full Active Directory domain trusts (which the Red Hat solution documents on page 3 that it does not support), etc.

But back to this Red Hat guide. It's great that Red Hat is publishing this, options are good. Note it gives the customer 10 options to do basic AD integration. Most of the options are variations of Winbind, and page 15 it lists the advantages and disadvantages of each, and there is a bunch of manual steps required for each (with corresponding disadvantages / lack of functionality per above). The advantage of Centrify Express is that per the other commenters above is:

  1. it is simple to install w/out all the manual steps and...
  2. is free and...
  3. is not limited to Red Hat V7 which is important as the question had to do with Linux, not just one variant -- Centrify supports over 300 flavors of *nix and...
  4. supports all variants of Windows AD, not just Windows 2008. They published a comparison of Centrify vs. Winbind here, but it is not open source.

At the end it boils down to do you want to roll it yourself or go with a commercial solution. Really a matter where you and how you spend your time.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .