この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。Microsoft LearnのAzure Virtual Desktop認証、Microsoft Entra SSO、Microsoft Entra Kerberos、Windows 365ネットワーク設計の公式情報を確認し、旧版の「2026年1月パッチが原因」という前提と、Entra KerberosでオンプレミスADへの依存を完全に排除できるという説明を見直しました。検証ステータス：📘 Microsoft公式情報確認済み／実環境での障害再現は未実施
Azure Virtual Desktop（AVD）やWindows 365で「サインインできない」「資格情報を何度も求められる」「セッションには入れるがファイルサーバーへつながらない」といった問題が出たとき、最初からWindows UpdateやKerberosだけを原因と決めつけないことが重要です。
認証は1回で終わる処理ではなく、AVDでは少なくともクラウドサービスへの認証、リモートセッションへの認証、セッション内のアプリやオンプレミス資源への認証に分かれます。Windows 365でも、Cloud PCへの接続と、その中からアクセスする業務資源の認証は分けて考えた方が切り分けしやすくなります。
まず見る：どの段階で失敗しているか
| 段階 | 代表的な症状 | 主に確認する場所 |
|---|---|---|
| クラウドサービス認証 | リソース一覧が出ない、接続開始前に拒否される | Microsoft Entra ID、条件付きアクセス、MFA、ユーザー割り当て |
| リモートセッション認証 | AVD/Cloud PCは見えるがWindowsへのサインインで失敗 | SSO設定、Windows Cloud Login、参加状態、RDP認証設定 |
| セッション内認証 | デスクトップには入れるがSMB、社内Web、SQLなどで認証失敗 | Kerberos、AD DS到達性、DNS、Kerberos server object、SPN |
この3段階を分けるだけで、「AVD全体が壊れた」のか、「Windowsへのサインインだけが失敗している」のか、「セッション内からオンプレミス資源へ行く経路だけが壊れている」のかを切り分けられます。
Entra参加にしても、オンプレミス資源のAD依存が必ず消えるわけではない
Microsoft Entra joined のAVDセッションホストやWindows 365 Cloud PCは、端末自体をオンプレミスAD DSへドメイン参加させずに運用できます。これは管理や展開の依存関係を減らすうえで大きな利点です。
ただし、オンプレミスのSMB共有やWindows統合認証のWebサイトなど、従来のKerberosを使う資源へアクセスする場合は話が別です。
Microsoft Entra Kerberosでは、クラウド資源向けのCloud TGTと、オンプレミス資源向けのOnPremTgtは役割が異なります。オンプレミス資源向けのOnPremTgtは部分的なTGTであり、それだけでは十分ではありません。ハイブリッド利用では、最終的にオンプレミスのドメインコントローラーと交換して完全なTGTを取得する経路が必要になります。
つまり、「Entra Kerberosを有効にすれば、オンプレミスKerberos資源へのアクセスでもDC到達性が不要になる」とは限りません。ここは旧版から大きく修正した点です。
まず試す：セッションホスト側で状態を確認する
dsregcmd /status
klist cloud_debug
klist
dsregcmd /status では、参加状態だけでなく、環境によって CloudTgt や OnPremTgt の状態も確認できます。Microsoftの現在のEntra Kerberos資料では、Cloud TGTはクラウド側資源向け、OnPremTgtはオンプレミス資源へつなぐための部分TGTとして説明されています。
ここを見る
- AzureAdJoined / DomainJoined：想定した参加方式になっているか
- AzureAdPrt：Microsoft Entra IDのPrimary Refresh Tokenを取得できているか
- CloudTgt：クラウド向けKerberosチケットがあるか
- OnPremTgt：オンプレミス資源向けのTGT取得経路が成立しているか
- klist：必要なSPN向けサービスチケットが実際に発行されているか
AVDのSSOは「enablerdsaadauth」だけで終わらない
MicrosoftのAVD公式手順では、Microsoft Entra IDを使ったSSOを有効にする際、ホストプール側で enablerdsaadauth を有効にします。
enablerdsaadauth:i:1ただし、実際のSSOにはこれ以外にも、Windows Cloud Login、条件付きアクセス、対象デバイス、クライアント対応状況などが関係します。
さらに、Microsoft Entra hybrid joined セッションホストではKerberos server objectが必要です。Microsoft Entra joined セッションホストでも、オンプレミスAD DSのKerberos資源へアクセスする場合はKerberos server objectが必要になるケースがあります。
「ログインできない」と「社内共有へ入れない」を分ける
たとえば、ユーザーがAVDのデスクトップには正常にサインインできる一方、セッション内から \\fileserver\share にだけアクセスできない場合、AVDサービスそのものよりも次を優先して確認します。
- 名前解決が正しいか
- セッションホストからドメインコントローラーへ必要な経路があるか
- Kerberos server objectが正しく構成されているか
- 対象サービスのSPNが正しいか
klistで対象サービスのチケットが発行されているか
逆に、リソース一覧の取得時点で失敗しているなら、Kerberosより先にMicrosoft Entra IDのサインインログや条件付きアクセスを確認します。
Windows 365はAVDと同じ設計にしない
Windows 365は内部的にAzure Virtual Desktopの接続基盤を利用しますが、Cloud PCの展開モデルやネットワーク責任範囲はAVDと同一ではありません。
Microsoftの現在のWindows 365アーキテクチャでは、新規構成ではMicrosoft Entra join + Microsoft-hosted networkが推奨パターンです。オンプレミスへの直接ネットワーク接続やMicrosoft Entra hybrid joinが必要な場合に、Azure network connectionを選びます。
そのため「AVDでこうしたからWindows 365でも同じVNet・同じドメイン参加・同じKerberos構成」と機械的にそろえるのではなく、Cloud PCが本当にオンプレミスのKerberos/NTLM資源を必要とするかを先に確認する方が設計を簡素化できます。
パッチ起因を疑うときの確認順
旧版では「2026年1月パッチ起因の認証エラー」を前提にしていましたが、今回の見直しでは、その前提を裏付けるMicrosoft公式情報を確認できませんでした。そのため、特定の更新プログラムが原因だと決めつける記述は削除しています。
- 失敗が始まった日時
- 対象端末のOSビルドとインストール済みKB
- 影響ユーザーと正常ユーザーの差
- AVD/Windows 365への接続自体が失敗するのか、セッション内だけ失敗するのか
- Entraサインインログ、条件付きアクセス結果、イベントログ
dsregcmd /statusとklistの結果
この情報をそろえてから、MicrosoftのWindows release healthや既知の問題と突き合わせれば、単なる時系列の一致と、本当にKBが原因であるケースを分けやすくなります。
仕事で使うなら：認証経路を図にして残す
flowchart LR
A[ユーザー端末] --> B[Microsoft Entra ID]
B --> C[AVD / Windows 365 接続]
C --> D[Windows セッション]
D --> E[Microsoft 365 / SaaS]
D --> F[Azure Files / Cloud Kerberos]
D --> G[オンプレミス SMB / Web / SQL]
G --> H[AD DS / Domain Controller]
障害対応では、この図に「どこまで成功しているか」を書き込むだけでも効果があります。たとえばDまで成功してGだけ失敗しているなら、Entra IDへの初回サインインを何度も調べるより、DNS・Kerberos・DC到達性へ調査を絞れます。
まとめ
AVDやWindows 365の認証障害では、Entra ID、リモートセッション、セッション内のKerberosを一つの「ログイン」として扱わないことが重要です。
Microsoft Entra joinはAD DS依存を減らせますが、オンプレミスKerberos資源へのアクセスまで自動的にAD DS不要になるわけではありません。Microsoft Entra Kerberosも、クラウド向けCloud TGTとオンプレミス向けOnPremTgtで動作が異なります。
まず dsregcmd /status、klist cloud_debug、klist で状態を観察し、失敗している認証段階を特定してから設定を変える方が、障害対応を再現可能にできます。
公式情報・一次情報
- Microsoft Learn ― Azure Virtual Desktop identities and authentication
- Microsoft Learn ― Configure single sign-on for Azure Virtual Desktop using Microsoft Entra ID
- Microsoft Learn ― Introduction to Microsoft Entra Kerberos
- Microsoft Learn ― Windows 365 Azure network connection
この記事の更新履歴
この記事は、生成AIを活用した自動レビュー・更新フローにより内容を見直し、必要な修正を反映しています。
2026年9月13日
- 追加 認証を「クラウドサービス」「リモートセッション」「セッション内」に分ける切り分け手順と、
dsregcmd・klistによる確認方法を追加しました。 - 変更 AVDとWindows 365を同一構成として扱わず、それぞれの現在のMicrosoft推奨構成に沿って整理しました。
- 変更 Microsoft Entra KerberosのCloud TGTとOnPremTgtの違いを反映し、オンプレミス資源ではAD DSとのチケット交換が必要になる説明へ修正しました。
- 削除 Microsoft公式情報で裏付けられなかった「2026年1月パッチ起因」という断定、未確認のレジストリ設定、実在性を確認できないデプロイコマンド例を削除しました。
