Common wisdom about Active Directory authentication for Linux Servers?
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...
- their OS platform and
- the current version of that platform and
- 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:
- it is simple to install w/out all the manual steps and...
- is free and...
- 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...
- 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.