Active Directory におけるフォレストの信頼関係のしくみ

Active Directory Domain Services (AD DS) では、ドメインおよびフォレストの信頼関係を通じて、複数のドメインまたはフォレスト間でセキュリティが提供されます。 信頼間で認証が行われる前に、まず、Windows でユーザー、コンピューター、またはサービスによって要求されるドメインに、要求元アカウントのドメインとの信頼関係があるかどうかを確認する必要があります。

この信頼関係を確認するために、Windows セキュリティ システムでは、要求を受信するサーバーのドメイン コントローラー (DC) と、要求元アカウントのドメインにある DC との間の信頼パスが計算されます。

AD DS と Windows 分散セキュリティ モデルによって提供されるアクセス制御メカニズムにより、ドメインおよびフォレストの信頼の操作のための環境が提供されます。 これらの信頼を適切に機能させるには、すべてのリソースまたはコンピューターに、配置先のドメイン内の DC への直接の信頼パスがある必要があります。

信頼パスは、信頼されたドメイン機関への認証済みリモート プロシージャ コール (RPC) 接続を使用して、Net Logon サービスによって実装されます。 また、セキュリティで保護されたチャネルは、ドメイン間の信頼関係を通じて、他の AD DS ドメインに拡張されます。 このセキュリティで保護されたチャネルは、ユーザーとグループのセキュリティ識別子 (SID) を含む、セキュリティ情報を取得して検証するために使用されます。

Domain Services に信頼を適用する方法の概要については、フォレストの概念と機能に関する記事を参照してください。

Domain Services で信頼を使用するには、フォレストの信頼を使用するマネージド ドメインを作成します。

信頼関係のフロー

信頼を介したセキュリティで保護された通信のフローによって、信頼の柔軟性が決まります。 信頼を作成または構成する方法によって、通信がフォレスト内またはフォレスト間でどの程度拡張されるかが決まります。

信頼を介した通信のフローは、信頼の方向によって決まります。 信頼は、一方向または双方向であることがあり、推移的または非推移的である場合があります。

次の図は、ツリー 1 とツリー 2 のすべてのドメインに、既定で推移的な信頼関係があることを示しています。 その結果、ツリー 1 のユーザーは、ツリー 2 のドメインにあるリソースにアクセスでき、ツリー 2 のユーザーはツリー 1 のリソースにアクセスできます (リソースで適切なアクセス許可が割り当てられている場合)。

一方向と双方向の信頼

信頼関係を使用して、リソースへのアクセスを一方向または双方向にすることができます。

一方向の信頼は、2 つのドメイン間に作成される一方向の認証パスです。 ドメイン A とドメイン B 間の一方向の信頼では、ドメイン A のユーザーはドメイン B のリソースにアクセスできます。しかし、ドメイン B のユーザーは、ドメイン A のリソースにアクセスすることはできません。

一部の一方向の信頼は、作成される信頼の種類に応じて、非推移的または推移的にすることができます。

双方向の信頼では、ドメイン A はドメイン B を信頼し、ドメイン B はドメイン A を信頼します。この構成は、2 つのドメイン間で認証要求を双方向に渡すことができることを意味します。 一部の双方向の関係は、作成される信頼の種類に応じて、非推移的または推移的にすることができます。

オンプレミスの AD DS フォレスト内のすべてのドメイン信頼は、双方向の推移的な信頼です。 新しい子ドメインが作成されると、新しい子ドメインと親ドメインとの間に双方向の推移的な信頼が自動的に作成されます。

推移的な信頼と非推移的な信頼

信頼をそれが形成された 2 つのドメインの外部で拡張できるかどうかは、推移性によって決まります。

• 他のドメインとの信頼関係を拡張する場合は、推移的な信頼を使用できます。
• 他のドメインとの信頼関係を拒否する場合は、非推移的な信頼を使用できます。

フォレスト内に新しいドメインを作成するたびに、新しいドメインとその親ドメインとの間に双方向の推移的な信頼関係が自動的に作成されます。 子ドメインが新しいドメインに追加された場合、信頼パスはドメイン階層を上方向に流れ、新しいドメインとその親ドメインとの間に作成された最初の信頼パスが拡張されます。 推移的な信頼関係は、形成されるドメイン ツリーを上方向に流れ、ドメイン ツリー内のすべてのドメイン間に推移的な信頼が作成されます。

認証要求はこれらの信頼パスに従うため、フォレスト内のドメインからのアカウントは、フォレスト内のその他のドメインで認証できます。 適切なアクセス許可を持つアカウントでは、1 回のサインイン プロセスで、フォレスト内の任意のドメインのリソースにアクセスできます。

フォレストの信頼

フォレストの信頼は、セグメント化された AD DS インフラストラクチャを管理し、複数のフォレストにわたるリソースやその他のオブジェクトへのアクセスをサポートするのに役立ちます。 フォレストの信頼は、サービス プロバイダー、合併または買収される企業、コラボレーション ビジネス エクストラネット、管理上の自治権を得るためのソリューションを探している企業に役立ちます。

フォレストの信頼を使用すると、2 つの異なるフォレストをリンクして、一方向または双方向の推移的な信頼関係を形成することができます。 フォレストの信頼では、管理者は 2 つの AD DS フォレストを 1 つの信頼関係に接続し、フォレスト全体でシームレスな認証および承認エクスペリエンスを提供することができます。

フォレストの信頼は、あるフォレストのフォレスト ルート ドメインと、別のフォレストのフォレスト ルート ドメインとの間でのみ作成できます。 フォレストの信頼は 2 つのフォレスト間でのみ作成でき、3 番目のフォレストに暗黙的に拡張することはできません。 この動作は、フォレスト 1 とフォレスト 2 の間にフォレストの信頼が作成され、フォレスト 2 とフォレスト 3 の間に別のフォレストの信頼が作成された場合、フォレスト 1 にはフォレスト 3 との暗黙の信頼がないことを意味します。

次の図は、1 つの組織内の 3 つの AD DS フォレスト間の 2 つの別のフォレストの信頼関係を示しています。

この構成例では、次のようにアクセスできます。

• フォレスト 2 のユーザーは、フォレスト 1 またはフォレスト 3 のドメインにあるリソースにアクセスできます
• フォレスト 3 のユーザーは、フォレスト 2 のドメインにあるリソースにアクセスできます
• フォレスト 1 のユーザーは、フォレスト 2 のドメインにあるリソースにアクセスできます

この構成では、フォレスト 1 のユーザーがフォレスト 3 のリソースにアクセスすることはできません。その逆も同様です。 フォレスト 1 とフォレスト 3 の両方のユーザーがリソースを共有できるようにするには、2 つのフォレスト間に双方向の推移的な信頼を作成する必要があります。

2 つのフォレスト間に一方向のフォレストの信頼が作成された場合、信頼される側のフォレストのメンバーは、信頼する側のフォレストにあるリソースを利用できます。 しかし、信頼は一方向でしか動作しません。

たとえば、一方向のフォレストの信頼がフォレスト 1 (信頼される側のフォレスト) とフォレスト 2 (信頼する側のフォレスト) の間に作成された場合、次のようになります。

• フォレスト 1 のメンバーは、フォレスト 2 にあるリソースにアクセスできます。
• フォレスト 2 のメンバーは、同じ信頼を使用してフォレスト 1 にあるリソースにアクセスすることはできません。

フォレストの信頼の要件

フォレストの信頼を作成するには、その前に、適切なドメイン ネーム システム (DNS) インフラストラクチャが整備されていることを検証する必要があります。 フォレストの信頼は、次のいずれかの DNS 構成を使用できる場合にのみ作成できます。

• 単一のルート DNS サーバーが両方のフォレスト DNS 名前空間のルート DNS サーバーである - ルート ゾーンには、各 DNS 名前空間の委任が含まれ、すべての DNS サーバーのルート ヒントにはルート DNS サーバーが含まれます。

• 共有ルート DNS サーバーがなく、各フォレスト DNS 名前空間のルート DNS サーバーで、各 DNS 名前空間の DNS 条件付きフォワーダーを使用して、他の名前空間の名前に対するクエリをルーティングする場合。

  重要

  信頼のある Microsoft Entra Domain Services フォレストでは、この DNS 構成を使用する必要があります。 フォレストの DNS 名前空間以外の DNS 名前空間をホストすることは、Microsoft Entra Domain Services の機能ではありません。 条件付きフォワーダーは適切な構成です。

• 共有ルート DNS サーバーがなく、各フォレスト DNS 名前空間のルート DNS サーバーで、各 DNS 名前空間に構成されている DNS セカンダリ ゾーンを使用して、他の名前空間の名前に対するクエリをルーティングする場合。

AD DS でフォレストの信頼を作成するには、Domain Admins グループ (フォレスト ルート ドメイン内) または Active Directory の Enterprise Admins グループのメンバーである必要があります。 各信頼には、両方のフォレストの管理者が知っておく必要があるパスワードが割り当てられます。 両方のフォレストの Enterprise Admins のメンバーは、信頼を両方のフォレストに一度に作成することができます。このシナリオでは、暗号的にランダムなパスワードが、両方のフォレストに対して自動的に生成されて書き込まれます。

マネージド ドメイン フォレストでは、オンプレミスのフォレストに対する一方向の送信フォレストの信頼が最大 5 つサポートされます。 Microsoft Entra Domain Services の出力方向のフォレストの信頼は、Microsoft Entra 管理センターで作成されます。 入力方向のフォレストの信頼は、オンプレミス Active Directory で前述の特権を持つユーザーによって構成される必要があります。

信頼のプロセスと相互作用

ドメイン間およびフォレスト間トランザクションの多くは、さまざまなタスクを完了するためにドメインまたはフォレストの信頼に依存します。 このセクションでは、信頼間でリソースがアクセスされ、認証参照が評価されたときに発生するプロセスと相互作用について説明します。

認証参照処理の概要

ドメインに対する認証の要求が参照された場合、そのドメイン内のドメイン コントローラーでは、要求元のドメインとの間に信頼関係が存在するかどうかを判断する必要があります。 ドメイン内のリソースにアクセスするユーザーを認証する前に、信頼の方向と信頼が推移的か非推移性かを判断する必要もあります。 信頼される側のドメイン間で発生する認証プロセスは、使用されている認証プロトコルによって異なります。 Kerberos V5 および NTLM プロトコルでは、ドメインに対する認証の参照が異なる方法で処理されます

Kerberos V5 の参照処理

Kerberos V5 認証プロトコルは、クライアントの認証および承認情報を得るために、ドメイン コントローラー上の Net Logon サービスに依存します。 Kerberos プロトコルは、オンラインのキー配布センター (KDC) と Active Directory アカウント ストアに接続してセッション チケットを取得します。

また、Kerberos プロトコルにより、領域間チケット保証サービス (TGS) で信頼が使用され、セキュリティで保護されたチャネルを介して特権属性証明書 (PAC) が確認されます。 Kerberos プロトコルでは、Windows ブランド以外のオペレーティング システムの Kerberos 領域 (MIT Kerberos 領域など) でのみ領域間認証が行われ、Net Logon サービスとやり取りする必要がありません。

クライアントでは、認証に Kerberos V5 を使用する場合、そのアカウント ドメイン内のドメイン コントローラーからターゲット ドメイン内のサーバーに対するチケットが要求されます。 Kerberos KDC は、クライアントとサーバーの間の信頼される仲介役として機能し、2 つのパーティが相互に認証できるようにするセッション キーが提供されます。 ターゲット ドメインが現在のドメインと異なる場合、KDC では、認証要求を参照できるかどうかを判断するための論理プロセスに従います。

1. 現在のドメインは、要求されているサーバーのドメインによって直接信頼されていますか?

   • そうである場合は、要求されたドメインへの参照をクライアントに送信します。
   • そうでない場合は、次の手順に進みます。

2. 現在のドメインと、信頼パスの次のドメインとの間に推移的な信頼関係は存在しますか?

   • そうである場合は、信頼パスの次のドメインへの参照をクライアントに送信します。
   • そうでない場合は、サインイン拒否メッセージをクライアントに送信します。

NTLM の参照処理

NTLM 認証プロトコルは、クライアントの認証および承認情報を得るために、ドメイン コントローラー上の Net Logon サービスに依存します。 このプロトコルでは、Kerberos 認証を使用しないクライアントが認証されます。 NTLM では、ドメイン間で認証要求を渡すために信頼が使用されます。

クライアントで認証に NTLM を使用する場合、認証の最初の要求は、クライアントからターゲット ドメインのリソース サーバーに直接送信されます。 このサーバーでは、クライアントで応答するチャレンジが作成されます。 その後、サーバーにより、そのコンピューター アカウント ドメイン内のドメイン コントローラーにユーザーの応答が送信されます。 このドメイン コントローラーでは、ユーザー アカウントとそのセキュリティ アカウント データベースが照合されます。

アカウントがデータベースに存在しない場合、ドメイン コントローラーでは、次のロジックを使用して、パススルー認証を実行するか、要求を転送するか、要求を拒否するかが決定されます。

1. 現在のドメインに、ユーザーのドメインとの直接の信頼関係はありますか?

   • そうである場合は、ドメイン コントローラーによって、パススルー認証のためにユーザーのドメイン内のドメイン コントローラーにクライアントの資格情報が送信されます。
   • そうでない場合は、次の手順に進みます。

2. 現在のドメインに、ユーザーのドメインとの推移的な信頼関係はありますか?

   • そうである場合は、認証要求を信頼パス内の次のドメインに渡します。 このドメイン コントローラーでは、ユーザーの資格情報をそのセキュリティ アカウント データベースと照合し、プロセスを繰り返します。
   • そうでない場合は、ログオン拒否メッセージをクライアントに送信します。

フォレストの信頼を介した認証要求の Kerberos ベースの処理

2 つのフォレストがフォレストの信頼によって接続されている場合、Kerberos V5 または NTLM プロトコルを使用して行われた認証要求は、両方のフォレスト内のリソースへのアクセスを提供するためにフォレスト間でルーティングできます。

フォレストの信頼が最初に確立されたときに、各フォレストではそのパートナー フォレスト内の信頼された名前空間をすべて収集し、信頼されたドメイン オブジェクトに情報を格納します。 信頼された名前空間には、ドメイン ツリー名、ユーザー プリンシパル名 (UPN) のサフィックス、サービス プリンシパル名 (SPN) のサフィックス、および他のフォレストで使用されるセキュリティ ID (SID) の名前空間が含まれます。 TDO オブジェクトはグローバル カタログにレプリケートされます。

認証プロトコルがフォレストの信頼パスに従うようにするには、その前に、リソース コンピューターのサービス プリンシパル名 (SPN) を他のフォレスト内の場所に解決する必要があります。 SPN は、次のいずれかの名前にすることができます。

• ホストの DNS 名。
• ドメインの DNS 名。
• サービス接続ポイント オブジェクトの識別名。

あるフォレストのワークステーションで、別のフォレストにあるリソース コンピューター上のデータへのアクセスを試みると、Kerberos 認証プロセスでは、リソース コンピューターの SPN に対するサービス チケットについて、ドメイン コントローラーに問い合わせます。 ドメイン コントローラーでは、グローバル カタログに対してクエリを実行し、SPN がドメイン コントローラーと同じフォレストにないと判断した場合、その親ドメインの参照をワークステーションに送り返します。 その時点で、ワークステーションでは、サービス チケットについて親ドメインに対してクエリを実行し、リソースが配置されているドメインに到達するまで参照チェーンをたどり続けます。

次の図と手順では、Windows を実行しているコンピューターで、別のフォレストにあるコンピューターのリソースへのアクセスを試みるときに使用される Kerberos 認証プロセスについて詳しく説明します。

1. User1 は、europe.tailspintoys.com ドメインからの資格情報を使用して、Workstation1 にサインインします。 その後、ユーザーは usa.wingtiptoys.com フォレストにある FileServer1 の共有リソースへのアクセスを試みます。

2. Workstation1 により、そのドメイン内のドメイン コントローラー (ChildDC1) 上の Kerberos KDC に問い合わせ、FileServer1 SPN のサービス チケットが要求されます。

3. ChildDC1 では、そのドメイン データベースで SPN が見つからず、グローバル カタログに対してクエリを実行し、tailspintoys.com フォレスト内のいずれかのドメインにこの SPN が含まれているかどうかを確認します。 グローバル カタログはそれ自身のフォレストに限定されるため、SPN は見つかりません。

   その後、グローバル カタログではそのデータベースで、そのフォレストで確立された任意のフォレストの信頼に関する情報があるかどうかを確認します。 見つかった場合、フォレストの信頼の信頼される側のドメイン オブジェクト (TDO) にリストされている名前サフィックスと、ターゲット SPN のサフィックスを比較して一致を見つけます。 一致が見つかると、グローバル カタログによって ChildDC1 にルーティング ヒントが返されます。

   ルーティング ヒントは、送信先フォレストに認証要求を直接送信するのに役立ちます。 ヒントは、ローカル ドメイン コントローラー、さらにはグローバル カタログなど、従来のすべての認証チャネルで SPN の検出に失敗した場合にのみ使用されます。

4. ChildDC1 によって、その親ドメインの参照が Workstation1 に送り返されます。

5. Workstation1 では、wingtiptoys.com フォレストのフォレスト ルート ドメインにあるドメイン コントローラー (ForestRootDC2) への参照について、ForestRootDC1 (その親ドメイン) のドメイン コントローラーに問い合わせます。

6. Workstation1 では、要求されたサービスに対するサービス チケットについて、wingtiptoys.com フォレスト内の ForestRootDC2 に問い合わせます。

7. ForestRootDC2 では、そのグローバル カタログに問い合わせて SPN を見つけます。グローバル カタログでは SPN の一致を見つけ、それを ForestRootDC2 に送り返します。

8. その後、ForestRootDC2 では、usa.wingtiptoys.com への参照を Workstation1 に送り返します。

9. Workstation1 では ChildDC2 の KDC に問い合わせ、User1 のチケットをネゴシエートして FileServer1 にアクセスできるようにします。

10. Workstation1 では、サービス チケットを受け取ったら、そのサービス チケットを FileServer1 に送信します。そこで、User1 のセキュリティ資格情報が読み取られ、それに応じてアクセス トークンが構築されます。

信頼されたドメイン オブジェクト

組織内の各ドメインまたはフォレストの信頼は、そのドメイン内のシステム コンテナーに格納されている、信頼されたドメイン オブジェクト (TDO) によって表されます。

TDO の内容

TDO に含まれる情報は、TDO がドメインの信頼とフォレストの信頼のどちらで作成されたかによって異なります。

ドメインの信頼が作成されている場合、DNS ドメイン名、ドメイン SID、信頼の種類、信頼の推移性、相互ドメイン名などの属性が TDO で表されます。 フォレストの信頼の TDO では、パートナー フォレストからの信頼されたすべての名前空間を識別するために、追加の属性が格納されます。 これらの属性には、ドメイン ツリー名、ユーザー プリンシパル名 (UPN) のサフィックス、サービス プリンシパル名 (SPN) のサフィックス、およびセキュリティ ID (SID) の名前空間が含まれます。

信頼は Active Directory に TDO として格納されるため、フォレスト内のすべてのドメインでは、フォレスト全体に適用されている信頼関係を認識します。 同様に、フォレストの信頼を介して 2 つ以上のフォレストが結合されている場合、各フォレスト内のフォレスト ルート ドメインでは、信頼されたフォレスト内のすべてのドメイン全体に適用されている信頼関係を認識します。

TDO パスワードの変更

信頼関係にある両方のドメインでは、Active Directory の TDO オブジェクトに格納されている、パスワードを共有します。 アカウントのメンテナンス プロセスの一環として、信頼する側のドメイン コントローラーでは、TDO に格納されているパスワードが 30 日ごとに変更されます。 双方向の信頼はすべて、実際には反対方向に進む 2 つの一方向の信頼であるため、プロセスは双方向の信頼に対して 2 回発生します。

信頼には、信頼する側と信頼される側があります。 信頼される側では、すべての書き込み可能なドメイン コントローラーをプロセスに使用できます。 信頼する側では、PDC エミュレーターによってパスワードの変更が行われます。

パスワードを変更するために、ドメイン コントローラーでは次のプロセスを完了します。

1. 信頼する側のドメイン内のプライマリ ドメイン コントローラー (PDC) エミュレーターでは、新しいパスワードを作成します。 信頼される側のドメイン内のドメイン コントローラーで、パスワードの変更が開始されることはありません。 常に信頼する側のドメイン PDC エミュレーターによって開始されます。

2. 信頼する側のドメインの PDC エミュレーターによって、TDO オブジェクトの OldPassword フィールドが現在の NewPassword フィールドに設定されます。

3. 信頼する側のドメインの PDC エミュレーターでは、TDO オブジェクトの NewPassword フィールドが現在のパスワードに設定されます。 以前のパスワードのコピーを保持しておくと、信頼される側のドメイン内のドメイン コントローラーで変更を受信できない場合、または新しい信頼パスワードを使用する要求が行われる前に変更がレプリケートされない場合に、古いパスワードに戻すことができます。

4. 信頼する側のドメイン内の PDC エミュレーターでは、信頼される側のドメイン内のドメイン コントローラーをリモートで呼び出し、信頼アカウントのパスワードを新しいパスワードに設定するように要求します。

5. 信頼される側のドメイン内のドメイン コントローラーでは、信頼パスワードを新しいパスワードに変更します。

6. 信頼の両側では、更新が、ドメイン内の他のドメイン コントローラーにレプリケートされます。 信頼する側のドメインでは、この変更によって、信頼される側のドメイン オブジェクトの緊急レプリケーションがトリガーされます。

これで、両方のドメイン コントローラーでパスワードが変更されました。 通常のレプリケーションでは、TDO オブジェクトがドメイン内の他のドメイン コントローラーに配布されます。 しかし、信頼する側のドメイン内のドメイン コントローラーでは、信頼される側のドメイン内のドメイン コントローラーが正常に更新されずに、パスワードが変更される可能性があります。 このシナリオは、パスワードの変更を処理するために必要な、セキュリティで保護されたチャネルを確立できなかったことが原因で発生する可能性があります。 また、信頼される側のドメイン内のドメイン コントローラーが、プロセス中のある時点で利用できない可能性があり、更新されたパスワードが受信されない可能性があります。

パスワードの変更が正常に伝達されない状況に対処するために、信頼する側のドメイン内のドメイン コントローラーでは、新しいパスワードを使用して (セキュリティで保護されたチャネルを設定して) 正常に認証されない限り、新しいパスワードが変更されることはありません。 このような動作になるのは、古いパスワードと新しいパスワードの両方が、信頼する側のドメインの TDO オブジェクトに保持されるためです。

パスワードを使用した認証が成功するまで、パスワードの変更は完了しません。 格納されている古いパスワードは、信頼される側のドメイン内のドメイン コントローラーで新しいパスワードが受信されるまで、セキュリティで保護されたチャネル経由で使用できます。したがって、サービスを中断することなく利用できます。

パスワードが無効であるために新しいパスワードを使用した認証に失敗した場合、信頼する側のドメイン コントローラーでは、古いパスワードを使用して認証が試行されます。 古いパスワードで正常に認証された場合、15 分以内にパスワード変更プロセスが再開されます。

信頼パスワードの更新は、30 日以内に信頼の両側のドメイン コントローラーにレプリケートする必要があります。 信頼のパスワードが 30 日後に変更され、ドメイン コントローラーに N-2 パスワードしかない場合、信頼する側から信頼を使用することはできず、信頼される側ではセキュリティで保護されたチャネルを作成することはできません。

信頼で使用されるネットワーク ポート

信頼はさまざまなネットワーク境界にまたがってデプロイされる必要があるため、1 つまたは複数のファイアウォールを超えなければならない場合があります。 このような場合は、ファイアウォールを介して信頼トラフィックをトンネリングするか、ファイアウォールの特定のポートを開いてトラフィックが通過できるようにすることができます。

フォレストの信頼に必要なポートの詳細については、Microsoft サポート記事の「Active Directory ドメインと信頼関係のためのファイアウォールを構成する方法」の「 「Windows Server 2008 とそれ以降のバージョン」セクションを参照してください。

サービスとツールのサポート

信頼と認証をサポートするために、いくつかの追加機能と管理ツールが使用されます。

Net Logon

Net Logon サービスでは、Windows ベースのコンピューターから DC へのセキュリティで保護されたチャネルが維持されます。 また、次の信頼関連のプロセスでも使用されます。

• 信頼の設定と管理 - Net Logon は、信頼パスワードの管理、信頼情報の収集、LSA プロセスと TDO とのやり取りによる信頼の検証に役立ちます。

  フォレストの信頼の場合、信頼情報にはフォレストの信頼情報 (FTInfo) レコードが含まれます。これには、信頼される側のフォレストによって管理が要求される名前空間セットが含まれ、各要求が信頼する側のフォレストによって信頼されているかどうかを示すフィールドで注釈が付けられます。

• 認証 – セキュリティで保護されたチャネルを介して、ドメイン コントローラーにユーザー資格情報を提供し、そのユーザーのドメイン SID とユーザー権利を返します。

• ドメイン コントローラーの場所 – ドメイン内または複数のドメインにわたる、ドメイン コントローラーを検索または特定するのに役立ちます。

• パススルー検証 – 他のドメインのユーザーの資格情報は、Net Logon によって処理されます。 信頼する側のドメインでユーザーの身元を検証する必要がある場合、Net Logon 経由で、検証のために信頼される側のドメインにユーザーの資格情報を渡します。

• 特権属性証明書 (PAC) の検証 – 認証に Kerberos プロトコルを使用しているサーバーでは、サービス チケットの PAC を検証する必要がある場合、セキュリティで保護されたチャネルを介して、検証のためにそのドメイン コントローラーに PAC が送信されます。

ローカル セキュリティ機関

ローカル セキュリティ機関 (LSA) は、システム上のローカル セキュリティのあらゆる側面に関する情報を保持する、保護されたサブシステムです。 ローカル セキュリティ ポリシーと総称される、LSA では名前と識別子の間の変換のためのさまざまなサービスが提供されます。

LSA セキュリティ サブシステムでは、オブジェクトへのアクセスの確認、ユーザー特権の確認、および監査メッセージの生成を行うために、カーネル モードとユーザー モードの両方でサービスが提供されます。 LSA には、信頼されているドメインまたは信頼されていないドメインのサービスによって提示される、すべてのセッション チケットの有効性を確認する役割があります。

管理ツール

管理者は、Active Directory ドメインと信頼関係、Netdom、Nltest を使用して、信頼を公開、作成、削除、または変更することができます。

• Active Directory ドメインと信頼関係 は、ドメインの信頼、ドメインとフォレストの機能レベル、およびユーザー プリンシパル名のサフィックスを管理するために使用される Microsoft 管理コンソール (MMC) です。
• Netdom および Nltest コマンドライン ツールを使用して、信頼の検索、表示、作成、および管理を行うことができます。 これらのツールでは、ドメイン コントローラー上の LSA 機関と直接通信を行います。

次のステップ

フォレストの信頼を使用するマネージド ドメインの作成を開始するには、Domain Services マネージド ドメインの作成と構成に関するページを参照してください。 その後、オンプレミス ドメインに対して出力方向のフォレストの信頼を作成できます。