web-dev-qa-db-ja.com

FreeIPAまたはRHIdMを既存のMSAD環境に統合する

FreeIPAまたはRedHatIdMを既存の環境にデプロイしたい

現在、私のドメインは別のグループによって管理されているMSADによって管理されています。 MS ADで何かを変更することは、政治的な理由で困難または不可能になると想定します。

Linuxの場合、最近、Enterprise LinuxでSSSDを使用して、MSADによって直接提供されるKerberosパスワード認証を使用するようにシステムを構成しました。 ID情報は引き続きローカルシステムで提供されます。

今の私の最大の悩みは、新しいドメインネームスペースを提案する方法を考え出すことです。

MS ADドメインのサブドメインを使用して、その制御をFreeIPAに委任できますか？

Kerberos構成がMSADを直接指すことが望ましいと思います。これはすでに非常に回復力があります。既存のインフラストラクチャを利用してみませんか？しかし、これは私にそれが価値があるよりも多くの問題をもたらすでしょうか？物事がどのように統合されるかはわかりません。

これを考慮に入れてください：

私たちのホスト命名基準は、この「app-id-dev /prd.domain.com」のようなものです。たとえば、「server01dev.domain.com」

ポリシーにより、dev/prd環境間でサーバーIDを複製しないため、サブドメインを使用する便利な方法は、前の例を「server01.dev.domain.com」に変換することだと考えていました。これの優れた機能は、ホストの短い名前を指定するときに、ドメインの検索順序がクライアントで適切に設定されていれば、dev/prdを指定する必要がなくなることです。

認識されている利点：これにより、これらのサブドメインのCAになることができます。これにより、今後関連するすべての証明書が簡素化されます。

認識されているデメリット：それは認証にとって何を意味しますか？元のドメインにすでに存在するユーザー名を使用してユーザーを認証したいのですが。例：[email protected]ではなく[email protected]

もう1つの疑問は、MS ADKerberosを直接使用することに意味があるかどうかです。FreeIPALDAPからID情報を利用できない場合でも、クライアントシステムにローカルIDがない限り、ユーザーは正しくログインできません。

それが本当の問題だとしたら、FreeIPA LDAP情報をADと同期させることは可能かと思いますが、その場合はサブドメインでユーザーを作成する必要があると思います。

または、復元力のためにMS ADを直接使用するという概念を捨てて、復元力のあるFreeIPA/RH IdM環境を作成する必要があることを受け入れる必要がありますか？

active-directoryredhatfreeipa
4
xdaxdb

まず、FreeIPAとRed Hat EnterpriseIdMを同じ意味で使用します。これが不快感を引き起こす場合は、飲み物を提案させてください。

FreeIPAは、Active Directoryとは別のKerberosレルムである必要があり、Krb5レルムに対応する別のDNSゾーンを使用する必要があります。 ADドメインが子ゾーン「dev」と「prd」とともにDNSゾーン「domain.com」を使用している場合は、「idm.domain.com」などの新しいDNSゾーンと、その下のサブレルムを作成する必要があります。それ。すべてのUPNを[email protected]、すべてのSPNをHost/SERVER123.IDM.DOMAIN）として、「IDM.DOMAIN.COM」というKrb5レルムを作成します。 .COMなど（おそらくWWW/SERVER123.PRD.IDM.DOMAIN.COM）。

ADと同じDNSゾーンを使用できますが、それは[〜＃〜]本当に[〜＃〜]悪い考えです。 DNSを使用したサービス検出が失われるだけでなく、手動でマッピングを行う必要があり、IdMレルム内のサーバーに不適切なKrbトークンを渡そうとするクライアントのトラブルシューティングが難しい問題が発生する可能性があります。

ADチームと協力して、レルム間の信頼を設定する必要があります。彼らはそれを一方向の信頼にしたいかもしれません。ADは信頼できるドメインであり、FreeIPAは信頼できるドメインです。ほとんどの場合、これは問題にはなりません。

現時点では、RHEL 7に同梱されているバージョンのFreeIPAは、フォレスト頂点ADドメインとの信頼の確立、および認証のために子ドメインへのトラバースをサポートしていません。 RHEL 7u1で、推移的な信頼サポートがFreeIPAに追加されるため、これは修正されると言われていますが、コードフリーズの翌日に機能リストが表示されるまで息を止めていません。回避策として、ユーザープリンシパルが生成される子ドメインへの信頼を設定できる必要があります。

私も同様の取り組みをしています。頑張って、これがどのように機能するかを教えてください。私は幸運にもADチームを私のチームの要素として持つことができました（そして彼らは私の真向かいに座っています）。私たちはチームレベル（分隊サイズのユニット）で同じリーダーにロールアップし、この統合が成功することを望んでいる部門リーダーから多くのサポートを受けています。

3
DTK