Linux Kerberos Active Directory Integration With Unix
Authenticate Linux/Unix to Active Directory. UNIX clients use Active Directory Kerberos for. To integrate Windows and UNIX more.
Configure SSSD Everything in SSSD revolves around a single config file (/etc/sssd/ssd.conf). sssd configfileversion = 2 domains = ad.example.com services = nss, pam debuglevel = 0 nss pam domain/ad.example.com idprovider = ldap authprovider = krb5 chpassprovider = krb5 accessprovider = ldap # To use Kerberos, un comment the next line #ldapsaslmech = GSSAPI # The following 3 lines bind to AD.
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 NSLCD 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. 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? In March 2014, Red Hat published a reference architecture for. (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.
(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. 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. 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 + (from PADL), or the combined (which originated as a fork and has seen ongoing development and enhancements). Since you're asking about RedHat specifically it's worth noting that 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. 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 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, 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. 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.
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. 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.
Active Directory On Unix
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.
Kerberos Authentication Linux
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.