Common wisdom about Active Directory authentication for Linux Servers?

Question

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:

Winbind/Samba
Straight-up LDAP
Sometimes LDAP + Kerberos
Microsoft Windows Services for Unix (SFU)
Microsoft Identity Management for Unix
NSLCD
SSSD
FreeIPA
Centrify
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.

But...

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?

Solution 1

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

Solution 2

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.

Solution 3

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.

Solution 4

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.

Winbind

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.

SSSD

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.

Summary

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.

Solution 5

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.

View more solutions

Comments

[Michael Hampton]

Wait until you see realmd in RHEL 7...

[ewwhite]

@MichaelHampton Well, you see my point. It's a reasonable request. I just don't want to get screwed-over in the process.

[Michael Hampton]

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.

[Giordano Ferrari]

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.

[Michael Hampton]

Looks like realmd sets up sssd by default to join an AD domain, though you can override it and use winbind.

[voretaq7]

@MichaelHampton if you have any experience (or docs) with realmd/RHEL7 you should write up an answer - I'm peripherally familiar with it but I didn't see any good current docs. It looks like that's going to be the SSSD replacement?

[Michael Hampton]

@voretaq7 No, it's just a configurator that tries to set up everything automatically, and gives some level of control when you need to do things manually. It abstracts away the differences between, say, AD and FreeIPA. And no, the RHEL docs don't appear to have been written yet.

[Aaron Copley]

This guide was just published last month. As such, it should contain relevant/current information.

[dvim]

@ewwhite Just curious -- how did you end up doing this? Did you enable the (deprecated) Identity Management for Unix? Or just create custom attributes for the UID/GID/etc and edit them manually? I'm considering the same issue, on Windows Server 2012 R2.

[ewwhite]

@JW. Thanks for following up. I accomplished this by adding another 2008 R2 domain controller and utilizing the Unix attributes tab in ADUC. On the Linux side, I used SSSD and kerberos (not Winbind). A couple of tweaks were needed to the SSSD side, but all works well.

[dvim]

@ewwhite Thanks. I'm planning to use SSSD too, but since we have a 2012 server, I was a little wary of enabling the deprecated Unix attributes.

[ewwhite]

@JW. I did it in a W2012 environment as well... basically because it's easy for end-users (my customers) to understand the UNIX tab.

[Maximus Minimus]

+1 for this; my general experience is "they say it works but it's never clean".

[Yolo Perdiem]

"This document" link appears to be invalid.

[Aaron Copley]

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.

[ewwhite]

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.

[Aaron Copley]

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.)

[ewwhite]

@AaronCopley The role provides an administrative GUI to enable Unix attributes on a per-user basis.

[Ryan Bolger]

+Infinity to this. Centrify even has their Express version that's free if all you need is basic authentication support.

[Juan Jimenez]

The second document link is now invalid, says authoization is required. :(

[Aaron Copley]

I updated the link.

[Jonathon Reinhart]

SSSD does support Dynamic DNS updates: access.redhat.com/documentation/en-us/red_hat_enterprise_lin‌​ux/…

[junior ruby developer]

Now (2020 Nov) reference architecture for integrating Red Hat Enterprise Server with Active Directory link is broken.