关于Linux服务器Active Directoryauthentication的常识？
2014年关于Linux服务器和现代 Windows Server操作系统（CentOS / RHEL）的Active Directoryauthentication/集成的常识是什么？
自2004年我第一次尝试整合以来，似乎围绕着这个问题的最佳做法已经转移了。 我不太确定目前哪种方法的动力最强。
在这个领域，我看到：
对Winbind /桑巴
直接 LDAP
有时LDAP + Kerberos
用于Unix的Microsoft Windows服务（SFU）
用于Unix的Microsoft身份pipe理
NSLCD
SSSD
FreeIPA
Centrify公司
Powerbroker（ 同样地 ）
Winbind总是显得可怕和不可靠。 像Centrify和Likewise这样的商业解决scheme一直在运行，但似乎没有必要，因为这个function已经被embedded到了操作系统中。
我所做的最后几个安装过程中，将Microsoft Identity Management for Unixangular色function添加到Windows 2008 R2服务器和Linux端的NSLCD（RHEL5）。 这一直工作，直到RHEL6，NSLCD和内存资源pipe理问题缺乏维护迫使改变SSSD。 红帽也似乎支持SSSD方法，所以这对我的使用来说很好。
我正在使用一个全新的安装，其中的域控制器是Windows 2008 R2 Core系统，并且不能添加Identity Management for Unixangular色function。 而且我被告知，此function已被弃用， 不再存在于Windows Server 2012 R2中 。
安装此angular色的好处在于此GUI的存在，同时允许对用户属性进行简单的一步pipe理。
但…
远程服务器pipe理工具（RSAT）的服务器networking信息服务（NIS）工具选项已被弃用。 使用本机LDAP，Samba客户端，Kerberos或非Microsoft选项。
如果它可能会向前兼容，那么就很难依靠它。 客户想使用Winbind，但是我从红帽方面看到的一切都指向了使用SSSD。
什么是正确的方法？
你如何在你的环境中处理这个问题？
2014年3月，红帽发布了一个将红帽企业服务器与Active Directory集成的参考架构。 （这个材料当然应该是最新的和相关的。）我讨厌把这个作为一个答案，但它真的只是太多的材料转移到答案领域。
这篇文章 （更正后）似乎很热，关注于红帽企业Linux（RHEL）7的新function。它已于上周发布。
如果这个链接过时了，请让我知道，我会相应地更新答案。
我个人使用WinBind相当可靠的身份validation。 有非常罕见的服务失败，需要有根或其他本地帐户的人进来并反弹winbindd。 这可能可以通过适当的监测来处理，如果你在努力的话。
值得注意的是，Centrify确实有更多的function，尽pipe这可以通过单独的configurationpipe理来提供。 （木偶等）
编辑6/16/14：
红帽企业Linux 7 Windows集成指南
re：“像Centrify和Likewise这样的商业解决scheme一直在运行，但似乎没有必要，因为这个function已经被embedded到了操作系统中。”
好吧，我想大多数人已经听说多年来，XYZ操作系统终于破解了AD集成难题。 恕我直言，问题是，对于操作系统供应商来说，AD集成是一个checkboxfunction，即他们需要提供的东西，有点工程，以获得该checkbox，该checkbox通常只适用于…
- 他们的OS平台和
- 该平台的当前版本
- 针对更新版本的Active Directory。
现实情况是，大多数环境在操作系统供应商和操作系统版本方面并不是单一的，并且将具有较旧版本的AD。 这就是为什么像Centrify这样的厂商必须支持450多种UNIX / Linux / Mac /等等。 针对Windows 2000到Windows 2012 R2，而不仅仅是RHEL 7再次Windows 2012 R2。
另外，您需要考虑AD的部署方式，操作系统供应商的AD集成支持只读域控制器（RODC），单向信任，提供多森林支持等等。现有的UID空间（您将会），是否有迁移工具将UID迁移到AD中。 操作系统供应商的AD支持解决了在您的UID空间不平坦的情况下将多个UID映射到单个AD的能力。 那么…那么你明白了。
然后是支持的问题
点是AD集成在概念上可能看起来很简单，并可能与供应商的最新操作系统“免费”，并可能工作，如果你只有一个来自一个供应商的操作系统版本，并有一个最新版本的香草广告，与操作系统供应商签订了一份高级支持合同，他们将尽最大努力解决将会出现的任何问题。 否则，您可能需要考虑专门的第三方解决scheme。
远程服务器pipe理工具（RSAT）的服务器networking信息服务（NIS）工具选项已被弃用。
这对我来说不足为奇–NIScertificate了Sun恨我们，并希望我们变得悲惨。
使用本机LDAP，Samba客户端，Kerberos或非Microsoft选项。
这是个好build议。 鉴于select，我会说“使用本机LDAP（通过SSL，请）” – 有很多选项可用于这两个，我最熟悉的是pam_ldap + nss_ldap （来自PADL），或组合的nss-pam- ldapd （起源于一个分支，并且看到了不断的发展和增强）。
由于您特别询问了RedHat，值得注意的是RedHat使用SSSD 为您提供了其他select 。
如果你的环境是全部RedHat（或者只是有大量的RedHat系统），那么看看官方支持的“RedHat做事情的方式”当然是值得的。
由于我自己没有使用RedHat / SSSD的经验，所以我只是按照文档去做，但它看起来相当健壮，devise良好。
必须评论这个：
值得注意的是，Centrify确实有更多的function，尽pipe这可以通过单独的configurationpipe理来提供。 （木偶等）
作为与Centrify合作的人员不确定评论的来源。 看看这个 ，你可以看到有一大堆的function，你没有得到configurationpipe理工具ala木偶。 例如，支持将多个UID映射到单个AD帐户（区域），支持完整的Active Directory域信任（红帽解决scheme在其不支持的页面3上的文档）等。
但是回到这个红帽指南。 红帽发布这个很棒，选项很好。 注意它给客户10个选项来做基本的AD集成。 大部分选项都是Winbind的变体，第15页列出了每个选项的优点和缺点，每个选项都需要一些手动步骤（相应的缺点/缺less上面的function）。 Centrify Express的优势在于，上面的其他评论者是：
- 安装w / out所有手动步骤和…
- 是免费的，…
- 并不局限于Red Hat V7，因为这个问题与Linux有关，而不仅仅是一个变种 – Centrify支持超过300种* nix和…
- 支持Windows AD的所有变体，不仅仅是Windows 2008。他们在这里发布了Centrify与Winbind的比较，但它不是开源的。
最后归结为你想自己推出还是使用商业解决scheme。 真的是你在哪里以及如何度过你的时间。
build议的方法，让我给你一个优点/缺点列表：
直接Kerberos / LDAP
优点：正确configuration时效果很好。 很lessrest，有韧性，会在networking故障中幸免于难。 AD中无需更改，无模式更改，AD无需pipe理员访问。 自由。
缺点：configuration比较困难。 需要更改多个文件。 如果身份validation服务器（Kerberos / LDAP）不可用，则不起作用。
对Winbind
优点：易于configuration。 基本的sudofunction。 自由。
缺点：支持密集。 没有networking弹性。 如果出现networking问题，Linux机器可能会退出AD，需要重新注册服务器，这是一项支持任务。 需要访问AD的pipe理员帐户。 可能会在AD中进行架构更改。
Centrify /同样等。
优点：相对容易configuration。
缺点：将sudofunction更改为专有，难以支持。 每个服务器的许可成本 需要额外的技能来pipe理。
SSSD
优点：一个configuration文件，易于configuration。 适用于所有现在和未来的身份validation方法。 可扩展，与系统一起成长。 将工作在断开模式。 networking弹性。 无需对AD模式进行任何更改。 不需要ADpipe理员凭据。 免费，支持。
缺点：没有win服务，如自动更新DNS。 需要configurationCIFS共享。
概要
考虑到优势和劣势，SSSD是明显的赢家。 如果是新系统，没有理由使用SSSD以外的任何其他系统。 它是一个集成者，可以与所有现有的身份validation方法一起使用，并且可以随系统一起增长，因为可以添加新的方法。 它使用本地linux方法，更可靠和快速。 如果打开caching，即使在完全断开连接的系统中，系统也能正常工作，并发生全网故障。
Winbind可以用于现有的系统，如果有太多的工作需要改变。
Centrify在集成方面存在问题，可能会导致代价高昂。 大部分的错误都是在新版本中修复的，但仍然有一些会引起头痛。
我曾与所有这些方法，SSSD是明确的赢家。 即使是较老的系统，从Winbind转换到SSSD的ROI也是非常高的。 除非有特殊原因不使用SSSD，否则一定要使用SSSD。