Active Directory 信頼関係の構成

どうも、Miyaです。

今回は、Active Directory(以下AD)の信頼関係についてご説明します。
複雑なAD環境において、相手先ドメインまたはフォレストのリソースへのアクセスを可能にするために、お互いに信頼関係を結ぶ必要があります。

例えば、信頼関係を結ぶことでcontoso.comがadatum.comのリソース(例えばファイルサーバーなど)へのアクセスを実現することが出来ます。

本記事では、ADの信頼関係についての概要とデモストレーションをご紹介したいと思います。

スポンサーリンク




ADにはさまざまな環境が想定されます。環境によって結ぶ信頼関係の種類が異なり、種類が異なればもちろんそれぞれに特性があります。
ここでは、結ぶことができる信頼関係の紹介と概要の説明をしたいと思います。

なんですが…その前に、信頼方向推移性を理解しておきましょう。

信頼方向とは?

信頼関係には、入力方向と出力方向の2種類の信頼方向が存在します。
ADに限らず、信頼関係には信頼する側と信頼される側が存在し、それらを方向で表しているんですね。
信頼する=出力方向信頼される=入力方向で覚えておきましょう。

例えば、contoso.comからadatum.comに対して、出力方向の信頼関係が確立されたとしましょう。
その場合、contoso.comはadatum.comを信頼するため、contoso.comは自ドメインのリソースに対して、adatum.comのユーザーがアクセス要求すると、contoso.comのDCはそのユーザーにセッションチケットを配布します。adatum.comのユーザーはセッションチケットを提示することで、リソースにアクセスすることが出来るようになります。

ただし、逆方向のアクセスは信頼されていないため、セッションチケットは配布されません。
信頼関係

推移性とは?

推移性とは、信頼関係のパスを指します。下図を例に挙げると、同一フォレスト内にcontoso.comとその子ドメインとしてna.contoso.comが構成されているとします。
このcontoso.comとna.contoso.comは信頼関係が確立されており、双方向の信頼関係が結ばれています。
その環境に、contoso.comからadatum.comに対して出力方向の信頼関係を確立します。
この時、na.contoso.com⇒adatum.comに対しての信頼関係が推移性により確立されます。
親子信頼

ちなみに、adatum.comがna.contoso.comのリソースに対してアクセスした場合、上記の画像では直接アクセスしているように見えますが、adatum.comからna.contoso.comへの入力方向の信頼は明示的に確立していないため、contoso.comを経由してアクセスするイメージになります。
このような信頼関係を信頼パスなんて呼んだりしています。

信頼関係の種類

それぞれの信頼関係を方向・推移性の有無を添えて、解説した表が下記の通りです。
信頼関係

同一フォレスト内の場合、新しいドメインを構成したすると、双方向の信頼関係が自動的に生成されます。
また推移性があることから、フォレスト内のドメイン間は、全て信頼関係が確立されていることとなります。

また、フォレスト信頼には推移性があると記載されておりますが、3番目のフォレストに暗黙的に拡張することはできません。
例えば、フォレスト1とフォレスト2に信頼関係を確立し、フォレスト2とフォレスト3を信頼関係を確立した場合、フォレスト1とフォレスト3の間に推移性による信頼は成立しません。
フォレスト信頼の推移性はあくまでフォレストのルートドメインの子ドメインに対して有効であり、お互いのルートドメインを経由して子ドメインにアクセスするイメージです。

親子ドメインの信頼関係

親子ドメインを構成して、信頼関係が結ばれているかを確認したいと思います。
contoso.comドメインの子ドメインとして、na.contoso.comを構成しました。
信頼関係

構成後、Active Directory ドメインと信頼関係から確認すると信頼関係が結ばれているのが確認できます。
信頼関係

また、信頼される側のドメインオブジェクトがこの情報をSystemコンテナーのTrusted Domain Objectとして保持します。
信頼関係

フォレスト間の信頼関係

次に、フォレスト間の信頼関係を確立します。
contoso.comとは別フォレストに、adatum.comをルートドメインとして構成してみました。
この異なるフォレスト間にフォレスト信頼を確立したいと思います。

異なるドメインの信頼関係を結ぶにあたって、お互いが相手先ドメインを名前解決出来る必要があります。
そのため、まずはスタブゾーンを作成して、名前解決ができるように構成しましょう。
contoso.comのDCからDNS管理マネージャーで、[新しいゾーン]ウィザードを起動しましょう。
信頼関係

スタブゾーンを選択して、[次へ]をクリックします。
信頼関係

レプリケーションスコープを選択します。
信頼関係

[前方参照ゾーン]を選択し、[次へ]をクリックします。
信頼関係

ゾーン名に相手先ドメイン名を入力して、[次へ]をクリックします。
信頼関係

ゾーンの読み込み元となるゾーンDNSサーバーのIPアドレスを入力し、[次へ]をクリックします。
信頼関係

最後に[完了]で作成完了です。
信頼関係

contoso.comの設定が完了すれば、adatum.comも同様にスタブゾーンを作成しておきます。

それでは、contoso.com⇒adatum.comに対して出力方向の信頼関係を確立したいと思います。
[Active Directory ドメインと信頼関係]⇒[プロパティ]⇒[信頼]タブから[新しい信頼]をクリックします。
信頼関係

[次へ]をクリックします。
信頼関係

相手先フォレストの信頼関係を確立したいドメイン名を入力します。
信頼関係

フォレストの信頼を選択し、[次へ]をクリックします。
信頼関係

方向を選択します。今回はcontoso.comからadatum.comに対して出力方向を構成します。
信頼関係

相手先ドメインのEnterprise Adminsの資格情報を把握しているのであれば、[このドメインと指定されたドメインの両方]を選択することで、adatum.comドメインのDCで作業する手間が省けます。
信頼関係

adatum.comドメインのEnterprise Adminsの資格情報を入力します。
信頼関係

信頼認証のレベルを選択します。[フォレスト全体の認証]とした場合、adatum.comドメインの全ユーザーに対してセッションチケットを配布する設定となります。
一方、[認証の選択]とした場合、adatum.comからcontoso.comリソースにアクセスできるユーザーを明示的に設定しなければ、セッションチケットは配布されません。
今回は、[認証の選択]を選択したいと思います。
信頼関係

[次へ]をクリックします。
信頼関係

ローカルフォレストのUPNサフィックスから、認証ルーティングさせたいサフィックスを選択します。
信頼関係

[次へ]をクリックします。
信頼関係

構成した信頼関係に対して検証出来ます。
信頼関係

問題がなければ、信頼関係の確立は完了です。お疲れさまでした。
信頼関係

信頼による相手先リソースへのアクセス

それでは、先の手順で構成したフォレスト間信頼環境を利用して、相手先コンピューターの共有フォルダにアクセスしたいと思います。
信頼関係の推移性

adatum.comのクライアントが、contoso.comドメインのリソースアクセスする時、相手先DCに対してセッションチケットを要求します。
contoso.comのDCは、adatum.comクライアントを知らないため、Systemコンテナに格納されている信頼オブジェクトを参照し、信頼関係が結ばれていることを確認します。
contoso.comのDCは、adatum.comのクライアントを照会し、アクセスするためのセッションチケットを発行します。

さて、先の手順で構成した時、認証の選択を選びました。
そのため、リソースにアクセスするユーザーを明示的に許可しなければ、下記のようなエラーメッセージが表示されます。
信頼関係

信頼する側であるcontoso.comの共有フォルダを配置しているTEST02サーバーオブジェクトの[プロパティ]から、アクセスを許可したいadatum.comユーザーを追加し、[認証を許可]にチェックを入れます。
信頼関係

adatum.comのadministratorから、contoso.comのTEST02サーバーへアクセスします。
信頼関係

ちゃんとサーバーにアクセスして、共有フォルダが見えましたね、

おわりに

いかがでしたでしょうか?
企業の合併などで、相手企業がADによるID管理をしていた場合、信頼関係を結ぶことで統合するケースもあります。
ADの設計は知れば知るほど奥が深いなぁと思いしる毎日です…笑

それでは、よいWindows Serverライフをっ♪

スポンサーリンク

コメントを残す

*