別フォレスト同士を一方向フォレスト トラストでつなぐと、「相手にログオンできるのか」「相手のユーザー管理までできるのか」で混乱しがちです。本記事では信頼方向の考え方、ログオン可否の条件、管理を実現するための委任手順と安全な設計ポイントをまとめます。
前提：この記事での Domain A / Domain B の位置づけ
状況を整理するため、この記事では次のように呼び分けます。
- Domain A（アカウント側）：ユーザーが所属するフォレスト／ドメイン（ユーザーIDを持つ側）
- Domain B（リソース側）：端末・サーバー・ファイル共有などのリソースがあるフォレスト／ドメイン（アクセス先）
要件は「A のユーザーは B にアクセスできるが、B のユーザーは A にアクセスさせない」です。
結論：一方向フォレスト トラストでできること／できないこと
まず結論を、誤解が起きやすいポイントも含めて表で整理します。
| やりたいこと | 一方向フォレスト トラストだけで可能？ | ポイント |
|---|---|---|
| Domain A のユーザーが Domain B の端末にログオン（対話ログオン） | 可能（条件付き） | 信頼方向が正しいこと＋B側でログオン権限/ポリシーに阻まれないことが条件 |
| Domain A のユーザーが Domain B の共有フォルダ/サーバーへアクセス | 可能（権限設計次第） | トラストは“認証の経路”であり、ACL（アクセス許可）付与は別途必要 |
| Domain B → Domain A へのログオン/アクセスを禁止 | 可能 | 一方向にしておけば、B側ユーザーはA側で認証できない（ただしネットワーク到達性は別問題） |
| Domain A 側から Domain B のユーザー作成/変更/削除（管理） | 既定では不可 | 管理は権限（委任）が必要。B側で明示的に権限付与すれば可能 |
| Domain A のユーザーが「Domain B のユーザーとして」成り代わってログオン | 不可 | 当然ながらDomain B の資格情報（ID/パスワード等）が必要 |
最重要：信頼方向を取り違えると“逆”になる
一方向トラストは、言葉の取り違いで設計が反転しやすいです。覚え方はシンプルで、「X が Y を信頼する」＝「Y のユーザーが X のリソースに来られる」です。
A のユーザーを B に通したいなら、
Domain B が Domain A を信頼する（B trusts A）
という形にします。これにより、A のユーザーは B 側のサーバーや端末、共有などにアクセス可能になります。一方で、逆（A trusts B）にしてしまうと、B のユーザーが A のリソースへ行ける形になり、要件と逆になります。
| 信頼の表現 | アクセスできるのは誰？ | どこへ？ |
|---|---|---|
| B が A を信頼する（B trusts A） | A のユーザー | B のリソース（端末/共有/サーバー等） |
| A が B を信頼する（A trusts B） | B のユーザー | A のリソース |
Domain A ユーザーは Domain B にログオンできる？「可能（条件付き）」の中身
一方向フォレスト トラストが正しい向き（B trusts A）で張られていれば、Domain A のユーザーは Domain B 配下の端末・サーバーへ、A のアカウントのままログオンできる可能性があります。ただし、実際には次の“条件”が揃っている必要があります。
ログオンとアクセスの違いを分けて考える
「ログオンできるか？」は状況で意味が変わります。ここを分けるとトラブルシュートが一気に楽になります。
| 対象 | 例 | 主な判定要素 |
|---|---|---|
| 対話ログオン（端末に入る） | Domain B 参加 PC に A\user でサインイン | 信頼＋ログオン権限（ローカル/リモート）＋ポリシー制限 |
| ネットワークアクセス（リソース利用） | \\fileserverB\share に A\user でアクセス | 信頼＋共有/NTFS の許可（ACL）＋必要ならKerberos/NTLMの成立 |
| 管理ログオン/昇格 | RDPで管理用に入る、管理ツールを実行する | 信頼だけでは不足。管理権限の付与が必要 |
ログオン可否を左右するチェックリスト
「トラストは張ったのにログオンできない」場合、原因はトラスト自体ではなく周辺条件であることが多いです。現場で効くチェック項目をまとめます。
| チェック項目 | 確認ポイント | つまずきやすい例 |
|---|---|---|
| 信頼方向 | B trusts A になっているか | 向きを逆にしており、B→A が通ってしまう |
| 名前解決（DNS） | 双方のDCやクライアントが相手フォレストの名前を引けるか | 条件付きフォワーダ/スタブ ゾーン未設定で相手を解決できない |
| 時刻同期 | Kerberos は時刻ずれに弱い。数分以上ずれると失敗しやすい | 別NTP参照で大きくずれて認証不可 |
| 認証方式 | Kerberos が通る設計か（SPN、名前解決、通信） | Kerberos不成立でNTLMに落ち、制限や監査要件に引っかかる |
| ログオン権限（ローカル/リモート） | 「ローカル ログオンを許可」「RDPログオンを許可」等に含まれるか | GPOで「Deny log on locally / through RDS」に該当して失敗 |
| Selective Authentication の有無 | 選択的認証を有効にしている場合、Allowed to Authenticate が必要 | “許可設定”を忘れて認証段階で弾かれる |
| リソース側 ACL | 共有/NTFS/アプリ側の権限に A 側グループが入っているか | トラストはOKだが、許可がなくアクセス拒否 |
「Forest-wide authentication」と「Selective authentication」どちらを選ぶべき？
フォレスト トラストを作るとき、認証のスコープとして代表的に次の2択が出てきます（環境により表示文言は多少異なります）。結論から言うと、要件が“一方向で最小限に通したい”なら Selective authentication を第一候補にすると事故が減ります。
| 項目 | Forest-wide authentication | Selective authentication |
|---|---|---|
| 考え方 | 信頼したフォレストのユーザーは、B側のあらゆるコンピューターに“認証自体は”試みられる | 許可したコンピューター（またはサービス）にだけ認証を許す |
| 運用の手間 | 少ない | 増える（Allowed to Authenticate 設定が必要） |
| セキュリティの事故耐性 | 低め（許可の置き忘れで広く到達しやすい） | 高め（“許可しない限り到達しない”に寄せやすい） |
| おすすめ用途 | 統合に近い関係、運用を簡素化したい場合 | リソース フォレスト型（A→Bのみ）、委託先/子会社連携など |
Selective authentication を使う場合、Domain B 側で対象サーバー（またはコンピューター）に対して、Domain A のグループへ「Allowed to Authenticate」（認証を許可）を付与します。これがないと、A のユーザーはB側で認証段階で止まります。
“A のユーザーが B のユーザーとしてログオン”はできない
一方向トラストで実現できるのは、あくまで「A の資格情報を B が受け付ける」ことです。「A のユーザーが B のユーザーに成り代わる」ことはできません。
- A のユーザーが B の端末へログオンする → ログオンするIDは A のユーザー
- B のユーザーとしてログオンしたい → B のID/パスワード（またはそれに相当する認証要素）が必要
Domain A 側の DC から Domain B のユーザー管理はできる？「既定では不可、委任で可能」
ここが一番の勘違いポイントです。トラストは“認証・アクセスの経路”を作るだけで、相手ドメインの管理権限を自動で付与しません。よって、
- 既定の状態：Domain A のユーザー（や Domain A の管理者）であっても、Domain B のユーザー作成/削除/変更はできない
- 実現したい場合：Domain B 側で委任（Delegation）や権限付与を行い、Domain A のアカウント/グループに明示的な権限を付ける
「管理操作」が必要とする権限は、想像より細かい
“ユーザー管理”といっても範囲が広いので、よくある作業と必要な考え方を整理します。
| 作業 | 既定でA側から可能？ | B側で必要になること | おすすめのやり方 |
|---|---|---|---|
| ユーザー作成/削除 | 不可 | OUに対する「Create/Delete User objects」等の権限 | B側の特定OUに委任（ドメイン直下で広く与えない） |
| ユーザー属性変更（部署、電話番号、UPN等） | 不可 | 変更対象属性の書き込み権限 | 必要な属性だけ委任（最小権限） |
| パスワードリセット | 不可 | Reset password 権限、必要なら Change password 関連 | ヘルプデスク用ロールとして委任 |
| グループ管理（メンバー追加/削除） | 不可 | 対象グループの「Write members」権限 | “権限付与用のグループ”だけ操作できるように分離 |
| コンピューター アカウント作成/参加（ドメイン参加） | 不可 | OUへの委任、または「Add workstations to domain」相当 | 参加用OUを作り、そこだけ委任 |
| GPO作成/リンク/編集 | 不可 | Group Policy 管理権限（GPMC関連） | 要件が明確な場合のみ。原則はB側管理者で運用 |
委任で“できるようにする”基本手順（Domain B 側で実施）
もっとも安全で運用しやすいのは、Domain A の個人ユーザーへ直接権限を与えるのではなく、グループを経由して権限設計することです。
手順の全体像
- Domain A 側：アクセス/管理対象者をまとめるグループを用意（例：A_B_Operators）
- Domain B 側：委任用のグループを用意（例：B_Delegated_UserAdmins）
- Domain B 側：B_Delegated_UserAdmins に A_B_Operators（またはA側のユーザー/グループ）を追加
- Domain B 側：委任したいOUに対して Delegation of Control（委任のウィザード）で権限を付与
- 必要なら：Selective authentication の Allowed to Authenticate を対象サーバーへ付与
なぜ「B側グループ」→「A側グループの追加」がおすすめなのか
- B側の監査・棚卸しがやりやすい（「Bでは誰に委任したか」をBのADだけで追える）
- 担当者の入れ替えがA側だけで完結する（Aのグループメンバーを替えるだけ）
- 過剰権限を避けやすい（OU単位・タスク単位で委任を刻める）
このとき、B側には「Foreign Security Principal（外部セキュリティ プリンシパル）」としてA側のSIDが取り込まれる形になります。管理上は違和感なく扱えますが、委任やアクセス許可の主体は“グループ”に集約するのが重要です。
「A 側の DC から操作できるか？」の本質：場所ではなく“資格情報と権限”
質問でよく出るのが「Domain A 側の DC から Domain B を管理できるの？」という点ですが、結論は次のとおりです。
- 管理ツール（ADUC など）をどこで起動しても、最終的に効くのは接続先Bでの権限
- Domain A 側で ADUC を起動して Domain B に接続すること自体は可能
- ただし、B側で委任がない限り、作成/変更/削除などの管理操作はできない
よく使う運用パターン
| パターン | 概要 | メリット | 注意点 |
|---|---|---|---|
| RSAT/ADUC を管理端末から実行して B に接続 | 管理端末（AでもBでも可）から B のDCへ接続 | 日常運用に最適、端末をDCにしなくてよい | 通信（LDAP/ADWS等）と権限が必要 |
| runas /netonly でBの資格情報を使う | ログオンはAのまま、接続先だけB資格情報で動かす | 切り替えが楽、普段の作業環境を維持 | 操作ミスのリスク。委任設計があればB資格情報を減らせる |
| B側に管理ジャンプサーバーを用意 | B内で管理作業を閉じる（Aからは踏み台経由） | セキュリティ境界が明確、監査しやすい | 運用コストは上がる |
参考として、接続先だけ別資格情報でツールを開く例です。
runas /netonly /user:DomainB\SomeAdmin "mmc %SystemRoot%\system32\dsa.msc"Domain A アカウントで B の委任が設計できているなら、Bの強い管理者資格情報を日常的に使わずに済みます。
実務で効く：A→B だけ通す「安全な」設計ポイント
一方向トラストは便利ですが、雑に張ると「意図せず広く通る」「監査できない」「あとから引き締めにくい」状態になりがちです。A→Bのみを実現するなら、次の設計が効きます。
ポイント：トラストは“許可”ではない。許可はACLで作る
トラストを張った瞬間に「AのユーザーがBの共有を全部見られる」わけではありません。アクセス許可は次の2層で決まります。
- 認証できるか（トラスト、Selective authentication、ネットワーク、DNS、時刻）
- 許可されているか（共有権限、NTFS権限、アプリのRBAC、ローカルグループなど）
つまり、最小権限を作るコツは、「認証の入口」も「許可（ACL）」も絞ることです。
ポイント：グループ設計は “Aはアカウント、Bは権限” に寄せる
リソース フォレスト（B）に権限を集約する考え方は運用が安定します。おすすめの型は次のとおりです。
| 場所 | 役割 | 例 |
|---|---|---|
| Domain A | ユーザーをまとめる（誰が対象か） | A_GG_AppUsers、A_GG_Helpdesk など |
| Domain B | 権限を表す（何ができるか） | B_DLG_App_Read、B_DLG_App_Admin など |
| リソース（Bの共有/サーバー/アプリ） | ACLにB側グループを付与 | 共有/NTFS に B_DLG_App_Read を付与 |
この型にしておくと、「A側で誰を追加するか」と「B側で何の権限か」が分離され、棚卸し・監査・引き締めがやりやすくなります。
ポイント：B側の端末ポリシーを“確実に効かせる”にはループバックが有効
AのユーザーがBの端末にログオンすると、ユーザーはA所属です。すると、ユーザー向けGPOは基本的にA側のものが適用されます。B側の端末で「Bのルールを適用したい（デスクトップ制限、アプリ許可、プロキシ強制など）」場合は、対象OUのコンピューターGPOで「ユーザーのグループ ポリシー ループバック処理」を使うと設計しやすくなります。
- Bの端末に入るユーザーがA所属でも、Bの端末側OUのユーザーポリシーを適用できる
- VDI/Citrix/RDSなど、リソースフォレストでよく使う設計
ポイント：監査ログを“どこで見るか”を決めておく
クロスフォレストのアクセスは、問題が起きたときに「どのログを追うべきか」で迷います。最低限、次は運用前に決めておくと復旧が速くなります。
- 認証（Kerberos/NTLM）の失敗・成功を追う：Domain B 側のDC（KDCとして動く）
- 実際のログオン（4624など）やアクセス拒否：対象サーバー/端末（B側）
- 権限付与や委任の変更：AD（B側）の監査
構成例：要件「A → B は許可、B → A は不可」を満たす最小構成
実務で採用されやすい“最小構成”を、実装順に並べます。
実装ステップ（おすすめ順）
| ステップ | 実施内容 | 狙い |
|---|---|---|
| DNS設計 | 条件付きフォワーダ/スタブゾーン等で相互解決を成立 | トラスト/認証の土台 |
| 通信要件の整理 | DC間・クライアント↔DC間で必要ポートを許可 | “つながっているのに認証できない”を防ぐ |
| 一方向フォレスト トラスト作成 | B trusts A で作成 | A→Bのみの認証経路 |
| 認証スコープの選択 | 可能なら Selective authentication | 不要な到達範囲を削る |
| アクセス用グループ設計 | A側で対象者グループ、B側で権限グループ | 運用と監査の安定化 |
| リソースACL付与 | 共有/NTFS/アプリにB側グループを割り当て | 実際のアクセス制御 |
| 端末ログオン要件 | 必要ならローカルグループ/GPOでログオン権限を付与 | Aユーザーの対話ログオンを成立 |
| 管理が必要なら委任 | B側OUで Delegation of Control | “管理”はBの権限で実現 |
通信と名前解決の実務メモ（クロスフォレストで詰まりやすい場所）
環境差はありますが、相互に必要になりやすい代表例です。特に「トラスト作成時だけ通る/運用時に通らない」などの事故を避けるため、設計段階で関係者（NW/セキュリティ）と合意しておくのがおすすめです。
| 用途 | 代表的なプロトコル/ポート | 備考 |
|---|---|---|
| 名前解決 | DNS 53/TCP,UDP | 条件付きフォワーダを張るならDNS間通信が重要 |
| Kerberos 認証 | 88/TCP,UDP（環境によりUDP制限あり） | 時刻同期とセットで考える |
| LDAP/AD参照 | 389/TCP（LDAPSなら636/TCP） | ADUC等の基本 |
| グローバルカタログ参照 | 3268/TCP（LDAPSなら3269/TCP） | 検索や一部認証で使われる |
| SMB | 445/TCP | 共有アクセスや一部管理で関連 |
| RPC（管理/一部機能） | 135/TCP + 動的RPC | “管理をどこまでやるか”で必要範囲が変わる |
| ADWS（ADAC/PowerShell等） | 9389/TCP | PowerShellで跨るなら要確認 |
| 時刻同期 | NTP 123/UDP | Kerberosの成否に直結 |
トラブルシュートに効く確認コマンド（現場向け）
“信頼は張れているはず”という状態でも、DNS・経路・時刻・許可のどれかが欠けると失敗します。まずは「名前解決」「信頼の検証」「Kerberosの状況」を短いコマンドで切り分けるのがコツです。
名前解決
nslookup dc01.domainb.local
nslookup _ldap._tcp.dc._msdcs.domainb.local信頼の検証（クライアント/サーバー側）
nltest /domain_trusts
nltest /sc_verify:domainb.localKerberos チケット確認
klist「ログオンはできるが共有に入れない」場合は、共有とNTFSの両方でDomain A のグループ（またはそれを含むB側グループ）が許可されているかを確認します。
よくある誤解・FAQ（実際に揉めやすい論点）
“一方向なら絶対に安全”ではない？
一方向にすることで「BユーザーがAに認証できない」状態は作れます。しかし、A→Bを通す以上、Aが侵害された場合にBのリソースへ不正アクセスされるリスクは現実的に残ります。だからこそ、
- Selective authentication で“認証の入口”を絞る
- ACL（共有/NTFS/アプリ権限）を最小化する
- 委任はOU単位・タスク単位で刻む
という多層防御が重要になります。
Domain A のグループを Domain B の Domain Admins に入れたら管理できる？
理屈としては可能ですが、運用・監査・リスクの観点では最終手段です。Domain Admins は実質的にドメイン全域の強権限であり、“管理できる”と“してよい”は別です。多くのケースでは、必要なOUに必要なタスクだけを委任する方が、事故も監査負荷も小さくなります。
トラストを張ったのに、AユーザーがB端末にサインインできない
典型原因は次のいずれかです。
- B側で Selective authentication を有効にしているが、対象端末に Allowed to Authenticate を付けていない
- B側のGPOで「ローカル ログオンを拒否」「RDPログオンを拒否」等に該当している
- DNS解決が一部だけ失敗しており、認証先DC探索で詰まっている
- 時刻ずれでKerberosが失敗している
“B → A を完全にゼロ”にしたい（ネットワーク的にも遮断したい）
トラストは認証の話で、ネットワーク到達性の話ではありません。要件が「BからAへ一切通信させない」なら、ファイアウォールやルーティング設計での制御が別途必要です。ただし、トラスト運用上はDC間通信など最低限の要件が出るため、“どの通信が必要で、どこまで遮断するか”を要件として分解して設計すると破綻しにくくなります。
まとめ：ログオン（アクセス）は“経路”、ユーザー管理は“権限”
- 一方向フォレスト トラスト（B trusts A）が正しければ、AユーザーはBへログオン/アクセス可能（ただしDNS・時刻・ポリシー・ACLが条件）
- トラストだけでは管理権限は付与されないため、A側からBのユーザー作成/変更/削除は既定で不可
- B側でOU委任やグループ設計を行えば、A側アカウントに“必要な範囲だけ”管理を許可できる
- 要件が「A→Bのみ」なら、Selective authentication＋最小権限のACL/委任が実務的に強い
コメント