真のActiveDirectory統合の追求
私を笑って「ActiveDirectoryが必要な場合はWindowsを使用してください」と言うか、Googleを使用するように指示する前に、私に聞いてください。
私の会社はADに大きく依存しています。いや、私たちはこの時点でそれと結婚していて、フォーチュン10の会社として、それは変わっていません。ただし、環境には多くの* nixシステム（主にRHELとSLES）があり、IDソースとしてActiveDirectoryと統合するための優れたメカニズムをまだ見つけていません。少なくとも、私は以下を提供するために何かが必要です：
- AD資格情報による認証（ユーザーをドアに入れる）
- 認証された認証（システムの領域へのユーザーアクセスを許可）
- 監査（ユーザーアクションをAD資格情報に関連付けることができる）
- ADグループのサポート（Vanilla LDAPだけでなく、システム上の個々のユーザーを追加/削除する必要がある）
- ADの信頼に基づく複製/ミラーリングされたIDソースではありません（2つの巨大なシステムは必要ありません）
私が見つけたトップソリューションは次のとおりです。
- Centrify
- PowerBroker Open（PBIS Open、以前は同様に-Open）
- SSSD + SELinux
Centrify。 。 。ただ醜いです。私は本当のファンではありませんでした。また、私の会社のニーズのために、Centrify-Expressを使用できないため、無料ではなく、無制限のライセンスもありません。しかし、それは私たちが見つけた最良の解決策であり、私は何か他のものを見つけたいと切望しています。
PBISオープンは私が傾いているものです。これは、VMwareがvShieldのバックエンドで使用するものであり、非常にうまく機能します。セットアップに必要なコマンドはわずかで、ADグループをサポートし、セカンダリID管理システムはありません。ADと直接通信します。私がそのルートに進まない唯一の理由は、ネイティブソリューションが好きだからです。そして、現代のディストリビューションにすでに含まれている、より良い方法があれば、私はそれですべてです。
SSSD + SELinuxは素晴らしいサウンドでした。セットアップは厄介ですが、柔軟性があり、ネイティブであり、ほとんどの最新のディストリビューションでサポートされています。 （私が理解していることから）それが欠けている唯一のものは、ADグループのサポートです。多くの記事は、FreeIPAまたは同様のものを利用してこの機能を追加することを提案していますが、さらに読むと、これは要件5に違反し、基本的に仲介者IDサービスを作成します。基本的にADを複製したり、セカンダリIDサービスへの信頼を設定したりすることには興味がありません。
私が投げかけた他のクラッジオプションには、Puppet（私たちが使用している）を使用して/ etc/password、shadow、groupファイルをエンドポイントにプッシュすることが含まれますが、開発が必要であり、信じられないほど間接的であり、何かがひどく南に行くのを見ることができました。より良いオプションは、SSSD + SELinuxをPuppetのアイデアに追加することです。それは災害を単純化するでしょうが、それでも災害です。
何が欠けているのか、何を使用しているのか、そしてLinux AD統合の頭痛の種を解決するために私が説明していない「新しい辛さ」とは何ですか？
ここでのソリューションは、FreeIPAまたはCentrify/PowerBrokerのいずれかです。 FreeIPAは標準のRHELサブスクリプションの一部であるため、すでにいくらかの節約があります。
FreeIPAは、すべてのユーザーとグループがActiveDirectoryからアクセスできるモードで実行できます。これらのユーザーとグループのFreeIPAのPOSIX固有の環境（Sudoルール、公開SSHキー、ホストベースのアクセス制御定義、SE Linuxコンテキスト割り当てなど）へのマッピングのみを保持します。そのためには、ADユーザー/グループの一部をFreeIPAの一部のグループにマッピングする必要がありますが、これは情報の重複ではなく、AD固有ではない部分で修正されています。
FreeIPAがActiveDirectoryとの互換性を実装する方法は、ある種のActiveDirectory互換のフォレストとしてそれ自体を提示することです。フォレスト間の信頼を介してADユーザーがFreeIPAリソースを消費できるようにするだけで十分ですが、FreeIPAユーザーが信頼の反対側にあるWindowsシステムにアクセスできるようにするだけでは不十分です。あなたは最初の部分に興味を持っているようですので、これは問題ないはずです。
すでにRHEL7.1ベータの一部であるFreeIPA4.1（RHEL 7.1が「間もなく」リリースされることを願っています）では、FreeIPAのADユーザーとグループのオーバーライドを維持する強力なメカニズムがあり、SSSDはそれらすべてを検出できますサーバーごとの粒度。
SSSDについて話すとき、「実際のADグループ」とはどういう意味かを本当に聞きたいです。 SSSDの新しいバージョンでは、グループにPOSIX属性を設定する必要はなく、ADプロバイダーが使用されている場合は、ほとんどの場合、TokenGroupsからグループメンバーシップを読み取ります。
また、RHEL-7.1（アップストリーム1.12 +）では、SSSDはGPOポリシーを使用してアクセス制御チェックを実行する機能を取得しました。
特定の質問がある場合は、遠慮なくsssd-usersリストに書き込んでください。
Redhatオファリングはここで十分にカバーされています：
LinuxサーバーのActive Directory認証に関する一般通念？
最近のインストールでは、これはSSSD（組み込み）およびldapまたはsssd.confグループフィルターを介して行われました。
Linuxユーザーはシステム上で正確に何をする必要がありますか？
私はWinbind + Kerberoseも使用しており、何年も問題なく動作しますが、一部のマシンでも何年も使用していて満足しているため、すべてをPbisに移行しています。しかし、ネイティブソリューションも必要なので、RedHatのこのドキュメントに記載されているように、sssd統合のテストを開始します。 https://www.redhat.com/en/files/resources/en-rhel-intergrating-rhel-6-active-directory.pdf
aD統合のさまざまなシナリオがあります。
私はPBISのオープンソースバージョンを使用しています。バージョン6では、マシンにしばらく（数か月など）ログオンしていなかった場合、ログオンするとタイムアウトになることがわかりました。少なくとも、多くのマシンに当てはまりました。バージョン8ではその問題は発生していません。
PBISで十分だと思いました。それは私が気にしたオプションを設定することを可能にしました（デフォルトのホームディレクトリ、ログオンのためのドメインを想定する、アクセス権を持つグループを設定するなど）。
私は他に何も試したことはありません。しかし、私はPBISに満足していると言えます。
それをインストールするためのPuppetモジュールがあります（私のバージョン： https://github.com/etlweather/puppet-pbis ）。
winbind + samba + kerberosはどうですか？
- AD資格情報による認証（ユーザーをドアに入れる）
チェック済み
- 認証された認証（システムの領域へのユーザーアクセスを許可）
チェック済み
- 監査（ユーザーアクションをAD資格情報に関連付けることができる）
/ var/log/secure？チェック済み
- ADグループのサポート（Vanilla LDAPだけでなく、システム上の個々のユーザーを追加/削除する必要がある）
チェックされているローカルグループの広告グループまたは広告ユーザーの両方を許可します
- ADの信頼に基づく複製/ミラーリングされたIDソースではありません（2つの巨大なシステムは必要ありません）
freeipaは必要ありません、チェック済み