LinuxサーバーのActive Directory認証に関する一般的な知識

Linuxサーバーおよび最新の Windows Serverオペレーティングシステム（CentOS / RHELに焦点を当てた）のActive Directory認証/統合に関する2014年の一般的な知恵とは何ですか？

2004年に統合を最初に試みて以来、長年にわたって、これを取り巻くベストプラクティスは変わってきたようです。どの方法が現在最も勢いがあるかはよくわかりません。

フィールドで、私は見た：

winbindの/ Sambaの
ストレートアップ LDAP
時々 、LDAP + Kerberosの
Microsoft WindowsサービスのUNIX（SFU）のための
Unix用のMicrosoft ID管理
NSLCD
SSSD
FreeIPAの
Centrify
POWERBROKER（旧姓同様）

Winbindは常にひどくて信頼性が低いように見えました。CentrifyやSimilarなどの商用ソリューションは常に機能していましたが、この機能はOSに組み込まれているため、不要と思われました。

私が最後に行ったいくつかのインストールでは、Windows 2008 R2サーバーに追加されたUnixのMicrosoft Identity Management機能がLinux側のNSLCD（RHEL5用）に追加されました。これは、NSLCDのメンテナンス不足とメモリリソース管理の問題によりSSSDの変更を余儀なくされたRHEL6まで機能していました。また、Red HatはSSSDアプローチを支持しているように見えたので、私の使用には問題ありませんでした。

ドメインコントローラーがWindows 2008 R2 コアシステムであり、UnixのID管理機能を追加する機能を持たない新しいインストールで作業しています。また、この機能は非推奨であり、Windows Server 2012 R2には存在しないと言われています。

この役割をインストールする利点は、このGUIが存在することです。一方、ユーザー属性を簡単にワンステップで管理できます。

しかし...

リモートサーバー管理ツール（RSAT）のネットワーク情報サービス（NIS）ツールのサーバーオプションは廃止されました。ネイティブLDAP、Sambaクライアント、Kerberos、またはMicrosoft以外のオプションを使用します。

そのため、前方互換性が損なわれる可能性がある場合、信頼するのは非常に困難です。お客様はWinbindを使用したいと考えていますが、Red Hat側から見ると、すべてがSSSDの使用を指しています。

適切なアプローチは何ですか？環境で
これをどのように処理しますか？

2014年3月、Red HatはRed Hat Enterprise ServerとActive Directoryを統合するためのリファレンスアーキテクチャを公開しました。（この資料は確かに最新で関連性が高いはずです。）これを回答として投稿するのは嫌ですが、実際には回答欄に移すには多すぎる資料です。

このドキュメント（修正済み）は、Red Hat Enterprise Linux（RHEL）7の新機能に焦点を当てているようです。これは先週のSummitで公開されました。

このリンクが古くなった場合はお知らせください。それに応じて回答を更新します。

私は個人的にWinBindを認証にかなり確実に使用しました。非常にまれなサービス障害があり、rootまたは他のローカルアカウントを持つユーザーがwinbinddにアクセスしてバウンスすることが必要です。これはおそらく、適切な監視を行うことで対処できます。

Centrifyには追加の機能があることに注意してください。ただし、これは個別の構成管理によって提供できます。（人形など）

編集6/16/14：

Red Hat Enterprise Linux 7 Windows統合ガイド

re：「CentrifyやSimilarなどの商用ソリューションは常に機能していましたが、この機能はOSに組み込まれているため、不必要に思えました。」

私たちの多くは、XYZオペレーティングシステムが最終的にAD統合パズルを解くと長年聞いてきたと思います。私見の問題は、OSベンダーにとって、AD統合はチェックボックス機能であるということです。つまり、そのチェックボックスを取得するためにちょっと動作するものを配信する必要があります。

1. OSプラットフォームと
2. そのプラットフォームの現在のバージョン
3. Active Directoryのより新しいバージョンに対して。

現実には、ほとんどの環境はOSベンダーとOSバージョンの点でモノリシックではなく、ADの古いバージョンがあります。Centrifyなどのベンダーが450以上のフレーバーのUNIX / Linux / Mac / etcをサポートしなければならないのはそのためです。Windows 2000からWindows 2012 R2に対して、RHEL 7だけでなくWindows 2012 R2に対しても。

さらに、ADの展開方法を考慮する必要があるため、OSベンダーのAD統合は、読み取り専用ドメインコントローラー（RODC）、一方向の信頼、マルチフォレストサポートの提供などをサポートします。既存のUIDスペース（これから）、UIDをADに移行するための移行ツールがあります。また、OSベンダーのADサポートは、UIDスペースがフラットではない状況で複数のUIDを単一のADにマップする機能に対応していますか。そして、どうでしょう...あなたはアイデアを得ます。

次に、サポートの質問があります...

ポイントは、ADの統合は概念的には簡単に思えるかもしれず、ベンダーの最新のOSでは「無料」であり、あるベンダーのOSのバージョンが1つだけで、最新バージョンのバニラADがあれば、おそらく動作する可能性がありますOSベンダーとのプレミアムサポート契約。今後発生する問題を修正するために最善を尽くします。それ以外の場合は、専門のサードパーティソリューションを検討することをお勧めします。

リモートサーバー管理ツール（RSAT）のネットワーク情報サービス（NIS）ツールのサーバーオプションは廃止されました。

これは私にとって驚きではありません。NISは、Sunが私たちを憎み、惨めになりたかった証拠です。

ネイティブLDAP、Sambaクライアント、Kerberos、またはMicrosoft以外のオプションを使用します。

これは良いアドバイスです。「（、SSLを介してください）を使用するネイティブLDAP」私が言うの選択肢を考える-このために利用可能な多くのオプションがあり、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）が使用できない場合は機能しません。

ウィンバインド

長所：設定が簡単です。基本的な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には追加の機能があることに注意してください。ただし、これは個別の構成管理によって提供できます。（人形など）

Centrifyで作業する人として、そのコメントがどこから来たのかわからない。見て、この、あなたは人形ALA設定MGMTツールで取得していない機能の最大積載量があることがわかります。たとえば、単一のADアカウント（ゾーン）への複数のUIDのマッピングのサポート、完全なActive Directoryドメインの信頼のサポート（Red Hatソリューションでは3ページでサポートされていません）。

しかし、このRed Hatガイドに戻ります。Red Hatがこれを公開しているのは素晴らしいことです。オプションは良いです。基本的なAD統合を行うための10のオプションが得られることに注意してください。ほとんどのオプションはWinbindのバリエーションであり、15ページにはそれぞれの長所と短所がリストされており、それぞれに必要な多くの手動手順があります（上記の対応する短所/機能の欠如）。Centrify Expressの利点は、上記の他のコメンターごとに次のとおりであることです。

1. すべての手動ステップなしでインストールするのは簡単です...
2. 無料で...
3. 質問はLinuxに関係しているため、重要なRed Hat V7に限定されるものではありません。
4. Windows 2008だけでなく、Windows ADのすべてのバリアントをサポートしています。彼らはここでCentrifyとWinbindの比較を公開しましたが、オープンソースではありません。

最終的には、それを自分でロールバックするか、商用ソリューションに移行するかが決まります。本当にどこで、どのように時間を過ごすかが問題です。