はじめに
こんにちは、クラウドネイティブのkaitoです。
今回は、Microsoft Entra Domain Services（以下 Entra DS）とオンプレミスの AD の間にフォレスト信頼を張る話です。ゴールは、Entra DS のユーザーでオンプレ側のサーバーにログオンすることまでです。
「オンプレの AD をやめて、ユーザーは Entra ID と Entra DS に寄せたい。でも、ファイル サーバーやリモート デスクトップのサーバーはしばらくオンプレの AD に残る」。こんな状況の方は多いのではないでしょうか。そうした状況で選択肢を探している方に、こんな方法もあると伝われば幸いです。
手順の全体は公式のチュートリアルを正とし、この記事では公式に書かれていない点や、私がつまずいた点に絞って書きます。公式のチュートリアルは双方向の信頼が前提なので、一方向にしたときの読み替えも補います。
前提
- Entra DS は Enterprise SKU（Entra DS の価格プラン）以上が必要です。フォレスト信頼は Enterprise 以上でしか作れません。
- Entra DS のユーザーが Kerberos や NTLM で認証するには、そのためのパスワード ハッシュが Entra DS に届いている必要があります。
- オンプレの AD から同期しているユーザー：Entra Connect のパスワード ハッシュ同期が必要です。AD FS でフェデレーションしている組織では無効のこともあるので、先に確認してください。
- クラウドで作ったユーザー：Entra ID でパスワードを変更（またはリセット）するまでハッシュが作られず、Entra DS で認証できません。
- Entra DS の仮想ネットワークとオンプレの間で、ドメイン コントローラー（DC）同士が常に通信できる必要があります。必要なポートは「Active Directory ドメインと信頼のファイアウォールを構成する方法」を確認してください。動的 RPC（既定では 49152〜65535）も含まれます。公式のチュートリアルでは、信頼を張るドメインのすべての DC でこれらのポートを開けるよう求めています。
構成と信頼の向き
検証環境は次のとおりです。
- Azure：Entra DS
- 別のクラウド上：オンプレ役の AD フォレストと、そこに参加したリモート デスクトップ サービス（RDS）のサーバー
- 2 つの間：サイト間 VPN
やりたいのは「Entra DS のユーザーが、オンプレ側のサーバーにログオンする」ことです。リソースを持つオンプレ側が、ユーザーを持つ Entra DS を信頼する形になります。
同じ信頼でも、見る側で名前が逆になります。信頼の方向は、次のように呼び分けます。
| どこで作るか | 選ぶ方向 |
|---|---|
| オンプレの AD（Active Directory ドメインと信頼関係） | 一方向の送信（Outgoing。オンプレが Entra DS を信頼する） |
| Entra DS（ポータルの「信頼」） | 一方向の受信（Incoming。Microsoft Learn の日本語版では「一方向着信」） |
ビルの入館に例えると、「よそのビルで発行された入館証でも、自社ビルの受付を通れるようにする」イメージです。受付を通すと決めるのは自社側なので、自社が相手を信頼します。ただし、どのフロアに入れるかは別に決めます（ここが後で出てくる「認可」の話です）。
一方向にしたのは、オンプレ側のアカウント（サーバーやサービス アカウントなど）が Entra DS に認証しに行ける経路を、わざわざ開けないためです。
全体の流れ
- オンプレの DNS に、Entra DS の条件付きフォワーダーを作る
- オンプレの AD で、信頼（一方向の送信）を作る
- Entra DS のポータルで、信頼（一方向の受信）を作る
nltestで信頼を確認する- ログオン先のサーバーに、ログオンの権限を付ける
- 必要なら、SIDHistory の利用を許可する
信頼を作るまでにつまずいたところ
手順 1：条件付きフォワーダーは「ドメイン」に保存する
オンプレの DNS に、Entra DS のドメイン名の条件付きフォワーダーを作ります。AD に保存するときの範囲は、ドメイン内のすべての DNS サーバーにします。公式のチュートリアルに、フォレストに保存すると失敗すると書かれています。
# オンプレの DC で実行
Add-DnsServerConditionalForwarderZone -Name "<Entra DS のドメイン名>" `
-MasterServers <Entra DSのDCのIP 1>, <Entra DSのDCのIP 2> `
-ReplicationScope "Domain"手順 2・3：信頼のパスワードは、Entra DS 側の条件を満たすものを先に決める
信頼のパスワードは両側で同じものを入れます。私の環境では、Entra DS 側のフォームで「8 文字以上、数字と大文字を 1 文字以上」を求められました。オンプレ側を先に作るので、この条件を知らずに作ると作り直しになります。条件は最低ラインなので、実際は長いランダムな文字列にしておきます。
オンプレ側のウィザードでは、認証の範囲を「フォレスト全体の認証」にしました。
手順 3：Entra DS 側には DNS サーバーを 2 つ以上指定する
Entra DS 側の信頼の作成フォームでは、オンプレ側の DNS サーバーを 2 つ以上指定します。同じ IP を 2 回入れることはできませんでした。検証環境は DNS が 1 台だけだったので、もう 1 台用意しました。
保存してもすぐには一覧に出ず、私の環境では 10〜20 分ほどかかりました。失敗したと思って作り直さないよう注意です。
手順 4：検証は nltest /sc_verify で
信頼ができたら、オンプレ側の DC で nltest を使って検証します。
nltest /sc_verify:<Entra DS のドメイン名>
# → Trust Verification Status = 0 0x0 NERR_Success なら OK
手順 5：信頼ができても、ログオンはできない
信頼ができて意気揚々と RDP したところ、次のメッセージで止まりました。
The connection was denied because the user account is not authorized for remote login
これは認証の失敗ではなく、認可の失敗です。信頼はユーザーが誰かを確かめる経路を作るだけです。そのサーバーにリモート ログオンしてよいかは、サーバー側のユーザー権利「リモート デスクトップ サービスを使ったログオンを許可」で決まります。この権利は既定で Remote Desktop Users グループに付いています。
そこで、Entra ID にログオン用のセキュリティ グループを作り、Entra DS に同期されたそのグループを Remote Desktop Users に追加しました。Domain Users を入れると Entra DS の全ユーザーにログオンを許すことになるので、専用のグループにしています。
# オンプレ側の RDS サーバーで実行（台数が多い場合はグループ ポリシーで配布）
net localgroup "Remote Desktop Users" "<Entra DS の NetBIOS 名>\<グループの sAMAccountName>" /add
グループに追加してからもう一度 RDP すると、今度は Entra DS のユーザーでログオンできました。whoami /fqdn の結果に OU=AADDC Users が出ています。Entra DS では、Entra ID から同期されたユーザーはこの OU に入るので、Entra DS のユーザーでログオンしていることがわかります。
GPO でこのユーザー権利を書き換えている環境では、GPO 側にもグループを追加します。
この方法だと、オンプレのサーバーへのログオン権を Entra ID のグループで管理することになります。グループのメンバーを変更できる人は絞っておきましょう。また、Entra DS への Kerberos／NTLM の認証には、Entra ID の条件付きアクセスや MFA は適用されません。
細かいところ
- 一方向の信頼でも、オンプレ側から Entra DS のグループ名は解決できました。逆に、オンプレ側のアカウントで Entra DS の中を照会・管理することはできません。Entra DS ではドメイン管理者の権限はもらえないので、AAD DC Administrators グループのメンバーで、Entra DS に参加させた管理用の VM から管理しました。
- Entra DS での sAMAccountName は、既定ではユーザーは mailNickname（メールのエイリアス）、グループは表示名が基になり、拡張 sAMAccountName 同期（プレビュー）の設定でも変わります。指定する前に、管理用の VM で
Get-ADUser／Get-ADGroupを使って実際の値を確認しておくと確実です。 - ログオン名は
<Entra DS の NetBIOS 名>\<sAMAccountName>の形式を基本にしました。公式ドキュメントでは、信頼越しの代替 UPN サフィックスはサポートされていません。また、オンプレと Entra DS で同じ UPN サフィックスを使う場合は、sAMAccountName でサインインする必要があるとされています。
手順 6：古い SID の ACL を効かせる（SIDHistory の利用を許可）
オンプレの AD から Entra Connect で同期したユーザーとグループには、Entra DS 側の sidHistory にオンプレでの SID が入ります。公式の属性マッピングでは、onPremisesSecurityIdentifier が sidHistory に対応しています。これがあれば、オンプレの SID で付けたファイルの ACL を付け直さずに使えるはず、です。ただし、クラウドで作ったユーザーには入りません。また、オンプレ側で既に持っていた sidHistory は引き継がれません。
フォレスト信頼の既定では SID フィルタリングが働き、sidHistory の SID はトークンから外されます。そこで、オンプレ側の DC で、この信頼について SIDHistory の利用を許可しました。この設定は、SID 履歴を使って Entra DS 側のユーザーがオンプレの資源にアクセスできるようにするものです（netdom のドキュメント）。そのぶん、信頼された側（Entra DS）から届く SID を受け入れる範囲は広がります。
# オンプレの DC で実行
netdom trust <オンプレのドメイン名> /d:<Entra DS のドメイン名> /EnableSIDHistory:yes
許可後にログオンして whoami /all で確認すると、オンプレの SID がトークンに載っていました。その SID で ACL を付けたフォルダーにも書き込めました。
許可する前に考えたいこと
これはセキュリティの境界を緩める設定です。netdom のドキュメントにも「信頼されたフォレストの管理者を信頼する場合にのみ有効にします」とあります。
この構成での「信頼されたフォレスト」は Entra DS です。そして sidHistory の元は、オンプレの AD から Entra Connect で同期される onPremisesSecurityIdentifier です。この属性は Entra ID 側では読み取り専用で、Entra ID の管理者が直接書き換えるものではありません。主な経路は、同期元のオンプレ AD オブジェクト、Entra Connect サーバーと同期用アカウント、そして Entra Connect の構成を変更できる管理者です。これらが侵害されると、Entra DS 経由でオンプレの資源に届く SID が増える可能性があります。許可する前に、次を決めておきたいところです。
- 同期の対象に、オンプレの特権グループが含まれていないか
- 許可せずに ACL を付け替える選択肢はないか
- 許可するなら、いつ戻すか（
/EnableSIDHistory:no）
さいごに
信頼を張り、ログオン権を付け、古い SID も効かせる。ここまでで「Entra DS のユーザーでオンプレ側のサーバーに入る」というゴールには届きました。
しかし、ログオンできた後にもう 1 つ落とし穴がありました。オンプレ側の別のファイル サーバーにアクセスすると、エラーもなく開けるのに、裏では Kerberos ではなく NTLM で認証されていたのです。この話は次回書きたいと思います。
ここまで読んでくださってありがとうございました！
※ 画面の表記や手順は今後変わる可能性があります。設定前に公式ドキュメントで最新の情報を確認してください。
