Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
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. –  Michael Hampton Apr 17 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. –  cole Apr 17 at 18:02
2  
This guide was just published last month. As such, it should contain relevant/current information. –  Aaron Copley Apr 21 at 19:03
1  
@AaronCopley You're welcome to post that as an answer. I hadn't seen this guide before. –  ewwhite Apr 21 at 19:11
1  
@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. –  ewwhite Jun 3 at 18:57

4 Answers 4

up vote 7 down vote accepted

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 (a) their OS platform and (b) the current version of that platform and (c) against a more recent version of Active Directory. The reality is that most environments are not monolothic 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.

There there is 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.

share|improve this answer
    
+1 for this; my general experience is "they say it works but it's never clean". –  Darth Satan Apr 17 at 23:41

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

share|improve this answer
    
"This document" link appears to be invalid. –  evilensky Apr 23 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. –  Aaron Copley Apr 23 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 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.) –  Aaron Copley Apr 23 at 14:44
    
@AaronCopley The role provides an administrative GUI to enable Unix attributes on a per-user basis. –  ewwhite Apr 25 at 8:49

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.

share|improve this answer

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 http://www.centrify.com/express/upgrade-options-for-centrify-express.asp and you can see that there is a boatload 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 (a) it is simple to install w/out all the manual steps and (b) is free and (c) 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 (d) supports all variants of Windows AD, not just Windows 2008. They published a comparison of Centrify vs. Winbind here http://www.centrify.com/express/comparing-free-active-directory-integration-tools.asp 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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.