Entra Private Accessが、社内ファイルサーバにアクセスする際に、オンプレADの認証を回避する方法
「https://ignite.microsoft.com/en-US/sessions/BRK326?source=sessions」
Ignte 2024動画の１８分ごろ～の内容となります。
オンプレADに参加していない（Entraのみに参加している）windows端末が、Entra Private Accessを利用して、社内のファイルサーバにアクセスする際に、Entraのみ認証が求められ、社内ファイルサーバの認証(オンプレADの認証）は求められずにアクセスするデモがありますが、どのように実現しているのでしょうか（どのようにSSOを実現しているのでしょうか）
公式ドキュメント
上記構成を行うことにより、プライベート DNS という仕組みにてオンプレミス Active Directory と通信を行うことができるようになり、これにより Microsoft Entra 参加デバイスにおいても Active Directory から Kerberos チケットを取得することができるようになります。
通信フローの詳細については、上記資料の「Kerberos SSO (シングル サインオン) を使用して SMB (サーバー メッセージ ブロック)ファイル共有にアクセスする方法」のセクションが参考になります。
補足
「ADDS⇔デバイス」間の通信では、NATが発生している
デバイスは Entra 上のサービスに対して要求を投げ、Entra 上のサービスが Microsoft Entra Private Network Connector に対して要求を投げ、最終的に Microsoft Entra Private Network Connector がオンプレミス上のリソースに対して要求を投げるようなイメージとなります。
クライアント環境 <——> Microsoft Entra Private Access <——> Connector <——> オンプレミス リソース
この通信の過程で、NATが発生しています。
「ADDS⇔デバイス」間では、Kerberosプロトコルが使われており、NAT越えできないはずではないか
Active Directory における、NAT 環境のサポートについて
オンプレミス Active Directory は NAT 環境下で利用されることを想定していません。
NAT を経由したオンプレミス Active Directory 構成について、MSは推奨しておらず、NAT を利用した環境で正常に動作するかどうかはサポートされていません。
■NAT 経由の Active Directory のサポート境界の説明
NAT 環境での Kerberos 認証について
Kerberos ではクライアントの IP アドレスを確認するヘッダーが存在し、送信元の確認に使用する構成があります。
このような環境の場合に NAT デバイスを介すると Kerberos 認証に失敗することが想定されます。
しかしながら、Windows 環境で使用される Kerberos 認証の場合、既定ではクライアント送信元 IP アドレスの検証を実施していません。
このため、理論上は NAT 環境下でも Kerberos 認証は可能となります。
既定の状態から変更しクライアント送信元 IP アドレスの検証を実施する構成としている場合には上記のとおり影響が生じる可能性があります。
■Windows の Kerberos プロトコル レジストリ エントリと KDC 構成キー
Kerberos プロトコルとキー配布センター (KDC) に関するレジストリ エントリ – Windows Server | Microsoft Learn
Windows OS では、以前のバージョンを含めて、クライアント送信元 IP アドレスの検証を実施しておりません。
Microsoft Entra Private Access 利用時の Kerberos 認証
１つ上の項で説明した理由により、Microsoft Entra Private Access においても NAT 環境下でのKerberos 認証が可能となります。（ただし、「Active Directory における、NAT 環境のサポートについて」で記載している通り、MSとしては推奨していないとのことでした（MSサポート曰く）。ただ、MSサポートの方も少し自信がなさそうだったので、本当に「Entra Private Access × Kerberos」が非推奨かは、深堀する余地はありそうです。そもそも、MSとして非推奨のものを Ignite2024 で発表するということは通常しないと思いますし）
なお、既定の状態から変更しクライアント送信元 IP アドレスの検証を実施する構成でも検証してみましたが、検証環境においては即座に問題が発生することはありませんでした。
環境によっては、影響が生じる可能性があるので、対象環境において設定が変更されていないか念のため確認した方がよいです。
（参考） Microsoft Entra Private Network Connector 側の動作について
Kerberos ではサービスチケット内に、クライアントの IP アドレスが含まれています。そのため、ADDSと最後に通信する部分（Entra Private Network Connector）で、そのＩＰアドレス（IPヘッダのIPアドレス情報ではなく、Kerberosサービスチケットに含まれる情報）が、Entra Private Network Connector の IPアドレスに書き換えられている可能性があるかもと思いました（本件調査する過程にて、そのような疑問が生じました）
確認結果ですが、Microsoft Entra Private Network Connector 側で Kerberos サービス チケット内の情報 (IP アドレス) の更新が行われているか、といった情報は確認できませんでした。
Microsoft Entra Private Access の機能は、もともと Microsoft Entra ID に実装されていた Microsoft Entra アプリケーション プロキシの仕組みを拡張しているイメージとなります。もともとの機能である Microsoft Entra アプリケーション プロキシの機能ではクライアントからのリクエスト内容を基本的には改変はせずにバックエンド サーバーへ転送する動作となります。このため、Microsoft Entra Private Access の機能での Kerberos 認証においても情報の改変はせずに、そのままバックエンド サーバーへ転送しているようです。
この点について、以下の二点にて実際にパケットを採取して比較確認を実施しましたが、差異はありませんでした。
このため、Kerberos 認証に関する情報については、コネクタ側での情報改変はせずに、クライアントから提示された情報をそのままバックエンド サーバーに転送しているようです。
o クライアント環境上で GSA クライアント経由して送信される Kerberos サービス チケットの内容
o Microsoft Entra Private Network コネクタ サーバー上でバックエンド サーバーに転送している Kerberos サービス チケットの内容