Azure Virtual Desktopでログオン失敗(Code: 10006)を解決する方法｜Virtual Machine User Login(RBAC)付与の手順

Azure Virtual Desktop（AVD）のセッションホストが「利用可能」なのに、接続すると「Logon Failed Code: 10006」で即切断される――この症状は、Entra ID（Azure AD）参加のセッションホスト特有の“権限不足”が原因で起きることがよくあります。本記事では、ハイブリッド環境でハマりやすいポイントと、最短で直す手順を具体的に整理します。

発生している問題の全体像（Code: 10006 の典型パターン）

今回のケースは、オンプレミス Active Directory（以下オンプレAD）と Entra ID のハイブリッド環境で、AVD の新しいセッションホストを構築したところ、ユーザーがログオンできないというものです。環境や切り分け状況は、現場でよく見る“やるべきことはやっているのに繋がらない”状態に一致します。

ユーザー：Microsoft 365 E3 あり
セッションホスト：Windows 11 Enterprise、Entra ID（Azure AD）参加
ホストプール：割り当て済み（アプリグループ経由の割り当ても完了している前提）
セッションホストのローカル「Remote Desktop Users」グループにも追加済み
セッションホストのヘルス状態は「利用可能」
イベントログに明確なエラーが出ない
Remote Desktop エージェント／ブートローダー再インストール済み
しかし Windows App（Web）や Bastion 経由でも「Disconnected: reason = 10006」「Logon Failed Code: 10006」

さらに、クラウド専用ユーザー（クラウドネイティブユーザー）に E3 を付与しても同じ、という点が重要です。つまり「オンプレAD同期が絡むからダメ」ではなく、もっと根本の“Azure 側のログオン権限”が不足している可能性が高い状況です。

Code: 10006 は「認証が通ったのに最後で拒否される」系のサイン

AVD の Code: 10006 は、ユーザー視点だと「ログオン失敗」の一言で片付けられてしまい、原因が追いにくいのが厄介です。ポイントは、次の構造で切り分けることです。

段階	何が起きているか	代表的な確認ポイント	不足するとどう見えるか
ライセンス	AVD を利用できる権利があるか	M365 E3/E5、Windows E3/E5 など	フィードに出ない／利用不可になることがある
AVD 側の割り当て	アプリグループ（デスクトップ/リモートアプリ）に割り当て済みか	アプリグループの「割り当て」	リソースが表示されない／接続に進めない
OS 側のローカル権限	RDP ログオン権限があるか	Remote Desktop Users、ローカルポリシー	資格情報入力後に拒否されることがある
Azure 側のログオン権限（RBAC）	Entra ID 認証で VM にサインインできる権限があるか	Virtual Machine User Login / Administrator Login	最終段で拒否され、Code: 10006 で切断されやすい

今回のように「セッションホストが正常」「ユーザー割り当て済み」「ローカルグループも設定済み」なのに、Web クライアントや Bastion でも同じエラーになる場合、Azure RBAC のログオン権限が不足している可能性が非常に濃厚です。

根本原因：Entra ID 参加のセッションホストは “Azure RBAC のログオン権限” が必要

結論から言うと、原因は Azure 側のロール（RBAC）で対象ユーザーに 「Virtual Machine User Login」ロール が割り当てられていなかったことです。

ここが最大の落とし穴です。AVD のセッションホストが Entra ID（Azure AD）参加の VM の場合、次の2つだけではログオンが成立しません。

AVD のアプリグループ（またはホストプール相当）へのユーザー割り当て
VM ローカルの「Remote Desktop Users」グループ所属

なぜなら、Entra ID 参加 VM へのサインインは “Windows のローカルだけ” で完結せず、Azure の RBAC で「その VM へログオンしてよい」権限が別途必要になるからです。権限が不足すると、表面上は認証が進んでいるように見えても、最後の許可判定で弾かれ、クライアント側には Code: 10006 として現れます。

そして、この現象がややこしい理由はここです。

Windows のイベントログに「これが原因です」と言い切れる記録が出ないことがある
AVD エージェントの再インストールなど“VM 側の整備”をしても改善しない
オンプレ同期ユーザーでもクラウド専用ユーザーでも、RBAC が無ければ同じように失敗する

解決策：Virtual Machine User Login ロールを付与する

対処はシンプルで、対象ユーザー（またはグループ）に「Virtual Machine User Login」ロールを割り当てるだけです。実務では、個々のユーザーに直接付与するより、グループ運用に寄せると管理が楽で安全です。

Azure ポータルで付与する手順（最も確実）

Azure ポータルにサインイン
対象の AVD セッションホスト VM を開く（複数台構成なら VM を含むリソースグループで作業するのが運用向き）
左メニューから 「アクセス制御（IAM）」 を開く
「追加」→「ロールの割り当てを追加」 をクリック
ロール一覧から 「Virtual Machine User Login」 を選択
対象の ユーザーまたはグループ を選択して保存
数分待ってから再接続（トークンの都合で、Windows App を完全終了→再起動すると切り分けが早い）

このロールが付与されると、Code: 10006 で切断されていたログオンが正常に通るようになります。

付与スコープ	メリット	デメリット	おすすめ度
VM 単体	最小範囲で安全	台数が増えると管理が破綻しやすい／新規VMに都度付与が必要	小規模・検証向き
リソースグループ	対象RG配下のVMをまとめて管理できる／増減に強い	RG内の他VMにも適用される（RG設計が重要）	本番運用で最有力
サブスクリプション	付け忘れが起きにくい	範囲が広すぎて過剰権限になりがち	原則非推奨

グループで付与する運用が強い（推奨）

ユーザーに直接付与すると、退職・異動・一時利用などの管理が複雑になります。次のようにグループで設計すると、セキュリティと運用効率のバランスが取りやすくなります。

グループ例：AVD-SessionHost-VM-Login-Users
上記グループに「Virtual Machine User Login」をリソースグループスコープで付与
AVD のアプリグループ割り当ても、可能なら同じグループで実施

こうすると「AVD の割り当てはあるのに VM へ入れない」「VM へ入れるが AVD が出ない」といった“権限のねじれ”を減らせます。

補足：一般ユーザーと管理者で付与すべきロールが違う

ロールには似た名前が2つあるため、取り違えが起きがちです。原則として、利用者には User、運用者には Administrator を割り当てます（必要最小限が基本です）。

用途	付与するロール	想定ユーザー	注意点
日常利用（通常のVDI利用）	Virtual Machine User Login	一般ユーザー	基本これで十分。過剰に Administrator を配らない
運用・トラブルシュート（管理者ログオン）	Virtual Machine Administrator Login	運用担当、管理者	強い権限。付与範囲と期間（必要なら一時付与）を絞る

なぜ「Remote Desktop Users に入れてもダメ」なのか

オンプレAD参加（従来型）だと、「Remote Desktop Users に入れる」「RDP のユーザー権利を満たす」ことで、RDP ログオンは成立しやすいです。しかし、Entra ID 参加 VM はログオン経路が異なります。

ざっくり言うと、Entra ID 参加 VM では次の2段構えになります。

Windows 側：そのユーザーが対話ログオン／リモート対話ログオンできるか（ローカルの権限・ポリシー）
Azure 側：そのユーザーに VM へのログオンを許可するか（RBAC のログオンロール）

今回の症状は、このうち Azure 側の許可（RBAC）が不足しているために起きます。つまり、ローカルグループに入れても “Azure が許可していない” ので最後で落ちます。

現場でよくある「ハマりポイント」と対策

ロール付与後、すぐに直らないように見える

RBAC の反映にはタイムラグがあります。また、クライアントが古いトークンを握っていると、反映後もしばらく失敗が続くように見えることがあります。

数分待つ（短時間で何度も試すより、少し間隔を空ける）
Windows App（デスクトップ/モバイル）を完全終了して再起動
Web クライアントの場合はサインアウト→サインインし直す

どの範囲にロールを付与すべきか迷う

おすすめは「セッションホスト用のリソースグループ」を用意し、そのリソースグループに対してグループへ付与です。イメージ更新やホスト追加にも追従しやすく、付与漏れが減ります。

AVD 側の割り当てと RBAC を別々に管理してしまい、ズレる

実務ではここが一番多いです。AVD の割り当てと RBAC を別担当・別申請にすると、どちらかだけ実施されて「繋がらない」が発生します。可能なら、同じ Entra ID グループを両方に使う運用へ寄せると、問い合わせが激減します。

チェックリスト：Code 10006 が出たときに最短で潰す順番

原因が RBAC であることが多いとはいえ、焦って闇雲に設定をいじると、別の不具合を作ってしまいます。次の順番で“確認→是正→再試験”を回すのが効率的です。

優先度	チェック内容	確認場所	OKの目安
高	対象ユーザーはアプリグループに割り当て済みか	AVD のアプリグループ → 割り当て	ユーザー/グループが表示される
高	セッションホストが Entra ID 参加であることを把握しているか	セッションホストの参加状態（OS情報）	Entra ID 参加（Azure AD Joined）
最重要	Virtual Machine User Login ロールが付与されているか	VM もしくは RG の IAM（アクセス制御）	ユーザー/グループにロール割り当てあり
中	ローカルの Remote Desktop Users に含まれているか	セッションホストのローカルユーザーとグループ	ユーザー/グループが所属
中	管理者で入れるか（運用者のみ）	RBAC: Virtual Machine Administrator Login	管理者はログオンできる
低〜中	クライアントの再認証（トークン更新）を試したか	Windows App / Web クライアント	再ログイン後に挙動が変わる

PowerShell / Azure CLI での確認・付与（運用・自動化向け）

ポータル操作が一番確実ですが、台数が多い・運用で再現する・IaC（Infrastructure as Code）で統制する場合は、コマンドでの確認が役に立ちます。ここでは“考え方”が伝わる範囲で例を載せます（実行環境や権限により調整してください）。

Azure CLI 例：ロール割り当ての作成（概念例）

az role assignment create \
  --assignee &lt;ユーザーまたはグループのオブジェクトID&gt; \
  --role "Virtual Machine User Login" \
  --scope /subscriptions/&lt;SUBSCRIPTION_ID&gt;/resourceGroups/&lt;RG_NAME&gt;

Azure CLI 例：割り当て確認（概念例）

az role assignment list \
  --assignee &lt;ユーザーまたはグループのオブジェクトID&gt; \
  --all \
  --query "[?roleDefinitionName=='Virtual Machine User Login']"

ポイントは、AVD のリソース（ホストプール等）に対するロールではなく、VM（または VM を含むスコープ）に対するログオンロールである点です。ここを取り違えると、AVD 側の閲覧・管理権限だけが増えて、肝心のログオンが直りません。

ロールを付与しても直らない場合の追加確認（“次の一手”）

多くは RBAC で解消しますが、環境によっては追加の前提条件が絡むことがあります。以下は “RBAC は付いたのに同じエラーが続く” ときの確認観点です。該当しそうなものから順に見てください。

セッションホストが意図した参加状態か（作り直し時の取り違え）

想定：Entra ID 参加として構築したつもりが、実は別の参加形態になっている
対策：セッションホストの参加状態を再確認し、設計（Entra ID 参加／AD DS 参加）と一致させる

ユーザー割り当ての単位が「ホストプール」ではなく「アプリグループ」になっているか

AVD は基本的に、ユーザーをアプリグループへ割り当てます。現場では「ホストプールに割り当てたつもり」が、実は割り当て先が違った、というミスが起きがちです。リソースが見えているのに接続で落ちる場合は RBAC が本命ですが、そもそも割り当てがズレていないかも併せて確認すると手戻りが減ります。

ローカルポリシーやセキュリティ設定で RDP ログオンが拒否されていないか

「リモートデスクトップサービスによるログオンを許可」系のポリシー
セキュリティベースラインやGPO/Intuneの設定で、ユーザーのリモート対話ログオンが制限されていないか

“管理者は入れるがユーザーは入れない” 場合

この場合、RBAC が管理者だけに付いているか、ローカル権限（Remote Desktop Users など）がユーザーに付いていない可能性が高いです。次の組み合わせを疑うと整理しやすいです。

管理者ログオン	一般ユーザーログオン	ありがちな原因	対処方針
成功	失敗（10006）	一般ユーザーに Virtual Machine User Login が付いていない	ユーザー/グループへ User ロール付与
成功	失敗（別エラー）	ローカル RDP 権限不足、ポリシー制限	Remote Desktop Users、ポリシーを確認

セキュリティと運用のベストプラクティス（再発防止）

AVD は「繋がるようにする」だけで終わらず、「繋がり続ける」「権限が暴れない」設計が重要です。Code 10006 を一度踏んだ環境ほど、次の設計が効きます。

最小権限で配る

一般ユーザーには Virtual Machine User Login のみ
管理者は必要な範囲・期間だけ Virtual Machine Administrator Login

グループ運用に寄せる

AVD 割り当て（アプリグループ）と RBAC（VMログオン）を同じグループで管理
人の増減はグループ所属の追加/削除だけに寄せる

スコープ設計（リソースグループ分離）

セッションホスト用のリソースグループを分ける
その RG に対してログオンロールを付与する（意図せず他VMへ波及しない）

変更作業の“抜け”をなくす（運用手順に組み込む）

新規ホスト追加・イメージ更新・再デプロイの作業手順に、次をチェック項目として入れておくと、同じ事故を繰り返しにくくなります。

RG スコープに Virtual Machine User Login が付与されていること
アプリグループ割り当ての対象がグループ運用になっていること
ローカルグループ/ポリシーの標準が定義されていること（Intune/GPO）

まとめ：Code 10006 で疑うべき“最初の一手”は RBAC

AVD のセッションホストが Entra ID 参加の場合、AVD 側の割り当てやローカルの Remote Desktop Users だけではログオンが成立しません。Azure RBAC の「Virtual Machine User Login」ロールが付与されていないと、認証が進んだように見えても最後に拒否され、クライアントは Code: 10006 として切断します。

同様の症状が出たら、まずは VM（または VM を含むリソースグループ）の IAM で、対象ユーザー（できればグループ）に Virtual Machine User Login が付いているかを確認してください。ここを押さえるだけで、遠回りな再インストールや無関係な設定変更を避け、最短で復旧できます。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Azure Virtual Desktopでログオン失敗(Code: 10006)を解決する方法｜Virtual Machine User Login(RBAC)付与の手順

発生している問題の全体像（Code: 10006 の典型パターン）

Code: 10006 は「認証が通ったのに最後で拒否される」系のサイン

根本原因：Entra ID 参加のセッションホストは “Azure RBAC のログオン権限” が必要