LinuxサーバーのActive Directory認証に関する一般的な知識はありますか？
Linuxサーバーとmodernmodern（---）Windows Serverオペレーティングシステム（CentOS/RHELに焦点を当てた）のActive Directory認証/統合に関する2014年の一般的な知識は何ですか？
2004年に統合を試みた最初の年から、これに関するベストプラクティスが変わったようです。どの方法が現在最も勢いがあるのか、私にはよくわかりません。
フィールドで、私は見ました：
Winbind/Samba
まっすぐLDAP
時々LDAP + Kerberos
Microsoft Windows Services for Unix（SFU）
Microsoft Identity Management for Unix
NSLCD
[〜＃〜] sssd [〜＃〜]
FreeIPA
Centrify
Powerbroker（née同様）
Winbindは常にひどく、信頼性が低いように見えました。 CentrifyやLikeのような商用ソリューションは常に機能しましたが、この機能はOSに組み込まれているため不要であるように見えました。
最後に行ったいくつかのインストールでは、Microsoft Identity Management for Unixの役割機能がWindows 2008 R2サーバーとLinux側のNSLCDに追加されました（ RHEL5）。これはRHEL6まで機能しました。NSLCDとメモリリソース管理の問題でメンテナンスが不足していたため、SSSDが変更されました。 Red HatもSSSDのアプローチを支持しているようで、私の使用にはそれで問題ありません。
ドメインコントローラーがWindows 2008 R2Coreシステムであり、UnixのID管理機能を追加する機能がない新しいインストールを使用しています。また、この機能は非推奨であると言われています Windows Server 2012 R2にはもう存在しません 。
この役割をインストールすることの利点は、このGUIが存在することでありながら、ユーザー属性の簡単な1ステップの管理を可能にします。
だが...
リモートサーバー管理ツール（RSAT）のネットワーク情報サービス（NIS）ツール用サーバーオプションは廃止されました。ネイティブLDAP、Sambaクライアント、Kerberos、またはMicrosoft以外のオプションを使用します。
そのため、前方互換性が失われる可能性がある場合に依存するのは非常に困難です。顧客はWinbindの使用を望んでいますが、Red Hat側から見たすべてがSSSDの使用を指しています。
適切なアプローチは何ですか？
your環境でこれをどのように処理しますか？
2014年3月、Red Hatは Red Hat Enterprise ServerとActive Directoryの統合 のリファレンスアーキテクチャを公開しました。 （この資料は確かに最新で関連性のあるものでなければなりません。）私はこれを回答として投稿するのは嫌ですが、回答フィールドに転送するには資料が多すぎます。
このドキュメント （修正済み）ホットプレスは、Red Hat Enterprise Linux（RHEL）7の新機能に焦点を当てているようです。先週のサミットで公開されました。
このリンクが古くなった場合はお知らせください。回答を適宜更新します。
私は個人的にWinBindをかなり確実に認証に使用しました。 rootまたはその他のローカルアカウントを持つユーザーがwinbinddにアクセスしてバウンスすることを要求する、非常にまれなサービス障害があります。もしあなたがそれに努力を注ぎたいのであれば、これはおそらく適切な監視を介して対処することができます。
Centrifyには追加の機能がありますが、これは個別の構成管理によって提供できることは注目に値します。 （人形など）
2014年6月16日編集：
re：「CentrifyやLikeのような商用ソリューションは常に機能していましたが、この機能はOSに組み込まれているため、不要であるように見えました。」
さて、私たちのほとんどは、XYZオペレーティングシステムがついにAD統合パズルを解読することを長年聞いてきたと思います。私見の問題は、OSベンダーにとって、AD統合はチェックボックス機能であることです。つまり、彼らは、そのチェックボックスを取得するためにある程度機能するものを提供する必要があり、そのチェックボックスは通常、機能するだけです...
- oSプラットフォームと
- そのプラットフォームの現在のバージョンと
- より新しいバージョンのActive Directoryに対して。
実際のところ、ほとんどの環境はOSベンダーとOSバージョンの点でモノリシックではなく、古いバージョンのADがあります。そのため、Centrifyなどのベンダーは、UNIX/Linux/Macなどの450以上のフレーバーをサポートする必要があります。 Windows 2000からWindows 2012 R2に対して、RHEL 7だけでなくWindows 2012 R2に対して。
さらに、ADの展開方法を考慮する必要があります。OSベンダーのAD統合では、読み取り専用ドメインコントローラー（RODC）、一方向の信頼、マルチフォレストサポートなどがサポートされます。既存のUIDスペース（これを行います）には、UIDをADに移行するための移行ツールがあります。また、OSベンダーのADサポートは、UIDスペースがフラットでない状況で複数のUIDを単一のADにマップする機能に対応していますか？そして、どうですか...まあ、あなたはアイデアを得ます。
次にサポートの問題があります...
ポイントは、ADの統合は概念的には簡単に見える可能性があり、ベンダーの最新OSで「無料」である可能性があり、1つのベンダーのOSのバージョンが1つだけで、最新バージョンのバニラADがあり、発生する問題を修正するために最善を尽くすOSベンダーとのプレミアムサポート契約。それ以外の場合は、専門のサードパーティソリューションを検討する必要があります。
リモートサーバー管理ツール（RSAT）のネットワーク情報サービス（NIS）ツール用サーバーオプションは廃止されました。
これは私にとって驚くべきことではありません。NISは、Sunが私たちを憎んでおり、私たちが惨めになりたかったという証拠です。
ネイティブLDAP、Sambaクライアント、Kerberos、またはMicrosoft以外のオプションを使用します。
これは良いアドバイスです。 「ネイティブLDAPを使用する（SSLを使用してください）」という選択肢があるとしたら、これには多くのオプションがあり、私が最もよく知っている2つは pam_ldap + nss_ldap （PADLから）、または結合された nss-pam-ldapd （これはフォークとして始まり、開発と拡張が進行中です）。
RedHatについて具体的に質問しているので、 RedHatは他の選択肢を提供します SSSDを使用することに注意してください。
環境がすべてRedHatである場合（または単にRedHatシステムが多数ある場合）、公式にサポートされている「RedHat Way of Doing Things」を調査することは、確かに時間の価値があります。
私自身はRedHat/SSSDを使用した経験がないので、ただドキュメントを読んでいますが、非常に堅牢でよく設計されているようです。
提案された方法のうち、賛否両論のリストを挙げましょう。
まっすぐなKerberos/LDAP
長所：適切に構成されていれば、うまく機能します。まれに、回復力のあるブレークは、ネットワークの不具合を乗り越えます。 ADでの変更、スキーマの変更、ADへの管理者アクセスは必要ありません。自由。
短所：構成が比較的難しい。複数のファイルを変更する必要があります。認証サーバー（Kerberos/LDAP）が使用できない場合は機能しません。
Winbind
長所：設定が簡単。基本的なSudo機能。自由。
短所：集中的なサポート。ネットワークの復元力はありません。ネットワークに問題があると、LinuxマシンがADから削除され、サーバーの再登録が必要になる場合があります。これはサポートタスクです。 ADの管理者アカウントへのアクセスが必要です。 ADでスキーマを変更する可能性があります。
Centrify/Likewiseなど.
長所：構成が比較的簡単です。
短所：Sudoの機能が独自仕様に変更され、サポートが難しくなります。サーバーあたりのライセンス費用。管理するには追加のスキルが必要です。
SSSD
長所：構成が簡単な1つの構成ファイル。現在および将来のすべての認証方法で機能します。スケーラブルで、システムとともに成長します。切断モードで動作します。ネットワークの回復力。 ADスキーマを変更する必要はありません。 AD管理者の資格情報は必要ありません。無料、サポートされています。
短所：DNSの自動更新などのwinサービスがない。 CIFS共有を構成する必要があります。
概要
利点と欠点を見ると、SSSDが最も勝っています。新しいシステムの場合、SSSD以外を使用する理由はありません。これは、現在のすべての認証方法で機能するインテグレーターであり、利用可能な場合は新しい方法を追加できるため、システムとともに成長できます。ネイティブのLinuxメソッドを使用し、はるかに信頼性が高く、高速です。キャッシングがオンになっている場合、システムは完全に切断されたシステムで完全なネットワーク障害が発生しても動作します。
Winbindは、変更する必要のある作業が多すぎる場合に、既存のシステムに使用できます。
Centrifyには統合に問題があり、コストがかかる可能性があります。バグのほとんどは新しいリリースで修正されていますが、頭痛の原因となるバグがまだいくつかあります。
私はこれらすべての方法を使用してきましたが、SSSDは明らかに勝者です。古いシステムでも、WinbindからSSSDへの変換のROIは非常に高くなります。 SSSDを使用しない特別な理由がない限り、常にSSSDを使用してください。
これについてコメントする必要があります：
Centrifyには追加の機能がありますが、これは個別の構成管理によって提供できることは注目に値します。 （人形など）
セントリファイと一緒に仕事をしている人として、そのコメントがどこから来たのかわかりません。 this を見ると、config mgmtツールala Puppetで取得できない機能が大量にあることがわかります。たとえば、複数のUIDから単一のADアカウント（ゾーン）へのマッピングのサポート、完全なActive Directoryドメイン信頼のサポート（3ページのRed Hatソリューションドキュメントではサポートされていません）など。
しかし、このRed Hatガイドに戻りましょう。 Red Hatがこれを公開しているのは素晴らしいことです。オプションは適切です。基本的なAD統合を行うための10のオプションが提供されていることに注意してください。ほとんどのオプションはWinbindのバリエーションであり、15ページにはそれぞれの長所と短所がリストされており、それぞれに必要な一連の手動ステップがあります（対応する短所/上記の機能の欠如）。 Centrify Expressの利点は、上記の他のコメンターによると次のとおりです。
- すべての手動ステップなしでインストールするのは簡単です...
- 無料で...
- 問題はRed Hat V7に限定されません。これは、1つのバリアントだけではなく、Linuxに関する質問であるため重要です。Centrifyは、300以上の* nixをサポートしています...
- windows 2008だけでなく、Windows ADのすべてのバリアントをサポートします。CentrifyとWinbindの比較を公開しました here ですが、オープンソースではありません。
最後に、それはあなたがそれを自分で転がしたいのか、それとも商用のソリューションを使いたいのかということです。本当にあなたがどこでどのように時間を過ごすかが問題です。