【図解】Microsoft Entra Kerberosとは？Entra参加端末がオンプレADのチケットをもらう仕組み

Windows端末をMicrosoft Entra参加にして、オンプレミスのActive Directoryからは外す。こうした構成が増える一方で、社内にはまだADで守られたファイルサーバや業務システムが残っています。ADに参加していない端末が、パスワードも入力せずにオンプレミスのファイルサーバへKerberosでつながる。そのとき、誰がどうやってチケットを発行しているのでしょうか。

この記事では、その答えになる「Microsoft Entra Kerberos」を扱います。設定すると、ADとEntra IDに何が作られるのか。サインインからファイルサーバへのアクセスまで、どのようなシーケンスでチケットがやり取りされるのか。動作確認と切り分けの方法まで、順に整理します。

この記事でわかること

Entra参加端末がオンプレADのチケットをもらう3つの方法と、Entra Kerberosの位置づけ
設定でADとEntra IDに作られるオブジェクト（AzureADKerberos、krbtgt_AzureAD）
Entra IDが「仮想のRODC」として部分TGTを出す仕組み
サインインからファイルサーバまでのシーケンスと、Azure Filesの場合
導入の前提、動作確認、うまくいかないときの切り分け

Windows認証シリーズ

この記事は3本シリーズの3本目です。①NTLM認証 → ②Kerberos認証の基礎 → ③Microsoft Entra Kerberos（この記事）。TGT、サービスチケット、PACといった言葉は②で説明しているので、先に読んでおくと理解しやすくなります。

Entra参加端末とオンプレADのすき間

Entra参加の端末は、オンプレミスのADにコンピュータアカウントを持っていません。それでも、Entra ConnectやCloud SyncでADのユーザーをEntra IDに同期している環境なら、オンプレミスのファイルサーバへシングルサインオンできます。サインインすると、Entra IDがPRT（Primary Refresh Token）と一緒に、ユーザーのオンプレミスのドメインの情報を端末に返すからです。

問題は、どうやってオンプレミスのTGTを手に入れるかです。パスワードでサインインした場合は、端末がそのパスワードを使ってDCに通常のAS交換をすれば済みます。しかしWindows Hello for Business（PINや生体認証）やFIDO2セキュリティキーでサインインした場合、端末はパスワードを持っていないので、パスワードから作る鍵で事前認証ができません。この場合の方法は3つあります。

図1　Entra参加端末がオンプレADのTGTを手に入れる3つの方法

方法	仕組み	準備
パスワードでサインイン	端末がDCに通常のAS-REQを送る	DCへの通信だけ
鍵の信頼・証明書の信頼	Windows Helloの鍵や証明書を使うKerberos（PKINIT）でAS-REQを送る	DCの証明書などPKIの構築。証明書の信頼ではユーザー証明書も必要
クラウドKerberos信頼	Entra IDが部分TGTを発行し、DCで完全なTGTに交換する	Microsoft Entra Kerberosの設定。PKIは不要

Microsoftは、クラウドKerberos信頼を「PKIの構築や公開鍵の同期が要らず、ほかの方式より導入しやすい方式」と位置づけています。FIDO2セキュリティキーでのオンプレミスへのSSOも、同じMicrosoft Entra Kerberosの仕組みを使います。

Microsoft Entra Kerberosとは

Microsoft Entra Kerberosは、Entra IDをクラウド上のKDCとして動かし、Kerberosのチケットを発行させる仕組みです。2021年に登場しました。Entra IDは2種類のTGTを発行します。

図2　Entra Kerberosが発行する2種類のTGT

項目	クラウドTGT	部分TGT
レルム	`KERBEROS.MICROSOFTONLINE.COM`	オンプレミスのADドメイン（例：`CORP.EXAMPLE`）
中身	クラウドのサービス向けの認可情報	ユーザーのSIDだけ。グループの情報（PAC）はない
使い道	Azure Files、Azure SQL Managed Instance などのサービスチケットを、そのままEntra IDからもらう	オンプレミスのDCに渡して、完全なTGTに交換する
DCとの通信	不要	交換とサービスチケットの取得に必要
Windowsでの確認	`klist cloud_debug`	`dsregcmd /status` の `OnPremTgt`、交換後は `klist`

大事なのは、オンプレミスのリソースについては、Entra IDがやるのは「本人確認と部分TGTの発行」までだという点です。グループに基づく認可とサービスチケットの発行は、これまでどおりオンプレミスのDCが担当します。Entra IDがADのグループ情報を勝手に作ってチケットに入れることはありません。

設定するとADに何が作られるか

Microsoft Entra Kerberosは、PowerShellのモジュールで「Kerberosサーバオブジェクト」を作ることで有効になります。ここでは、オンプレミスのリソースへのSSO（クラウドKerberos信頼・FIDO2）のための手順を追います。

モジュールを準備する

ドメインコントローラに通信できるコンピュータに、AzureADHybridAuthenticationManagement モジュールを入れます。PowerShell Galleryで配布されていて、Entra Connectのサーバでなくても構いません。

管理用のコンピュータ（管理者のPowerShell）

[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

Kerberosサーバオブジェクトを作る

Set-AzureADKerberosServer で、ADとEntra IDの両方にKerberosサーバオブジェクトを作ります。必要な権限は、ADのDomain AdminsとEnterprise Adminsのメンバー、Entra IDのハイブリッドID管理者ロールです。ユーザーがいるドメインごとに実行します。

管理用のコンピュータ（管理者のPowerShell）：MFAを使う環境での例

$domain = $env:USERDNSDOMAIN
$userPrincipalName = "admin@example.onmicrosoft.com"
$domainCred = Get-Credential
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential $domainCred

作られたものを確かめる

コマンドを実行すると、ADに2つのオブジェクトができます。1つはDomain Controllers OUにある AzureADKerberos というコンピュータオブジェクトで、読み取り専用ドメインコントローラ（RODC）のように見えますが、実際のサーバはありません。もう1つはUsersコンテナにある krbtgt_AzureAD という無効化されたユーザーで、TGTを暗号化する鍵を持っています。同じ鍵がEntra IDのKerberosサーバオブジェクトにも安全に登録されます。

図3　Set-AzureADKerberosServerで作られるもの

管理用のコンピュータ（管理者のPowerShell）

Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential (Get-Credential)

表示される項目	意味
ComputerAccount	ADに作られたコンピュータオブジェクト（AzureADKerberos）
UserAccount	TGTを暗号化する鍵を持つ無効化されたユーザー（`CN=krbtgt_AzureAD,CN=Users,…`）
KeyVersion	AD側の鍵のバージョン。鍵を更新するたびに増える
CloudKeyVersion	Entra ID側の鍵のバージョン。KeyVersionと一致していることを確かめる
KeyUpdatedOn ／ KeyUpdatedFrom	鍵を作成・更新した日時と、更新したDC

ADの資格情報は、DOMAIN\user ではなくUPN形式（user@corp.example）で入力します。DOMAIN\user 形式だとNTLMで接続しようとして失敗することがあります。

端末のポリシーを設定する

Windows Hello for BusinessでクラウドKerberos信頼を使うには、端末側で2つのポリシーを有効にします。Intuneなら設定カタログで、グループポリシーなら コンピューターの構成 ›› 管理用テンプレート ›› Windows コンポーネント ›› Windows Hello for Business で設定します。

Intuneの設定（設定カタログ）	値	意味
Use Windows Hello For Business	true	Windows Hello for Businessを使う
Use Cloud Trust For On Prem Auth	Enabled	オンプレミスの認証にクラウドKerberos信頼を使う
Require Security Device	true（推奨）	鍵をTPMに保管する

「オンプレミス認証に証明書を使用する」ポリシーが有効だと、証明書の信頼が優先されます。クラウドKerberos信頼を使う端末では、このポリシーを未構成にしておきます。

Entra IDは「仮想のRODC」として振る舞う

AzureADKerberosオブジェクトがRODC（読み取り専用ドメインコントローラ）の形をしているのには理由があります。Entra Kerberosは、RODCのために用意されていた仕組みをそのまま借りているからです。まず、ふつうのRODCがどう動くのかを見ておきます。

ふつうのRODCの動き

RODCは、支店のように物理的なセキュリティを確保しにくい場所に置くための、読み取り専用のDCです。ADのデータは本社などの書き込み可能なDC（RWDC）から複製されますが、ユーザーのパスワードは原則として持っていません。どのユーザーのパスワードを手元に置いてよいかは、後で説明するパスワードレプリケーションポリシー（PRP）で決めます。

ポイントは、RODCごとに専用のkrbtgtアカウントがあることです。ふつうのDCは、ドメインで共通の krbtgt の鍵でTGTを暗号化します。RODCは、作成時に自動で作られる krbtgt_12345 のような「krbtgt_ランダムな数字」という自分専用のアカウントの鍵を使います。RODCが盗まれても、ドメイン共通のkrbtgtの鍵は漏れず、ほかのDCが出したチケットまで偽造されることはありません。

支店のユーザーがサインインすると、RODCは次のように動きます。

状況	RODCの動き
ユーザーのパスワードを手元に持っている	自分で事前認証を確かめ、`krbtgt_数字` の鍵でTGTを作って返します。本社への回線が切れていても、支店の中で認証できます。
パスワードを持っていない	要求を書き込み可能なDCに転送し、そちらで認証してもらいます。そのユーザーがPRPで許可されていれば、パスワードを書き込み可能なDCから複製して、次からは手元で認証できるようにします。
ほかのDCが作ったTGTが届いた	自分の鍵では作っていないので、書き込み可能なDCに転送します。

図4　ふつうのRODCの動き。自分専用のkrbtgt_数字の鍵でTGTを作り、置いてよいパスワードはPRPで決まる

アカウント	使う人	漏れたときの影響
`krbtgt`	書き込み可能なDC（ドメインで共通）	ドメインのどんなTGTでも偽造できる（ゴールデンチケット）
`krbtgt_数字`	そのRODCだけ	そのRODCが出すTGTだけ。RODCが出せるのは、PRPで許可されたユーザーに限られる
`krbtgt_AzureAD`	Entra ID（仮想のRODCとしてのAzureADKerberos）	部分TGTを偽造されるおそれがある。交換できるのはPRPで許可されたユーザーに限られる

Entra Kerberosも同じ仕組みを使う

Entra Kerberosは、Entra IDを「どこにも実体のないRODC」としてADに登録します。それが AzureADKerberos というコンピュータオブジェクトで、その専用のkrbtgtアカウントが krbtgt_AzureAD です。ふつうのRODCの krbtgt_数字 と同じ役割で、Entra IDはこの鍵で部分TGTを作ります。

ふつうのRODCと違うのは、Entra IDがユーザーのパスワードを持っていない点です。そのため、Entra IDが出せるのはユーザーのSIDだけを入れた部分TGTで、グループ情報を詰めた完全なTGTはオンプレミスのDCが作ります。DCは krbtgt_AzureAD の鍵も知っているので、部分TGTを開けて確かめられます。そして、そのユーザーがAzureADKerberosのPRPで許可されているかを確認してから、完全なTGTに交換します。

図5　Entra Kerberosも同じ仕組み。Entra IDが仮想のRODCとして部分TGTを出し、DCがPRPを確認して完全なTGTに交換する

パスワードレプリケーションポリシー（PRP）とは

PRP（Password Replication Policy）は、RODCごとに設定する「このRODCに、どのユーザーのパスワードを置いてよいか」のリストです。RODCのコンピュータオブジェクトの2つの属性に保存されていて、Active Directoryユーザーとコンピューターでは、RODCのプロパティの「パスワードレプリケーションポリシー」タブで確認できます。

リスト	属性	意味
許可リスト	`msDS-RevealOnDemandGroup`	パスワードを置いてよいユーザー・グループ
拒否リスト	`msDS-NeverRevealGroup`	パスワードを絶対に置かないユーザー・グループ。許可リストより優先される

判定のルールは単純で、「拒否リストに入っていれば拒否、入っていなくて許可リストに入っていれば許可、どちらにも入っていなければ許可しない」です。拒否が許可より優先されるので、許可リストに広くグループを入れても、拒否リストに入っている特権アカウントは除かれます。

図6　PRPの判定。拒否リストが許可リストより優先される

既定の中身は、ふつうのRODCとAzureADKerberosで考え方が違います。

項目	ふつうのRODC	AzureADKerberos
許可リスト	「Allowed RODC Password Replication Group」だけ。このグループは最初は空なので、新しいRODCは誰のパスワードも置かない	Domain Users が入っているため、ドメインの一般ユーザーは基本的に交換できる
拒否リスト	「Denied RODC Password Replication Group」（Domain Admins、Enterprise Admins、Schema Admins、Cert Publishers、Group Policy Creator Owners、ドメインコントローラなど）と、Administrators、Server Operators、Backup Operators、Account Operators	特権の高いグループ。Microsoftは、既定のPRPでは特権アカウントがクラウドKerberos信頼やFIDO2でサインインできないと説明している
考え方	基本は拒否。支店で使う人だけを許可する	基本は許可。特権アカウントだけを拒否する

つまり、Entra Kerberosを有効にすると、特権グループに入っていないドメインユーザーは、そのまま部分TGTを完全なTGTに交換できる状態になります。「この人たちには使わせたくない」というユーザーやグループがあれば、拒否リストに追加します。逆に、使える人を絞りたい場合は、許可リストから Domain Users を外し、専用のグループだけを入れます。Microsoftも、既定を拒否にして使ってよいグループだけを明示的に許可する運用を勧めています。

AzureADKerberosの拒否リストの中身は、作成した時期や環境によって違うという報告もあります。導入したら、実際の中身を確認しておくと安心です。

DC（管理者のPowerShell）：AzureADKerberosのPRPを確認する

Get-ADComputer AzureADKerberos -Properties msDS-RevealOnDemandGroup,msDS-NeverRevealGroup

特権アカウントのPRPは緩めない

Domain Adminsなどの特権アカウントを拒否リストから外すと、Entra IDを経由してADの特権アカウントのチケットが手に入る経路ができてしまいます。Microsoftは、AzureADKerberosオブジェクトのPRPを緩めて特権アカウントを使えるようにすることは推奨しないと明記しています。管理作業は、クラウドKerberos信頼ではない別の方法で行います。

サインインからファイルサーバまでのシーケンス

Windows Hello for BusinessでEntra参加端末にサインインし、オンプレミスの共有フォルダを開くまでの流れを追います。前半はEntra IDとのやり取り、後半はオンプレミスのDCとのやり取りです。

図7　Entra Kerberosのシーケンス（クラウドKerberos信頼）

No.	やり取り	中で起きていること
①〜②	nonceの要求と応答	サインイン画面でPINや生体認証を使うと、LSASSの中のCloud AP（クラウド認証のプロバイダ）がEntra IDにnonce（使い捨ての値）を要求します。
③	署名したnonce	Cloud APが、TPMなどで保護されたユーザーの秘密鍵でnonceに署名して返します。Entra IDは登録済みの公開鍵で署名を確かめます。
④	PRT＋クラウドTGT＋部分TGT	Entra IDはPRTと一緒に、クラウドTGTと部分TGTを返します。LSASSがPRTと部分TGTを保管します。
⑤	DCを探す	共有フォルダを開こうとすると、LSASSの中のKerberosのプロバイダが、Windows Helloの鍵の情報からユーザーのドメインを割り出し、DC Locatorでドメインコントローラを探します。
⑥〜⑦	部分TGTの交換	部分TGTをDCに送り、DCが正しいと確かめれば完全なTGTが返ります。完全なTGTはLSASSに保管され、以後のサービスチケットの要求に使われます。
⑧〜⑨	TGS交換	完全なTGTで、`cifs/fs01.corp.example` のサービスチケットをDCからもらいます。ここからはドメイン参加端末とまったく同じです。
⑩	AP交換	SMBのセッション確立の中でサービスチケットをファイルサーバに渡し、アクセスします。パスワードは一度も入力していません。

このうち、Entra Kerberosならではのステップは④と⑥⑦です。それぞれ「誰から誰へ、何が送られるか」を図で見ていきます。

Entra IDがPRTと部分TGTを返す（④）

本人確認ができると、Entra IDは3つのものを端末に返します。PRTはEntra IDのアプリにシングルサインオンするためのトークンで、Kerberosのチケットではありません。クラウドTGTはAzure Filesなどのクラウドのサービス用、部分TGTはオンプレミスのAD用です。

部分TGTは krbtgt_AzureAD の鍵で暗号化されていて、中にはユーザーのSIDしか入っていません。Entra IDはADのグループ情報を持っていないので、PACを作れないためです。そのため、部分TGTだけではオンプレミスのリソースにアクセスできません。

図8　PRTと部分TGTの受け取り（Entra ID → PC）

部分TGTをDCに渡す（⑥）

共有フォルダを開くと、端末は部分TGTをオンプレミスのDCに送ります。DCは krbtgt_AzureAD の鍵で部分TGTを開け、Entra IDが正しく発行したものかを確かめます。あわせて、そのユーザーがAzureADKerberosオブジェクトのPRPで許可されているかを確認します。

この交換は書き込み可能なDCが行います。MicrosoftはクラウドKerberos信頼を使う場合、Windows Hello for Businessで認証する各サイトに、十分な数の書き込み可能なDCを置くよう案内しています。

図9　部分TGTの交換（PC → DC）

DCが完全なTGTを返す（⑦）

DCはADからユーザーの所属グループなどを読み出してPACを作り、ドメインのkrbtgtの鍵で暗号化した完全なTGTを返します。ここから先は、ドメイン参加端末がサインイン時にもらうTGTと同じものです。⑧以降は、Kerberosの記事で説明したTGS交換とAP交換がそのまま行われます。

図10　完全なTGTの受け取り（DC → PC）

NTLMのリソースにもSSOできる

Microsoftは、この方式でサインインした端末が、NTLMで認証するリソースにもSSOできると案内しています。パスワードを入力していない端末でもNTLMの応答を計算できるよう、対応したDCが必要な鍵を端末に渡す仕組みがあります。対応しているDCかどうかは、nltest /dsgetdc:＜ドメイン＞ /keylist /kdc で確かめられます。

クラウドのリソース（Azure Files）の場合

クラウドTGTを使うと、Azure Filesのファイル共有にKerberosでアクセスできます。この場合、オンプレミスのDCは関わりません。端末はクラウドTGTを使ってEntra IDにTGS-REQを送り、Entra IDがストレージアカウントのサービスプリンシパルの鍵で暗号化したサービスチケットを返します。Kerberosのメッセージは、インターネット越しにHTTPS（KDCプロキシ）で運ばれます。

図11　Azure Filesのシーケンス

設定	内容
ストレージアカウント	ID ベースのアクセスで「Microsoft Entra Kerberos」を有効にし、作られたアプリに管理者の同意を与える
端末	`CloudKerberosTicketRetrievalEnabled` を1にして、サインイン時にクラウドTGTを取るようにする
条件付きアクセス	Azure FilesのEntra Kerberos認証はMFAに対応していないため、MFAを要求するポリシーからストレージアカウントのアプリを除外する
ADと併用する場合	同じ名前空間でADのストレージアカウントも使うなら、ホスト名とレルムの対応付け（HostToRealm）を設定する
アクセス許可	ハイブリッドのユーザーは共有レベルのアクセス許可とNTFSのACLで判断する。ACLを設定する作業にはDCへの通信が必要

端末（管理者のコマンドプロンプト）：サインイン時にクラウドTGTを取る設定

reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1

ADにアカウントを持たないクラウド専用のユーザーでも、Azure FilesにKerberosでアクセスできる機能がプレビューで提供されています。この場合の認可はAzure RBACで行います。

端末の参加形態ごとの違い

同じユーザーが同じファイルサーバにアクセスする場合でも、端末の参加形態とサインイン方法によって、最初のTGTをくれる相手が変わります。

比べる点	AD参加	Entra参加（パスワード）	Entra参加・ハイブリッド参加（Windows Hello・FIDO2）
最初の本人確認	オンプレミスのDC	Entra ID（オンプレはDCがAS交換）	Entra ID
オンプレのTGTをくれる人	DC（AS交換）	DC（AS交換）	Entra IDが部分TGT → DCが完全なTGT
必要な準備	ドメイン参加	ユーザーの同期	ユーザーの同期、Entra Kerberos、端末のポリシー
DCとの通信	チケットを取るとき	チケットを取るとき	部分TGTの交換とチケットを取るとき
Azure Files（Entra Kerberos）	対象外	クラウドTGTで利用できる

ハイブリッド参加の端末では、Windows Hello for Businessを登録したあとの最初のサインインに、DCへの通信が必要です。一度DCと通信してサインインすれば、以後のロック解除はキャッシュで行えます。

導入の前提と注意点

項目	内容
ユーザー	ADのユーザーがEntra Connect（またはCloud Sync）で同期されていること。`onPremisesSamAccountName`、`onPremisesDomainName`、`onPremisesSecurityIdentifier` などの属性が必要です。ADにアカウントがないユーザーは、オンプレのTGTを取れません。
端末	Windows 10 バージョン2004以降、またはWindows 11で、Entra参加かハイブリッド参加であること。
DC	部分TGTの交換に対応したバージョンと更新プログラム。各サイトに十分な数の書き込み可能なDC。
サインイン方法	クラウドKerberos信頼はWindows Hello for Business、FIDO2などの鍵ベースのサインインが対象。パスワードでのサインインは対象外です。
パスワードの期限	パスワードの有効期限が切れたユーザーは、FIDO2やクラウドKerberos信頼でのサインインがブロックされます。先にパスワードを変更する必要があります。
鍵の更新	`krbtgt_AzureAD` の鍵は、ADのkrbtgtと同じように定期的に更新します。ほかのツールではなく、`Set-AzureADKerberosServer` の `-RotateServerKey` で更新します。
対象外の使い方	資格情報を入力するRDPやVDI、「別のユーザーとして実行」は、クラウドKerberos信頼では使えません。

管理用のコンピュータ（管理者のPowerShell）：鍵を更新する

Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential $domainCred -RotateServerKey

鍵の更新は、AD側とEntra ID側の両方を同時に更新するため、反映に数時間かかります。そのため、24時間以内に続けて更新することは通常できません。

動作確認と切り分け

うまく動かないときは、クライアント、DC、Entra IDとADの間の3か所に分けて確認します。

図12　確認する3つの観点

Entra参加端末（コマンドプロンプト）

C:\> dsregcmd /status
C:\> klist cloud_debug
C:\> klist
C:\> nltest /dsgetdc:corp.example /keylist /kdc

確認する項目	見るポイント
AzureAdJoined	YES（ハイブリッド参加ならDomainJoinedもYES）
AzureAdPrt	YES。NOならEntra IDへのサインイン自体を先に確認する
OnPremTgt	YESなら部分TGTを持っている。NOならKerberosサーバオブジェクト、ユーザーの同期、サインイン方法を確認する
CloudTgt	YESならクラウドTGTを持っている（Azure Filesで使う）
klist	共有を開いたあとに `krbtgt/CORP.EXAMPLE` と `cifs/…` のチケットがあれば、交換とTGS交換が成功している

症状	よくある原因	確認すること
OnPremTgt が NO	Kerberosサーバオブジェクトがない、ユーザーが同期されていない、パスワードでサインインしている	`Get-AzureADKerberosServer`、Entra IDのユーザーのオンプレミス属性、サインイン方法
一般ユーザーは使えるが管理者は使えない	AzureADKerberosオブジェクトのPRPで特権グループが拒否されている	想定どおりの動作。管理作業は別の方法で行う
共有を開くと資格情報を聞かれる	DCに届かない（VPNなし）、DC Locatorのタイムアウト、交換に対応したDCがない	`nltest /dsgetdc:`、DNS、DCの更新状況
KeyVersion と CloudKeyVersion が違う	鍵の更新が片側だけで止まっている	`Set-AzureADKerberosServer` で更新し直す
Azure Filesにつながらない	クラウドTGTの取得設定がない、管理者の同意がない、MFAを要求する条件付きアクセス	`CloudKerberosTicketRetrievalEnabled`、アプリの同意、条件付きアクセスの除外
ネットワークが変わるとAzure Filesが切れる	VPNの再接続やスリープ復帰で、KDCプロキシの設定のキャッシュが消える	グループポリシー「Kerberos クライアントの KDC プロキシサーバーを指定する」でKDCプロキシを固定する

まとめ

Microsoft Entra Kerberosは、Entra IDを「仮想のRODC」としてADに登録し、Entra参加の端末に部分TGTを発行させる仕組みです。グループの情報を詰めた完全なTGTとサービスチケットは、これまでどおりオンプレミスのDCが発行するので、ファイルサーバ側の設定やACLを変える必要はありません。

項目	押さえておくこと
位置づけ	Windows HelloやFIDO2でサインインした端末が、パスワードなしでオンプレのTGTを得るための仕組み（クラウドKerberos信頼）
作られるもの	ADのAzureADKerberos（RODCの形のコンピュータ）とkrbtgt_AzureAD（鍵を持つユーザー）、Entra IDのKerberosサーバオブジェクト
チケットの流れ	Entra IDが部分TGT（SIDだけ）→ DCが検証して完全なTGT（PAC入り）→ 通常のTGS交換・AP交換
制御	AzureADKerberosのPRPで交換できるユーザーを制限。特権アカウントは既定で使えない
クラウドのリソース	クラウドTGTでAzure Filesなどのサービスチケットを直接もらう（DCは不要）
確認	`dsregcmd /status` の OnPremTgt・CloudTgt、`klist`、`Get-AzureADKerberosServer`

NTLM、Kerberos、Entra Kerberosと3本を通して見ると、Windowsの認証は「サーバが毎回DCに聞く」形から「チケットを見せる」形へ、そして「クラウドがチケット発行の入り口になる」形へと移ってきたことが分かります。オンプレミスのADを残したままパスワードレスに進めるとき、Entra Kerberosはその橋渡しになる仕組みです。

参考にした資料

この記事は、次の資料を確認して書いています。

Microsoft Entra Kerberos

Windows Hello for Business と Azure Files

RODC と PRP

Microsoft 以外の資料