Active Directory のフォレストの信頼関係のしくみ (プレビュー)
Active Directory Domain Services (AD DS) は、ドメインとフォレストの信頼関係を通じて、複数のドメインまたはフォレスト間のセキュリティを提供します。 認証が信頼を超えて行われる前に、Windows はまず、ユーザー、コンピューター、またはサービスによって要求されているドメインが、要求先アカウントのドメインと信頼関係を持っているかどうかを確認する必要があります。
この信頼関係を確認するために、Windows セキュリティ システムは、要求を受信するサーバーのドメイン コントローラー (DC) と要求先アカウントのドメイン内の DC の間の信頼パスを計算します。
AD DS と Windows 分散セキュリティ モデルによって提供されるアクセス制御メカニズムは、ドメインとフォレストの信頼を操作するための環境を提供します。 これらの信頼を適切に機能させるには、すべてのリソースまたはコンピューターに、その場所にあるドメイン内の DC への直接信頼パスが必要です。
Net Logon サービスは、信頼されたドメイン機関への認証済みのリモート プロシージャ コール (RPC) 接続を使用して信頼パスを実装します。 セキュリティで保護されたチャネルは、ドメイン間の信頼関係を通じて他の 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 つのドメインの外部で拡張できるかどうかを決定します。
- 推移的な信頼を使用して、他のドメインとの信頼関係を拡張できます。
- 非推移的な信頼を使用して、他のドメインとの信頼関係を拒否できます。
フォレストに新しいドメインを作成するたびに、新しいドメインとその親ドメインの間に双方向の推移的な信頼関係が自動的に作成されます。 子ドメインが新しいドメインに追加された場合、信頼パスはドメイン階層を通過し、新しいドメインとその親ドメインの間で作成された初期信頼パスを拡張します。 推移的な信頼関係は、形成されたドメイン ツリーを介して上方向に流れ、ドメイン ツリー内のすべてのドメイン間に推移的な信頼を作成します。
認証要求はこれらの信頼パスに従うので、フォレスト内の任意のドメインのアカウントは、フォレスト内の他のドメインによって認証できます。 シングル サインイン プロセスでは、適切なアクセス許可を持つアカウントは、フォレスト内の任意のドメイン内のリソースにアクセスできます。
フォレストの信頼
フォレストの信頼は、セグメント化された AD DS インフラストラクチャを管理し、複数のフォレストにまたがるリソースやその他のオブジェクトへのアクセスをサポートするのに役立ちます。 フォレストの信頼は、サービス プロバイダー、合併または買収を受けている企業、共同ビジネス エクストラネット、管理自律性のソリューションを求めている企業に役立ちます。
フォレストの信頼を使用すると、2 つの異なるフォレストをリンクして、一方向または双方向の推移的な信頼関係を形成できます。 フォレストの信頼により、管理者は 2 つの AD DS フォレストを 1 つの信頼関係に接続して、フォレスト全体でシームレスな認証と承認のエクスペリエンスを提供できます。
フォレストの信頼は、あるフォレストのフォレスト ルート ドメインと別のフォレストのフォレスト ルート ドメインの間でのみ作成できます。 フォレストの信頼は 2 つのフォレスト間でのみ作成でき、3 番目のフォレストに暗黙的に拡張することはできません。 この動作は、フォレスト Forest 1 と Forest 2の間にフォレスト信頼が作成され、さらに Forest 2 と Forest 3の間に別のフォレスト信頼が作成された場合でも、Forest 1 は Forest 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 にあるリソースにアクセスできません。
重要
Microsoft Entra Domain Services では、フォレスト トラストの多方向をサポートしています。
フォレストの信頼の要件
フォレスト トラストを作成する前に、適切なドメイン ネーム システム (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 セカンダリ ゾーンを各 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 プロトコルは、MIT Kerberos 領域などの Windows ブランド以外のオペレーティング システム Kerberos 領域でのみクロス領域認証を実行し、Net Logon サービスと対話する必要はありません。
クライアントが認証に Kerberos V5 を使用する場合は、アカウント ドメインのドメイン コントローラーからターゲット ドメイン内のサーバーにチケットを要求します。 Kerberos KDC は、クライアントとサーバーの間の信頼された仲介者として機能し、2 人が相互に認証できるようにするセッション キーを提供します。 ターゲット ドメインが現在のドメインと異なる場合、KDC は論理プロセスに従って、認証要求を参照できるかどうかを判断します。
現在のドメインは、要求されているサーバーのドメインによって直接信頼されていますか?
- "はい" の場合は、要求されたドメインへの紹介状をクライアントに送信します。
- いいえの場合は、次の手順に進みます。
現在のドメインと信頼パス上の次のドメインの間に推移的な信頼関係がありますか?
- "はい" の場合は、クライアントに信頼パス上の次のドメインに紹介を送信します。
- いいえの場合は、クライアントにサインイン拒否メッセージを送信します。
NTLM 紹介処理
NTLM 認証プロトコルは、クライアント認証と承認情報のドメイン コントローラー上の Net Logon サービスに依存します。 このプロトコルは、Kerberos 認証を使用しないクライアントを認証します。 NTLM では、信頼を使用してドメイン間で認証要求を渡します。
クライアントが認証に NTLM を使用する場合、認証の最初の要求はクライアントからターゲット ドメイン内のリソース サーバーに直接送信されます。 このサーバーは、クライアントが応答するチャレンジを作成します。 その後、サーバーはユーザーの応答をコンピューター アカウント ドメインのドメイン コントローラーに送信します。 このドメイン コントローラーは、セキュリティ アカウント データベースに対してユーザー アカウントをチェックします。
アカウントがデータベースに存在しない場合、ドメイン コントローラーは、次のロジックを使用して、パススルー認証を実行するか、要求を転送するか、要求を拒否するかを決定します。
現在のドメインは、ユーザーのドメインと直接の信頼関係を持っていますか?
- "はい" の場合、ドメイン コントローラーは、パススルー認証のために、クライアントの資格情報をユーザーのドメイン内のドメイン コントローラーに送信します。
- いいえの場合は、次の手順に進みます。
現在のドメインは、ユーザーのドメインと推移的な信頼関係を持っていますか?
- "はい" の場合は、信頼パス内の次のドメインに認証要求を渡します。 このドメイン コントローラーは、ユーザーの資格情報を独自のセキュリティ アカウント データベースに対して確認することで、プロセスを繰り返します。
- いいえの場合は、ログオン拒否メッセージをクライアントに送信します。
フォレストの信頼を介した認証要求の Kerberos ベースの処理
フォレスト信頼によって 2 つのフォレストが接続されている場合、Kerberos V5 または NTLM プロトコルを使用して行われた認証要求をフォレスト間でルーティングして、両方のフォレスト内のリソースへのアクセスを提供できます。
フォレストの信頼が最初に確立されると、各フォレストはパートナー フォレスト内のすべての信頼された名前空間を収集し、その情報を 信頼されたドメイン オブジェクトに格納します。 信頼された名前空間には、ドメイン ツリー名、ユーザー プリンシパル名 (UPN) サフィックス、サービス プリンシパル名 (SPN) サフィックス、および他のフォレストで使用されるセキュリティ ID (SID) 名前空間が含まれます。 TDO オブジェクトはグローバル カタログにレプリケートされます。
手記
信頼の代替 UPN サフィックスはサポートされていません。 オンプレミス ドメインで Domain Services と同じ UPN サフィックスが使用されている場合、サインインには sAMAccountName 使用する必要があります。
認証プロトコルがフォレストの信頼パスに従う前に、リソース コンピューターのサービス プリンシパル名 (SPN) を他のフォレスト内の場所に解決する必要があります。 SPN には、次のいずれかの名前を指定できます。
- ホストの DNS 名。
- ドメインの DNS 名。
- サービス接続ポイント オブジェクトの識別名。
あるフォレスト内のワークステーションが別のフォレスト内のリソース コンピューター上のデータにアクセスしようとすると、Kerberos 認証プロセスは、リソース コンピューターの SPN へのサービス チケットのドメイン コントローラーに接続します。 ドメイン コントローラーがグローバル カタログに対してクエリを実行し、SPN がドメイン コントローラーと同じフォレスト内にないことを確認すると、ドメイン コントローラーは親ドメインの紹介をワークステーションに送り返します。 その時点で、ワークステーションは親ドメインにサービス チケットのクエリを実行し、リソースが配置されているドメインに到達するまで紹介チェーンのフォローを続けます。
次の図と手順では、Windows を実行しているコンピューターが別のフォレストにあるコンピューターからリソースにアクセスしようとしたときに使用される Kerberos 認証プロセスの詳細な説明を示します。
User1 は、europe.tailspintoys.com ドメインの資格情報を使用して、Workstation1 にサインインします。 その後、ユーザーは、usa.wingtiptoys.com フォレストにある FileServer1 上の共有リソースにアクセスしようとします。
Workstation1 は、ドメイン内のドメイン コントローラーである ChildDC1上の Kerberos KDC に接続し、FileServer1 SPN に対するサービス チケットを要求します。
ChildDC1 では、ドメイン データベースに SPN が見つからないので、グローバル カタログに対してクエリを実行して、tailspintoys.com フォレスト内のドメインにこの SPN が含まれているかどうかを確認します。 グローバル カタログは独自のフォレストに制限されているため、SPN は見つかりません。
その後、グローバルカタログは、そのフォレストの中で確立されているフォレストトラストに関する情報をデータベースで確認します。 見つかった場合は、フォレスト信頼信頼ドメイン オブジェクト (TDO) にリストされている名前サフィックスとターゲット SPN のサフィックスを比較して一致を見つけます。 一致が見つかると、グローバル カタログは、ChildDC1にルーティング ヒントを返します。
ルーティング ヒントは、認証要求を宛先フォレストに直接送信するのに役立ちます。 ヒントは、ローカル ドメイン コントローラーやグローバル カタログなど、従来のすべての認証チャネルが SPN を見つけられなかった場合にのみ使用されます。
ChildDC1 は、親ドメインの紹介を Workstation1に送り返します。
Workstation1 では、wingtiptoys.com フォレストのフォレスト ルート ドメインにあるドメイン コントローラー (ForestRootDC2) への参照について、ForestRootDC1 (その親ドメイン) のドメイン コントローラーに問い合わせます。
Workstation1 では、要求されたサービスに対するサービス チケットについて、wingtiptoys.com フォレスト内の ForestRootDC2 に問い合わせます。
ForestRootDC2、グローバル カタログに接続して SPN を検索し、グローバル カタログが SPN の一致を見つけて、ForestRootDC2に送り返します。
その後、ForestRootDC2 では、usa.wingtiptoys.com への参照を Workstation1 に送り返します。
Workstation1 では ChildDC2 の KDC に問い合わせ、User1 のチケットをネゴシエートして FileServer1 にアクセスできるようにします。
Workstation1 がサービス チケットを取得すると、サービス チケットが FileServer1に送信されます。これにより、User1 のセキュリティ資格情報読み取られ、それに応じてアクセス トークンが構築されます。
信頼されたドメイン オブジェクト
ドメイン内の System コンテナーに格納されている信頼されたドメイン オブジェクト (TDO) は、組織内の各ドメインまたはフォレストの信頼を表します。
TDO の内容
TDO に含まれる情報は、TDO がドメイン信頼によって作成されたか、フォレスト信頼によって作成されたかによって異なります。
ドメイン信頼が作成されると、DNS ドメイン名、ドメイン SID、信頼の種類、信頼推移性、逆数ドメイン名などの属性が TDO で表されます。 フォレスト信頼 TDO には、パートナー フォレストからのすべての信頼された名前空間を識別するための追加の属性が格納されます。 これらの属性には、ドメイン ツリー名、ユーザー プリンシパル名 (UPN) サフィックス、サービス プリンシパル名 (SPN) サフィックス、およびセキュリティ ID (SID) 名前空間が含まれます。
信頼は TTO として Active Directory に格納されるため、フォレスト内のすべてのドメインには、フォレスト全体に存在する信頼関係に関する知識があります。 同様に、フォレストの信頼を通じて複数のフォレストが結合されている場合、各フォレストのフォレスト ルート ドメインには、信頼されたフォレスト内のすべてのドメイン全体に存在する信頼関係に関する知識があります。
TDO パスワードの変更
信頼関係の両方のドメインは、Active Directory の TDO オブジェクトに格納されるパスワードを共有します。 アカウントのメンテナンス プロセスの一環として、信頼するドメイン コントローラーによって TDO に格納されているパスワードが 30 日ごとに変更されます。 双方向の信頼はすべて、実際には反対方向に向かう 2 つの一方向の信頼であるため、このプロセスは双方向の信頼に対して 2 回発生します。
信頼には、信頼する側と信頼される側があります。 信頼できる側では、書き込み可能なドメイン コントローラーをプロセスに使用できます。 信頼側では、PDC エミュレーターがパスワードの変更を実行します。
パスワードを変更するために、ドメイン コントローラーは次のプロセスを完了します。
信頼するドメインのプライマリ ドメイン コントローラー (PDC) エミュレーターは、新しいパスワードを作成します。 信頼されたドメイン内のドメイン コントローラーは、パスワードの変更を開始しません。 これは常に、信頼するドメイン PDC エミュレーターによって開始されます。
信頼ドメインの PDC エミュレーターは、TDO オブジェクトの OldPassword フィールドを現在の NewPassword フィールドに設定します。
信頼するドメインの PDC エミュレーターは、TDO オブジェクトの NewPassword フィールドを新しいパスワードに設定します。 以前のパスワードのコピーを保持すると、信頼されたドメイン内のドメイン コントローラーが変更を受信できなかった場合、または新しい信頼パスワードを使用する要求が行われる前に変更がレプリケートされない場合に、古いパスワードに戻す可能性があります。
信頼するドメインの PDC エミュレーターは、信頼されたドメイン内のドメイン コントローラーにリモート呼び出しを行い、信頼アカウントのパスワードを新しいパスワードに設定するように要求します。
信頼されたドメインのドメイン コントローラーは、信頼パスワードを新しいパスワードに変更します。
信頼の両側で、更新プログラムはドメイン内の他のドメイン コントローラーにレプリケートされます。 信頼するドメインでは、変更によって、信頼されたドメイン オブジェクトの緊急のレプリケーションがトリガーされます。
両方のドメイン コントローラーでパスワードが変更されました。 通常のレプリケーションでは、TDO オブジェクトがドメイン内の他のドメイン コントローラーに分散されます。 ただし、信頼するドメイン内のドメイン コントローラーが、信頼されたドメイン内のドメイン コントローラーを正常に更新せずにパスワードを変更する可能性があります。 このシナリオは、パスワードの変更を処理するために必要なセキュリティで保護されたチャネルを確立できなかったために発生する可能性があります。 また、プロセス中のある時点で、信頼されたドメイン内のドメイン コントローラーが使用できず、更新されたパスワードを受け取らない可能性もあります。
パスワードの変更が正常に通信されない状況に対処するために、信頼するドメインのドメイン コントローラーは、新しいパスワードを使用して正常に認証 (セキュリティで保護されたチャネルを設定) しない限り、新しいパスワードを変更しません。 この動作により、古いパスワードと新しいパスワードの両方が信頼ドメインの TDO オブジェクトに保持されます。
パスワードを使用した認証が成功するまで、パスワードの変更は完了しません。 古い保存されたパスワードは、信頼されたドメイン内のドメイン コントローラーが新しいパスワードを受け取るまで、セキュリティで保護されたチャネルで使用できるため、サービスが中断されません。
パスワードが無効であるために新しいパスワードを使用した認証が失敗した場合、信頼するドメイン コントローラーは古いパスワードを使用して認証を試みます。 古いパスワードで正常に認証されると、15 分以内にパスワード変更プロセスが再開されます。
信頼パスワードの更新は、信頼の両側のドメイン コントローラーに 30 日以内にレプリケートする必要があります。 信頼パスワードが 30 日後に変更され、ドメイン コントローラーに N-2 パスワードしかない場合は、信頼側からの信頼を使用できないため、信頼された側にセキュリティで保護されたチャネルを作成できません。
信頼によって使用されるネットワーク ポート
信頼はさまざまなネットワーク境界に展開する必要があるため、1 つ以上のファイアウォールにまたがる必要がある場合があります。 この場合は、ファイアウォール経由で信頼トラフィックをトンネリングするか、ファイアウォール内の特定のポートを開いてトラフィックの通過を許可することができます。
重要
Active Directory Domain Services では、Active Directory RPC トラフィックを特定のポートに制限することはできません。
フォレストの信頼に必要なポートの詳細については、Microsoft サポートの記事の「Active Directory ドメインと信頼のファイアウォールを構成する方法」の「Windows Server 2008 以降のバージョン」セクションを参照してください。
サポート サービスとツール
信頼と認証をサポートするために、いくつかの追加機能と管理ツールが使用されます。
Net Logon
Net Logon サービスは、Windows ベースのコンピューターから DC へのセキュリティで保護されたチャネルを維持します。 また、次の信頼関連プロセスでも使用されます。
信頼のセットアップと管理 - Net Logon は、LSA プロセスと TDO とやり取りすることで、信頼パスワードの維持、信頼情報の収集、信頼の検証に役立ちます。
フォレストの信頼の場合、信頼情報にはフォレスト信頼情報 (FTInfo) レコードが含まれます。このレコードには、信頼されたフォレストが管理するように要求する名前空間のセットが含まれ、各要求が信頼するフォレストによって信頼されているかどうかを示すフィールドで注釈が付けられます。
認証 – セキュリティで保護されたチャネル経由でユーザー資格情報をドメイン コントローラーに提供し、ユーザーのドメイン SID とユーザー権限を返します。
ドメイン コントローラーの場所 – ドメイン内またはドメイン間でドメイン コントローラーを検索または検索するのに役立ちます。
パススルー検証 – 他のドメインのユーザーの資格情報は、Net Logon によって処理されます。 信頼するドメインがユーザーの ID を確認する必要がある場合、ユーザーの資格情報は Net Logon 経由で検証のために信頼されたドメインに渡されます。
特権属性証明書 (PAC) 検証 – 認証に Kerberos プロトコルを使用するサーバーがサービス チケット内の PAC を検証する必要がある場合、セキュリティで保護されたチャネル全体で PAC をドメイン コントローラーに送信して検証します。
ローカル セキュリティ機関
ローカル セキュリティ機関 (LSA) は、システム上のローカル セキュリティのすべての側面に関する情報を保持する保護されたサブシステムです。 まとめてローカル セキュリティ ポリシーと呼ばれる LSA は、名前と識別子間の変換のためのさまざまなサービスを提供します。
LSA セキュリティ サブシステムは、オブジェクトへのアクセスの検証、ユーザー特権の確認、監査メッセージの生成を行うために、カーネル モードとユーザー モードの両方でサービスを提供します。 LSA は、信頼されたドメインまたは信頼されていないドメイン内のサービスによって提示されるすべてのセッション チケットの有効性を確認する役割を担います。
管理ツール
管理者は、Active Directory ドメインと信頼、Netdom、および Nltest を使用して、信頼を公開、作成、削除、または変更できます。
- Active Directory ドメインと信頼関係 は、ドメイン信頼、ドメインおよびフォレストの機能レベル、ユーザープリンシパル名のサフィックスを管理するために使用される Microsoft 管理コンソール (MMC) です。
- Netdom と Nltest コマンド ライン ツールを使用して、信頼を検索、表示、作成、および管理できます。 これらのツールは、ドメイン コントローラー上の LSA 機関と直接通信します。
次の手順
フォレストの信頼を持つマネージド ドメインの作成を開始するには、「Domain Services マネージド ドメインの作成と構成」を参照してください。 その後、オンプレミス ドメインに対して出力方向のフォレストの信頼を作成できます。