Azure Virtual Desktop（AVD）を構築したのに「ローカル管理者なら入れるのに、Microsoft Entra ID（旧Azure AD）ユーザーではサインインできない」という相談は非常に多いです。原因はネットワークやAVD側の障害よりも、MFA・条件付きアクセス・セキュリティ既定や、接続元クライアントの状態不備であることがほとんどです。本記事では、実運用を想定した切り分け手順とチェックリストを用意し、どこをどう直せばEntra IDユーザーでAVDに正しくサインインできるようになるかを詳しく解説します。
Azure Virtual Desktop に Entra ID ユーザーで接続できないときの全体像
今回のケースを整理すると、次のような状態になっています。
- AVDのセッションホスト自体は正常に作成・起動している
- セッションホストは「Microsoft Entra ID 参加済み」と表示されている
- ローカル管理者アカウントではリモートデスクトップ接続が可能
- しかし、同じホストにMicrosoft Entra IDユーザーではサインインできない
- ユーザー単位MFA無効化、ホストプールのEntra SSO有効化、NLAオフなどを試したが改善しない
この時点で、次のような重要な示唆があります。
- ローカル管理者で入れるのでネットワークやNSG（セキュリティグループ）の問題ではない
- ホスト側のOSやAVDエージェントは基本的に機能している
- 問題はEntra ID ベースのサインイン経路に限定される
つまり、「AVD＋Entra IDサインイン」に固有の条件をひとつでも満たしていない、あるいは条件付きアクセスなどで過剰に厳しいポリシーが適用されてしまっていると考えるのが合理的です。
典型的な原因パターン
現場でよく遭遇する原因を、ざっくり次の3カテゴリに分けられます。
| カテゴリ | 主な原因 | よくある症状 |
|---|---|---|
| 認証ポリシー | ユーザー単位MFA、条件付きアクセス、セキュリティ既定によりVMサインインにもMFAが強制されている | サインイン画面から進まない、AVD接続が即時切断される、Entraサインインログで「要件未満」 |
| 接続元デバイス | 接続元PCがEntra未登録、別テナント登録、OSバージョンが古いなど | 資格情報入力後に「アクセスが拒否されました」、SSOが効かない、毎回パスワード入力になる |
| AVDの割り当て・設定 | アプリグループ未割り当て、ホストプール設定ミス、ユーザーUPN不一致など | AVDクライアント上にリソースが表示されない、接続前に「アクセスがありません」と表示 |
この記事では、これらの原因をひとつずつ潰していく形で解説していきます。
Azure Virtual Desktop と Entra ID サインインの仕組みを理解しておく
トラブルシューティングの前に、仕組みを簡単に押さえておきましょう。
- AVDは「Azure側のコントロールプレーン」と「Windows セッションホスト」の2階層構造
- ユーザーはまずAVDサービス（コントロールプレーン）にサインインし、そこで公開アプリ・デスクトップの一覧を取得
- 接続時には、AVDクライアントがMicrosoft Entra ID トークンを使ってセッションホストに対して認証を行う
ここで重要なのは、Windows セッションホストに対するサインインは、Entra IDのクラウドアプリ「Microsoft Azure Windows Virtual Machine Sign-in」（アプリID：372140e0-b3b7-4226-8ef9-d57986796201）として扱われる点です。つまり、条件付きアクセスやMFAの評価対象になり得る、ということです。
このため、ここに対して「MFA必須」など過度な制約を掛けてしまうと、VMサインイン自体がブロックされ、AVDからのログオンが失敗します。まずはこの前提を押さえたうえで、順番に確認していきます。
認証ポリシー（MFA／条件付きアクセス／セキュリティ既定）を確認する
「ローカル管理者では入れるのに、Entra IDユーザーでは入れない」という状態では、認証ポリシーの影響を最優先で疑うべきです。特に、次の3つを必ずチェックしてください。
ユーザー単位のMFA設定を確認する
古くからのテナントでは、今でもユーザー単位MFAが一部に残っていることがあります。該当ユーザーが「有効（Enabled）」あるいは「強制（Enforced）」になっていると、VMサインインのフェーズでもMFAを期待する挙動になり、結果として失敗することがあります。
| 状態 | 表示例 | VMサインインへの影響 |
|---|---|---|
| 無効 | Disabled | ユーザー単位MFAによる影響なし（推奨） |
| 有効 | Enabled | 条件によってはVMサインイン時にMFA要求となり失敗する可能性 |
| 強制 | Enforced | 基本的にMFA前提となり、AVDログオンで不具合が出やすい |
AVD検証時は、対象ユーザーのユーザー単位MFAを必ず「Disabled」にしておくことを強く推奨します。条件付きアクセスによるモダンなMFA制御に移行している場合でも、古いMFA設定が残っていないか必ず再確認してください。
条件付きアクセス（CA）のクラウドアプリ対象を見直す
現在のベストプラクティスでは、MFAやアクセス制御は「条件付きアクセス」で行うのが主流です。しかし、うっかり次のような状態になっていると、AVDログオンが失敗します。
- クラウドアプリ「すべてのアプリ」を対象にMFAを必須にしている
- または、「Microsoft Azure Windows Virtual Machine Sign-in」を含む形で対象を定義し、そのポリシーでMFA必須にしている
現時点では、AVDセッションホストのWindowsログオン自体にMFAを直接かける構成はサポートされていません。そのため、次のいずれかの対応が必要です。
- VMサインイン用クラウドアプリ「Microsoft Azure Windows Virtual Machine Sign-in」（アプリID：372140e0-b3b7-4226-8ef9-d57986796201）を、MFA必須ポリシーから除外する
- AVD用ユーザーやグループを別途作成し、VMサインインに影響するポリシーからユーザー／グループ単位で除外する
「AVD接続時だけなぜかMFA周りでこける」という場合、Entra IDのサインインログを見てみると「条件付きアクセスによるブロック」や「要求されたコントロールを満たしていない」といった理由で失敗していることが多々あります。まずはCAの対象アプリと除外設定を丁寧に洗い出してみてください。
セキュリティ既定（Security Defaults）とグローバル管理者の罠
新しめのテナントでは、初期状態でセキュリティ既定（Security Defaults）が有効になっていることがあります。セキュリティ既定が有効だと、特に次のような影響が出ます。
- 全体管理者（グローバル管理者）アカウントにMFAが必須になる
- 管理者ロールを持つアカウントでのサインインは基本的にMFA前提になる
その結果、グローバル管理者のアカウントでAVDログオンテストをすると、Security DefaultsによるMFA強制でVMサインインが成立せず、ログオンできないという状況が発生します。「管理者で試してダメだったので、AVDが壊れていると思った」というケースは非常に多いです。
この問題を避けるための実務的な対処は次の通りです。
- 検証用に管理者ロールを持たない一般ユーザーを1アカウント用意し、そのユーザーでAVDログオンを試す
- 必要に応じて、テナントのSecurity Defaultsを無効にし（または条件付きアクセスに移行し）、テストユーザーが過剰なMFA要求を受けないよう調整する
- 本番運用においても、「AVD利用用アカウント」と「管理用アカウント」を分離する（管理者で普段ログオンしない）
つまり、「グローバル管理者アカウントでAVDログオンをテストしない」というだけでも、無駄なハマりポイントを一つ潰すことができます。
接続元クライアント／デバイス要件を満たしているか確認する
Entra IDベースのAVD接続では、「セッションホスト側がEntra参加している」だけでは足りません。接続元PCの状態も重要な評価要素になります。ここを満たしていないと、いくらAVD側を調整してもサインインが成功しません。
対応OSとEntra登録・参加の要件
接続元のWindowsクライアントは、基本的に次の条件を満たしている必要があります。
- OSがWindows 10 / Windows 11 の 20H1 以降であること
- 接続先AVDセッションホストと同一テナントに対して、いずれかの状態になっていること
- Microsoft Entra 登録（Registered）
- Microsoft Entra 参加（Joined）
- ハイブリッド参加（Hybrid Joined）
この状態は、クライアントPC上で次のコマンドを実行すると確認できます。
dsregcmd /status
出力の中から、特に次の項目を確認します。
| 項目 | 期待値 | 意味 |
|---|---|---|
| AzureAdJoined | YES なら Entra 参加 | ドメイン参加の代わりにEntraに直接参加している状態 |
| WorkplaceJoined | YES なら Entra 登録 | 職場アカウントとしてEntraに登録された状態（BYODなど） |
| TenantId | AVDセッションホストのテナントIDと一致 | 接続元と接続先が同じEntraテナントに属していることを確認 |
少なくとも AzureAdJoined または WorkplaceJoined のどちらかが YES であり、TenantId がAVDセッションホストと同じでなければなりません。別テナントに参加・登録されている場合や、どちらも NO の場合、EntraベースのSSOやトークン発行が期待通りに動作せず、リモート接続が拒否されます。
リモートデスクトップクライアント（MSRDC）のバージョン
AVDに接続するクライアントとしては、次のどちらかを利用できます。
- Microsoft Store や公式サイトから提供される「Windows 用リモート デスクトップ クライアント」（MSRDC）
- Windowsに標準搭載されている従来のRDPクライアント（
mstsc.exe）
Entra IDベースの認証やSSOをフル活用したい場合は、必ずMSRDCの最新バージョンを利用してください。古いクライアントや、OS標準の古いバージョンでは必要な認証フローがサポートされておらず、接続プロファイルによってはログオンに失敗します。
サインインID（UPN形式）を正しく入力する
意外と多いのが、「ユーザー名の形式」が原因のトラブルです。AVDにEntraユーザーで接続する際は、次の形式でIDを入力します。
- UPN形式：
[email protected]
これを、オンプレミス時代の名残で「CONTOSO\user」のような形式で入力してしまうと、Entra ID認証として処理されず、ログオンに失敗する原因になります。サインインIDは常にUPN形式であることを徹底しましょう。
AVD側の割り当て・設定を再確認する
認証ポリシーと接続元デバイスに問題がない場合は、AVD側の設定を見直します。特に次の3点は必ずチェックしてください。
アプリ グループへのユーザー／グループ割り当て
AVDでは、実際にユーザーが利用するデスクトップやRemoteAppはアプリグループとして公開されます。ユーザーは「ホストプール」ではなく、このアプリグループに対して割り当てられている必要があります。
確認すべきポイントは次の通りです。
- 対象のユーザーまたはユーザーが所属するグループが、
- Desktopアプリグループ（フルデスクトップ用）、または
- RemoteAppのアプリグループ
- 同じユーザーに複数のアプリグループが割り当てられている場合、不整合がないか
正しく割り当てられていないと、AVDクライアントの画面にそもそもリソースが表示されなかったり、「アクセスがありません」と表示されて接続に進めなかったりします。
ホストプールのRDPプロパティとEntra SSO設定
ホストプールのRDPプロパティで「Entra シングルサインオン」を有効化する設定は、確かにログオン体験の向上には有効です。しかし、これだけでは問題解決にはなりません。
なぜなら、Entra SSOはあくまで「サインインできたあとにSSOするための設定」であり、そもそもの認証ポリシー（MFA/CA/セキュリティ既定）でブロックされている状態では機能しないからです。RDPプロパティは次のようなスタンスで扱いましょう。
- Entra SSO自体は有効にしておく（ユーザー体験向上のため）
- ただし、「Entra SSOをオンにすればMFA問題も解決する」という期待は持たない
- まずは条件付きアクセスやSecurity DefaultsでVMサインインをブロックしていないかを最優先で確認する
NLA（ネットワーク レベル認証）は基本オン推奨
トラブルシューティングの一環としてNLAをオフにする、という話もよく聞きますが、これは根本対策にはなりません。NLAはリモートデスクトップ接続の前段で認証を行う仕組みであり、Entra IDの認証ポリシーや条件付きアクセスで失敗している場合、NLAをオフにしても問題は解消されません。
- NLAをオフにすると、パスワード総当たり攻撃などに対する耐性が下がり、セキュリティリスクが増大します
- AVD構成では、基本的にNLAはオンのままにしておくべきです
「NLAを切ったら一瞬つながったように見えた」というケースもありますが、それは問題を隠蔽しているだけであり、本質的には認証ポリシーや接続元デバイス状態の見直しが必要です。
すぐ試せる実務向けチェックリスト
ここまでの内容を、「まず何から確認すればいいか」という順番に並べたチェックリストにまとめます。時間がない場合は、下記を上から順に潰していくだけでも、かなりの確率で問題点が洗い出せます。
- 接続元PCのEntra状態を確認
接続元クライアントでdsregcmd /statusを実行し、次を確認します。AzureAdJoinedまたはWorkplaceJoinedが YES になっているかTenantIdがセッションホスト側テナントと一致しているか
- ユーザー単位MFAが無効（Disabled）であることを確認
該当ユーザーのユーザー単位MFAを開き、「Enabled/Enforced」になっていないか再チェックします。 - 条件付きアクセスでVMサインインがブロックされていないか確認
条件付きアクセスのポリシーを確認し、- クラウドアプリ「Microsoft Azure Windows Virtual Machine Sign-in」（ID: 372140e0-b3b7-4226-8ef9-d57986796201）がMFA必須ポリシーの対象になっていないか
- もし対象になっているなら、そのポリシーから上記クラウドアプリ、またはAVD用ユーザー／グループを除外する
- セキュリティ既定（Security Defaults）の影響を確認
テナントにSecurity Defaultsが有効な場合、- グローバル管理者ではなく、管理者ロールを持たない一般ユーザーで接続テストを行う
- もしくは、検証目的で一時的にSecurity DefaultsやCAの影響からテストユーザーを除外する
- AVD側のアプリグループ割り当てを確認
対象ユーザー／グループが、接続したいDesktopアプリグループやRemoteAppアプリグループに適切に割り当てられているかを確認します。 - RDPクライアントの更新とUPN形式IDでの再接続
最新のWindows用リモートデスクトップクライアント（MSRDC）を使用し、- サインインIDをUPN形式（
[email protected]）で指定しているか - 古い接続プロファイルを一度削除し、新しくリソースをサブスクライブし直しているか
- サインインIDをUPN形式（
- セッションホストのイベントログで失敗理由を確認
セッションホスト側のイベントビューアで、次のログを中心に確認します。- Microsoft-Windows-AAD/Operational
- TerminalServices-RemoteConnectionManager
- TerminalServices-LocalSessionManager
ログとEntraサインインログを使った切り分け
上記チェックリストを実施しても原因が分からない場合は、ログを丁寧に追うことでヒントが見つかるケースが多くあります。
Microsoft Entra ID のサインインログ
Entra 管理センター（Azure ポータル）からユーザーのサインインログを開き、AVD接続時刻に対応するレコードを探します。特に次のようなポイントを確認してください。
- 「アプリケーション名」が「Microsoft Azure Windows Virtual Machine Sign-in」になっているログがあるか
- 「結果」が失敗の場合、その詳細メッセージや「条件付きアクセス」タブに表示される評価結果
- MFAが要求されているのに応答できていない、または要件を満たしていない、などのメッセージがないか
ここで条件付きアクセスによるブロックが確認できた場合は、ポリシーの対象・除外設定を見直すことで問題解決につながります。
セッションホスト側イベントログ
セッションホストのWindowsイベントログも重要です。特に次のログを確認します。
- アプリケーションとサービス ログ > Microsoft > Windows > AAD > Operational
- アプリケーションとサービス ログ > Microsoft > Windows > TerminalServices-RemoteConnectionManager
- アプリケーションとサービス ログ > Microsoft > Windows > TerminalServices-LocalSessionManager
ここにEntraトークンの取得失敗や、認証エラーの詳細、接続が拒否された理由などが記録されます。特定のユーザーだけエラーが出ているのか、全ユーザーで共通のエラーなのかを切り分けるのにも役立ちます。
設計・運用時に押さえておきたいベストプラクティス
一度トラブルを解消しても、運用やポリシー変更の結果、再び同じ問題が起こることがあります。以下のような設計・運用ルールをあらかじめ決めておくと、将来的なトラブルをかなり減らせます。
AVD利用用アカウントと管理用アカウントを分離する
グローバル管理者アカウントはSecurity Defaultsや条件付きアクセスの影響でMFAが必須になりやすく、AVDログオンテストには不向きです。次のような方針をおすすめします。
- 日常的なAVD利用は、管理者ロールを持たない一般ユーザーアカウントで行う
- テナント管理やポリシー変更などは、別の「管理専用アカウント」で実施する
- AVD検証用に、「CAから除外されたテストユーザー」を1つ用意し、障害時の切り分けに使えるようにしておく
条件付きアクセスの設計方針を明文化する
条件付きアクセスは強力な機能ですが、設計ルールが曖昧だと、知らないうちにAVDに影響する変更を加えてしまうことがあります。例えば次のようなルールを文書化しておくとよいでしょう。
- 「すべてのクラウドアプリ」を対象にするポリシーには、AVD関連アプリを含めない、またはAVDユーザーを除外する
- VMサインイン用クラウドアプリ（Microsoft Azure Windows Virtual Machine Sign-in）をMFA必須ポリシーで保護しない
- 新しいCAポリシーは必ず「報告のみ」モードでテストし、AVDログオンに影響が出ないことを確認してから有効化する
クライアントPCのEntra状態を標準化する
BYOD（個人所有PC）混在環境では、Entra登録・参加の状態がバラバラになりがちです。AVDを安定して使ってもらうには、次のようなルールづくりが有効です。
- 社給PCは必ずEntra参加（またはハイブリッド参加）させる
- BYODでの利用を認める場合も、少なくともEntra登録済みであることを必須条件にする
- ヘルプデスク向けに
dsregcmd /statusの読み方マニュアルを用意しておく
よくある質問と落とし穴
Q. NLA（ネットワーク レベル認証）をオフにすれば解決しますか？
A. いいえ。NLAをオフにしても、Entra IDの認証ポリシーや条件付きアクセスによるブロックは解消されません。むしろセキュリティリスクが増えるため、基本的には常にオンにしておくべきです。
Q. ローカル管理者でログオンできるのだから、AVDやネットワークは正常と考えていいですか？
A. 少なくとも「ネットワークやNSG、AVDエージェントの致命的な不具合ではない」と言えます。しかし、Entra ID経由の認証フローはローカルアカウントとは完全に別経路です。ローカル管理者で入れるのにEntraユーザーで入れない場合は、認証ポリシー／接続元デバイス状態／AVDの割り当てのいずれかに問題があると考えるのが妥当です。
Q. グローバル管理者アカウントで試してダメだったのですが？
A. Security Defaultsや条件付きアクセスにより、管理者アカウントにはMFAが強制されている可能性が高く、その結果としてAVDログオンに失敗している可能性があります。AVDの動作検証には、管理者ロールを持たない一般ユーザーアカウントを使うようにしてください。
Q. AVD側のホストプールやアプリグループ設定を何度見直しても原因が分かりません。
A. その場合、AVDの設定以前にEntra ID側のポリシーや接続元デバイス状態を疑うべきです。特に、条件付きアクセスで「すべてのクラウドアプリ」をMFA必須にしているケースや、テナント作成時からSecurity Defaultsが有効になっているケースでは、AVDだけを見ていても解決しないことが多くあります。この記事のチェックリストを上から順に確認し、Entra側とクライアント側の前提条件をまず整えてください。
Q. 一度つながったのに、後日突然つながらなくなりました。
A. そのタイミングで条件付きアクセスやSecurity Defaults、MFA設定、あるいはクライアントPCの状態（再イメージ、テナント登録変更など）に変更が入っていないか確認してください。AVDの構成を変えていなくても、Entra ID側のポリシー変更やクライアントの状態変化だけで挙動が変わることはよくあります。
まとめ：MFA／CAの除外とデバイス要件の適合が鍵
Azure Virtual DesktopのセッションホストにMicrosoft Entra IDユーザーでサインインできない場合、原因の多くは次の3つに集約されます。
- MFA・条件付きアクセス・セキュリティ既定による過剰な制限
- 接続元クライアントPCのEntra登録／参加状態の不備
- AVDアプリグループへのユーザー／グループ割り当て不足
特に、クラウドアプリ「Microsoft Azure Windows Virtual Machine Sign-in」をMFA必須ポリシーの対象にしてしまうと、AVDセッションホストへのログオンが成立せず、ユーザーからは「AVDにつながらない」としか見えません。まずはこのアプリをポリシーから除外しつつ、接続元PCの dsregcmd /status でEntra状態とTenantIdを確認することが重要です。
本記事で紹介したチェックリストとベストプラクティスを活用すれば、「ローカル管理者では入れるのにEntraユーザーでは入れない」というよくあるハマりポイントを効率よく解消し、安定したAzure Virtual Desktop環境を構築・運用できるはずです。
コメント