はじめに
こんにちは！クラウドネイティブの Kaito です。
前回の記事では、EDSとオンプレの AD の間に一方向のフォレスト信頼を作りました。そして、EDSのユーザーでオンプレ側のサーバーにログオンするまでを書きました。その最後に「オンプレ側のファイル サーバーにアクセスすると、Kerberos ではなく NTLM で認証されていた」と予告していました。今回はその続きです。
今回の話の結論ですが、クライアント側で「Kerberos フォレスト検索順序」（以下 KFSO）を設定後Kerberos に戻りました。
何が起きていたか
構成をおさらいします。
- Entra DS が「信頼される側」、オンプレの AD が「信頼する側」の一方向フォレスト信頼
- Entra DS のユーザーが、オンプレのドメインに参加した リモート デスクトップ サービスのサーバー（以下 RDS サーバー）にログオンする
- そこからオンプレのファイル サーバーの共有にアクセスする
検証は 2026 年 9〜10 月に行いました。環境は、Entra DS（Enterprise）、オンプレ役の AD（DC 1 台）、RDS サーバー 1 台、ファイル サーバーです。
net use で共有をつなぐと、エラーもなく成功します。画面上は何も問題がありません。ところが、ファイル サーバーのセキュリティ ログ（イベント 4624）を見ると、認証パッケージが NTLM、パッケージ名が NTLM V2 になっていました。4624 を記録するには、「ログオンの監査」の成功を有効にしておきます。
図にするとこうなります。
ここで SPN（サービス プリンシパル名）が出てきます。Kerberos でサービスを指す名前で、cifs/fs01.contoso.local のような形です。サービス名とホスト名の 2 つからなるものを 2 部構成と呼びます。末尾にさらにドメイン名が付く ldap/dc01.contoso.local/contoso.local のようなものは 3 部構成です（例のドメイン名は架空です）。
RDS サーバー上で、Entra DS のユーザーとしてチケットを直接取りにいくと、違いがはっきりしました。
# Entra DS のユーザーで RDS サーバーにログオンして実行
whoami # 被験者を確認してから測る
klist get cifs/<ファイル サーバーの FQDN> # 2 部構成の SPN
klist get ldap/<オンプレ DC の FQDN>/<オンプレのドメイン名> # 3 部構成の SPN3 部構成の SPN はチケットが取れました。一方、2 部構成の SPN（cifs/、host/、ldap/）は、どれも 0x6fb（0xc000018b）で失敗しました。コードの名前からは原因を読み取りにくいのですが、後で書くとおり KFSO のありなしで結果が切り替わったので、行き先が決まらない問題だと判断しました。SMB は Kerberos のチケットが取れないので、黙って NTLM にフォールバックしていたわけです。
なぜ最初に気づかなかったか
前回の検証でもファイル アクセスは試していました。ただ、アクセス先は RDS サーバー自身の共有でした。理由までは確かめていませんが、自分自身へのアクセスでは今回の問題が表に出ませんでした。アクセス先を別のサーバーに変えた途端、症状が出ました。
原因（推定）
フォレスト信頼では、DC の KDC が自分のフォレストで SPN を見つけられないと、グローバル カタログに照会します。グローバル カタログは、信頼されたドメイン オブジェクト（TDO）に登録された名前サフィックスと SPN を照合し、一致すれば紹介先を示すルーティング ヒントを DC に返します。3 部構成の SPN は末尾にドメイン名を持つので、行き先が SPN 自体からわかります。2 部構成の SPN はドメインの要素を持たないので、ホスト名と名前サフィックスの照合がうまくいかないと、行き先が決まりません。
今回の構成では、ユーザーのアカウントは Entra DS にあるので、最初にチケットを求められるのは Entra DS の KDC です。私の仮説は、Entra DS 側の信頼の情報にオンプレのフォレストの名前サフィックスが登録されておらず、2 部構成の SPN の行き先が決まらなかった、というものです。3 部構成なら成功し、KFSO で解消したことと矛盾しません。ただ、Entra DS の DC の中は直接見られないので、確かめてはいません。ここは推定どまりです。
KFSO で Kerberos に戻す
KFSO は、2 部構成の SPN を解決できなかったときに、指定したフォレストを順番に探しにいくための設定です。Microsoft Learn の「ポリシー CSP - Kerberos」によると、一致すれば適切なドメインへの紹介チケットを要求します。また、無効や未構成のままだと NTLM が使われる可能性がある、とも書かれています。まさに今回の症状です。
KDC 側にも同じ名前のポリシーがあります。しかし、Entra DS では Domain Admins の権限がなく、DC 側の設定に手を入れられません。そこで、クライアントである RDS サーバー側に設定しました。
- 場所：コンピューターの構成 → 管理用テンプレート → システム → Kerberos → 「フォレストの検索順序を使用する」
- 設定：有効にして、検索するフォレストにオンプレのフォレスト名を指定する
設定は、次のレジストリに UseForestSearch などの値として入ります。反映されたかはここを見ると確実です。
HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters
gpupdate /force のあと、RDS サーバーを再起動して、同じユーザーで測り直しました。再起動が必須かどうかは確かめておらず、念のため再起動しています。結果は次のとおりです。
klist get cifs/…とklist get host/…でチケットが取れた。klistの「KDC Called」はオンプレの DC で、オンプレのドメイン向けの紹介チケット（krbtgt/…）は Entra DS が発行していた- ファイル サーバー側の 4624 は、ログオン タイプ 3、認証パッケージ Kerberos、パッケージ名は「-」になった
念のため、ポリシーを「未構成」に戻して再起動すると、0x6fb が再発し、4624 も NTLM V2 に戻りました。設定のありなしで結果が切り替わったので、効いているのは KFSO だと判断しました。
つまずいたところ
「つながる」ことは確認にならない
NTLM にフォールバックしても、アクセスは成功します。そのため、利用者からの問い合わせでは見つかりません。確かめるには、klist でチケットを見るか、アクセス先の 4624 で認証パッケージを見ます。
なぜ放っておかないのか
NTLM は、Microsoft Learn の「Windows クライアントの非推奨機能」で、すべてのバージョンが非推奨とされています。Windows Server の次のリリースと Windows の次の年次リリースでも引き続き動作するとされているので、すぐに止まるわけではありません。ただ、同じページで、NTLMv1 は Windows 11 バージョン 24H2 と Windows Server 2025 以降で削除されたとされています。また、Windows 11 バージョン 24H2 と Windows Server 2025 以降では、SMB クライアント側で NTLM の接続をブロックする設定も用意されています。
接続元のサーバーやドメインで、いずれ NTLM を絞ろうとしたとき、Entra DS のユーザーだけ一斉にアクセスできなくなる。そんな事態は避けたいところです。今のうちに Kerberos に寄せておくのが安全だと考えています。
さいごに
「つながるけど NTLM」は、エラーが出ないぶん見つけにくい落とし穴でした。別のサーバーで試す、4624 を見る。この 2 つを試験項目に入れておくだけで、見落としを防げます。
まだ勉強中の身ですが、同じ構成を検討している方の参考になれば嬉しいです。ここまで読んでくださってありがとうございました！
※ 画面の表記や手順は今後変わる可能性があります。設定前に公式ドキュメントで最新の情報を確認してください。
