Azure VM に Microsoft Entra ID（旧 Azure AD）でサインインしようとしても、拡張機能も状態も問題なさそうなのに RDP が通らない――そんな事象は、MFA や条件付きアクセス、RBAC 設定など複数要素が絡むため原因が見えづらくなりがちです。本記事では Windows 11 VM で CloudAP や SID エラーが出るケースを例に、どこから調べてどう直すかを実務目線で整理します。
前提シナリオの整理
まず、本記事で想定する典型的なトラブルシナリオを整理します。
- Azure 上の Windows 11 VM
- AADLoginForWindows 2.2.0（現：Microsoft Entra ログイン拡張機能）が「成功」「稼働中」
- VM 上で
dsregcmd /status→AzureAdJoined : YES（Entra 参加済み） - Azure ポータルで VM の「Microsoft Entra ID」タブを見ると、Virtual Machine Administrator Login = 有効
- しかし、RDP で Entra ID ユーザーの UPN（[email protected]）を入力してもサインイン不可
- イベントログにはローカル グループへ SID を追加しようとした形跡があるが、「SID が見つからない」系のエラー
- Microsoft Entra のサインインログには何も記録されない
- VM 再作成やログイン拡張の再インストールでも改善せず
このパターンでは、CloudAP 自体よりもMFA／条件付きアクセス／RBAC／接続元クライアントのいずれか（または複数）がボトルネックになっていることがほとんどです。
まず理解しておきたい仕組み：Entra ログイン拡張機能と CloudAP
トラブルシュートを始める前に、「何が何をしているのか」をざっくり押さえておくと原因の当たりがつけやすくなります。
Microsoft Entra ログイン拡張機能の役割
Windows VM にインストールする「Microsoft Entra ログイン拡張機能」（旧 AADLoginForWindows）は、ざっくり言うと次のような役割を担います。
- VM を Microsoft Entra ID にデバイスとして登録／参加させる
- ローカル グループ「AzureAD\Virtual Machine Users」「AzureAD\Virtual Machine Administrators」と、
Azure 側の RBAC ロール（Virtual Machine User/Admin Login）をひも付ける - RDP サインイン時に Entra ID での認証が走るよう、Windows 側のログオンプロバイダーを有効化する
一方で、CloudAP（Cloud Authentication Provider）は Windows に組み込みの機能であり、この拡張機能が何かを「追加インストール」しているわけではありません。CloudAP が「見えない」「登録されていない」のでは？と心配になりがちですが、多くのケースでは CloudAP ではなく上流の認証条件や RBAC の問題です。
SID 解決エラーが意味していること
Entra ログインで VM に接続する際、Azure 側でユーザーに「Virtual Machine Administrator Login」などの RBAC ロールが付与されていると、Windows はそのユーザーをローカル グループに追加しようとして内部的に SID を解決します。ここでうまくいかないと、イベントログに次のようなイメージのメッセージが出ます。
- 「SID <…> を名前に解決できませんでした」
- 「ローカル グループへの追加に失敗しました」
このとき、SID 解決に失敗している＝Entra 側と VM 側でユーザー／ロール情報が正しくひも付いていない可能性が高いと考えます。原因として多いのは、後述する RBAC 不足や MFA／条件付きアクセスによるブロックです。
原因になりやすい 4 つの領域
Entra ID で Azure VM ログインができないとき、多くのケースは次の 4 つのどれか（または複合）に分類できます。
| 領域 | 典型的な問題 | 影響 |
|---|---|---|
| MFA／条件付きアクセス | VM サインインに対して MFA を必須にしてしまっている | RDP での対話型 MFA ができないため、クラウドに到達する前に失敗 |
| 接続元クライアント | クライアントが Entra 未登録、OS バージョン不足 | Entra ログイン前提の RDP 要件を満たせず、ログイン画面まで行かない |
| RBAC（ロール割り当て） | ユーザー／グループに VM ログイン用のロールが付いていない | SID 解決エラー、ローカル グループにユーザーが反映されない |
| デバイス／トークン状態 | dsregcmd での参加状態の不整合、PRT 期限切れ等 | CloudAP がトークンを取得できず、Entra への認証要求が出ない |
以降では、この 4 領域を順番に確認していく形で、具体的な対処方法を整理します。
MFA／条件付きアクセスの影響を除外する
実務で最も遭遇しやすいのが、このパターンです。
なぜ VM 直接サインインと MFA は相性が悪いのか
RDP で Azure VM に直接サインインする場合、ブラウザーやスマホ認証のような「インタラクティブな MFA フロー」を挟む余地がありません。そのため、Microsoft 公式ドキュメントや Q&A でも、VM ログインそのものに対して MFA を必須にする構成はサポートされず、結果としてサインイン失敗扱いになると案内されています。
チェックポイント 1：ユーザー単位 MFA の状態
古典的な「ユーザー単位 MFA」が有効／強制になっていると、そのユーザーが VM に対しても MFA を求められ、結果としてサインインできなくなります。
- Microsoft 365 管理センター → ユーザー → 多要素認証
- 対象ユーザーが 「有効」「強制」 になっていないか確認
- VM サインインを検証するときは、一時的に 「無効」 にしてから試す
本番運用では、VM ログイン専用のテストユーザーを作り、そのアカウントに対してのみ MFA を無効化するほうが安全です。
チェックポイント 2：条件付きアクセスの対象アプリ
条件付きアクセスで「すべてのクラウドアプリに対して MFA 必須」としている場合、「Microsoft Azure Windows Virtual Machine Sign-in」（テナントによっては「Azure Windows VM Sign-in」）アプリにも MFA が要求されることになります。
このアプリは VM への Entra ログイン専用のサービス プリンシパルで、アプリ ID は 372140e0-b3b7-4226-8ef9-d57986796201 です。条件付きアクセスでこのアプリに対して MFA を課すと、RDP セッション内での MFA プロンプトが成立せずサインインそのものが失敗します。
公式ドキュメントでは、Windows Hello for Business を利用していない環境では、このアプリを条件付きアクセスから「除外」することが推奨されています。
設定イメージは次の通りです。
- Entra 管理センター → 保護 → 条件付きアクセス → 該当ポリシー
- 「対象のリソース（クラウドアプリ）」で 「すべてのクラウドアプリ」などを指定している場合
- 「除外」タブで 「Microsoft Azure Windows Virtual Machine Sign-in」（または「Azure Windows VM Sign-in」）を検索して追加
チェックポイント 3：セキュリティの既定値（Security Defaults）
テナントで「セキュリティの既定値」が有効な場合、全体管理者（Global Administrator）など一部ロールには常に MFA が必須になります。
このとき、たとえユーザー単位 MFA を無効にしても、役割によっては VM 直接サインインができません。対策としては次のようなパターンがあります。
- VM サインイン用に非管理者アカウントを用意し、Global Admin ロールを持たないユーザーで接続する
- どうしても管理者アカウントで入りたい場合は、例外用の条件付きアクセス ポリシーで同アカウントを除外する（推奨度は低め）
検証時におすすめの最小構成
まずはシンプルに「MFA/CA の影響がない状態」で動作確認するのが近道です。
| 設定項目 | 検証用の推奨値 |
|---|---|
| ユーザー単位 MFA | 対象ユーザーのみ 無効 |
| 条件付きアクセス | VM サインイン アプリを 除外、または CA 自体を一時的に無効 |
| セキュリティの既定値 | 検証テナントでは 無効 が無難 |
この状態で Entra ログインが成功することを確認したうえで、必要なセキュリティ要件を 1 つずつ足していくと、どこで問題が起きるかが把握しやすくなります。
接続元クライアントの要件を満たしているか
次に見落とされがちなのが、「RDP を実行する側」の条件です。公式ドキュメントでは、以下が最低条件として案内されています。
- クライアント OS：Windows 10 20H1 以降、または Windows 11
- クライアントが同じテナントで Entra 参加／ハイブリッド参加／Entra 登録のいずれかになっている
クライアントがワークグループ端末のままだったり、別テナントに参加していたりすると、Entra ログイン前提の RDP フローが成立しません。
クライアントが Entra 参加しているか確認する
クライアント PC 側では、次の画面から確認できます。
- 設定 → アカウント → 「職場または学校にアクセスする」
- 「接続済み」の欄に組織アカウントが表示されているか
- 詳細から 「Azure AD に参加」もしくは 「Azure AD に登録」になっているか
ここが未設定の場合、まずはクライアントをテナントに登録／参加させてから再度 RDP を試します。
RDP のユーザー名と .rdp ファイルのポイント
RDP 接続時のユーザー名は以下の形式を推奨します。
- 第一候補：
[email protected]（UPN 形式） - うまくいかない場合：
AzureAD\[email protected]またはAzureAD\[email protected]
また、Azure ポータルから「接続」→「RDP ファイルのダウンロード」で取得した .rdp を使うと、自動的に enablerdsaadauth:i:1 等の設定が含まれており、Entra ログイン前提の RDP 設定になります。自前で mstsc の設定を作るより、この .rdp を利用したほうがトラブルを減らせます。
RBAC：Virtual Machine Login ロールを必ず確認する
「Entra ログインを有効化したから、もうユーザーは入れるはず」と思いがちですが、実は 拡張機能の有効化と RBAC ロールの割り当ては別作業です。
必要なロールと違い
Azure VM に Entra ID でログインする場合、ユーザー（またはグループ）に次のいずれかのロールを付与する必要があります。
| ロール名 | 権限のレベル | 用途 |
|---|---|---|
| Virtual Machine User Login | 標準ユーザー権限 | アプリ実行・設定変更が少ない一般ユーザー向け |
| Virtual Machine Administrator Login | ローカル管理者権限 | サーバー管理・ソフトウェアインストール等を行う管理者向け |
これらのロールは、VM 単体／リソースグループ／サブスクリプションなど任意のスコープで割り当て可能です。ロールが付いていないユーザーは、拡張機能が有効になっていても VM にログインできません。
ロール割り当ての確認方法
- Azure ポータルで対象 VM を開く
- 「アクセス制御 (IAM)」 → 「アクセスの確認」
- 対象ユーザー（またはグループ）を検索し、
Virtual Machine User Login / Administrator Login のいずれかが表示されるか確認
ここに何も表示されない場合は、該当ロールを割り当ててから数分待ち、再度 RDP を試します。ロールを付けた直後は、トークンやグループ情報が更新されるまでにタイムラグがあるため、後述のとおり VM とクライアント側でサインアウト／再起動を行うとなお確実です。
CloudAP とデバイス状態の確認
ここまでの時点で、MFA／CA／クライアント／RBAC を見直してもまだダメな場合、ようやく CloudAP やデバイス登録の状態を疑います。
dsregcmd /status で VM の参加状態を確認する
VM 上で管理者権限の PowerShell またはコマンドプロンプトを開き、次を実行します。
dsregcmd /status
確認したい主な項目は次のとおりです。
| 項目 | 期待値 |
|---|---|
| AzureAdJoined | YES |
| TenantName / TenantId | 想定しているテナントになっている |
| DeviceId | 空ではなく GUID が表示されている |
ここで AzureAdJoined が NO になっている場合、そもそも拡張機能による Entra 参加が完了していないため、まずは拡張機能の状態や VM 再起動、ネットワーク到達性（インターネット／Entra エンドポイント）を確認します。
CloudAP／User Device Registration のイベントログを見る
トラブルが深刻な場合は、次のイベントログも併せて確認します。
アプリケーションとサービス ログ > Microsoft > Windows > User Device Registration > Admin / Operationalアプリケーションとサービス ログ > Microsoft > Windows > CloudAP > Operational
ここにネットワーク到達性や証明書、トークン周りのエラーが出ている場合は、それを手掛かりにさらに深掘りします。たとえばプロキシ制限で Entra への通信がブロックされていると、CloudAP がトークンを取得できず、Entra サインインログにも何も出ない、といった状態になります。
チェックリスト：どこから確認すべきか
ここまでの内容を、実際の切り分け順に並べたチェックリストとしてまとめます。
| ステップ | 確認内容 | 確認場所 | OK となる状態 |
|---|---|---|---|
| 1 | VM の Entra 参加 | VM 上で dsregcmd /status | AzureAdJoined : YES |
| 2 | ログイン拡張機能の状態 | Azure ポータル → VM → 拡張機能 | AADLoginForWindows（Entra ログイン）が「成功」「稼働中」 |
| 3 | RBAC ロール | VM / RG / サブスクリプション → 「アクセス制御 (IAM)」 | 対象ユーザー（またはグループ）に「Virtual Machine (User/Admin) Login」が付与されている |
| 4 | ユーザー単位 MFA | Microsoft 365 管理センター → 多要素認証 | 検証ユーザーは「無効」 |
| 5 | 条件付きアクセス | Entra 管理センター → 保護 → 条件付きアクセス | 「Microsoft Azure Windows Virtual Machine Sign-in」アプリが除外されている |
| 6 | セキュリティの既定値 | Entra 管理センター → プロパティ | 必要に応じて無効／管理者ロールを持たないアカウントで検証 |
| 7 | クライアントの状態 | クライアント PC → 設定 → アカウント | Windows 10/11 かつ Entra 参加／登録済み |
| 8 | RDP 設定 | Azure ポータルから RDP ファイルをダウンロード | ユーザー名が UPN、enablerdsaadauth:i:1 が含まれる .rdp を使用 |
| 9 | イベントログ | CloudAP / User Device Registration ログ | 重大／エラーが出ていない、もしくは内容に応じて対処 |
実際の復旧シナリオ例（ステップバイステップ）
冒頭のように「SID 解決エラー」「Entra サインインログに何も出ない」状態から、最終的にログインできるようになるまでの具体的なフロー例を示します。
ステップ 1：MFA／条件付きアクセスを一時的に緩める
- 検証用ユーザー（VM ログイン用）を 1 つ決める
- そのユーザーのユーザー単位 MFA を 無効 にする
- 条件付きアクセスのうち、すべてのクラウドアプリに MFA を要求しているポリシーを特定
- そのポリシーの「除外」で Microsoft Azure Windows Virtual Machine Sign-in を追加
- 必要に応じて、テナントのセキュリティ既定値を一時的に無効にする、もしくは非管理者アカウントで検証
ステップ 2：RBAC ロールを明示的に付与する
- Azure ポータルで VM を開く
- 「アクセス制御 (IAM)」 → 「ロールの割り当ての追加」
- Virtual Machine Administrator Login（または User Login）を選択
- ステップ 1 で決めた検証ユーザーを割り当てる
ステップ 3：クライアントを整える
- 検証に使うクライアント PC を Windows 10/11 にする
- 設定 → アカウント → 「職場または学校にアクセスする」で、VM と同じテナントのアカウントで Entra 登録／参加する
- Azure ポータルから VM の RDP ファイルをダウンロード
- .rdp ファイルのユーザー名を UPN（[email protected]） に変更
ステップ 4：トークン／グループ情報を更新する
- VM を再起動、または再ログオンして Entra 参加状態を最新化
- クライアント PC も再起動し、PRT（Primary Refresh Token）とグループ情報を更新
ステップ 5：再度 RDP を実行し、サインインログを確認
- .rdp ファイルから接続し、ユーザー名に
[email protected]を入力 - パスワード入力後、サインインに成功するか確認
- Entra 管理センター → 「サインインログ」で、アプリ名が「Microsoft Azure Windows Virtual Machine Sign-in」のエントリが記録されているか確認
ここまででログインに成功し、サインインログにも記録が出るようになれば、MFA／CA／RBAC／クライアントの前提条件は概ね整ったと判断できます。以降はポリシーを少しずつ強化しながら、どの設定まで許容できるかを検証していきます。
「Entra サインインログに何も出ない」ケースの考え方
今回のシナリオのように、Entra サインインログが完全に空のままという場合、次のように考えると切り分けしやすくなります。
- クライアント／VM 側でブロックされている（CloudAP まで到達していない）
- MFA／CA による事前ブロックで、Entra 側での「試行」すら発生していない
- デバイス登録状態の破損により、トークンが取得できない
Entra 管理センターの「サインイン診断」機能を使うと、ユーザーやアプリ単位でサインインイベントを絞り込み、どこでブロックされているかを可視化できます。
よくある落とし穴とベストプラクティス
落とし穴 1：「Entra ログイン有効化＝すぐログインできる」と思い込む
VM の「Microsoft Entra ログイン」を有効化すると、それだけでログイン可能だと勘違いしがちですが、実際には次の 3 点が揃って初めてログイン可能になります。
- Entra ログイン拡張機能が正常に稼働
- 接続元クライアントが Entra 参加／登録済み
- ユーザー（またはグループ）に Virtual Machine (User/Admin) Login ロールが付与
このうちどれか 1 つでも欠けると、SID 解決エラーやログオン失敗に繋がります。
落とし穴 2：管理者アカウントでしか試さない
テナント管理者は Global Administrator ロールを持つことが多く、Security Defaults や条件付きアクセスにより常時 MFA が必須になっているケースがほとんどです。そのため、管理者アカウントでの VM 直接サインインは、設計上うまくいかないシナリオが多くなります。
検証時は必ず、
- 管理者ロールを持たない一般ユーザー
- VM ログイン専用のテストアカウント
を用意して試すことをおすすめします。
落とし穴 3：別テナントのアカウント／クライアントを混在させる
テスト環境と本番環境を行き来しているうちに、「クライアントは本番テナントに参加」「VM は検証用テナント」など、テナントが食い違う構成になっていることも珍しくありません。
Entra ログインでは、
- VM が所属するテナント
- Entra 参加しているクライアントのテナント
- ログインに使うユーザー アカウントのテナント
が同じであることが前提となります。ここが食い違うと、そもそもトークンの取得ができません。
まとめ
Entra ID（Azure AD）で Azure の Windows 11 VM にサインインできない場合、つい CloudAP 自体の問題に見えてしまいますが、実際には次の 4 点を順に確認していくと多くのケースを解決できます。
- MFA／条件付きアクセス：VM サインイン アプリに対して MFA を必須にしていないか、ユーザー単位 MFA が有効になっていないか
- 接続元クライアント：Windows 10/11 かつ同テナントに Entra 参加／登録しているか
- RBAC（Virtual Machine (User/Admin) Login）：ユーザーまたはグループにロールが付与されているか
- デバイス／CloudAP 状態：
dsregcmd /statusや CloudAP イベントログに異常がないか
「SID 解決エラーが出る」「Entra サインインログに何も表示されない」といった事象は、これらの前提条件が崩れているサインであることがほとんどです。本記事のチェックリストと手順をそのままなぞっていけば、どこでブロックされているかを段階的に切り分け、最終的には安定して Entra ログインできる構成に持っていけるはずです。
コメント