Azure Virtual Desktop（AVD）を本番運用し始めると、「社内からはつながるのに、外部の PC からだけ Entra ID 認証が通らない」「Azure ポータルの接続状態が Pending のまま動かない」といったトラブルに遭遇しがちです。この記事では、実際の現場で発生した「Windows アプリ（AVD クライアント）から外部端末で接続すると The credentials did not work が出る」事例をベースに、原因の整理と再発防止までを詳しく解説します。
障害の概要：外部端末からの AVD 接続で Entra ID 認証が失敗
まずは今回の典型的な症状を整理します。どこかで見覚えがあれば、かなり高い確率で同系統の問題です。
- 利用形態：Azure Virtual Desktop（AVD）
- クライアント：Windows 用 AVD クライアント（Remote Desktop）
- ユーザー：Entra ID（旧 Azure AD）アカウント
現象としては次のような状態です。
| 項目 | 状態 |
|---|---|
| 外部端末から AVD へ接続 | 資格情報入力後に The credentials … did not work が表示され、サインイン不可 |
| Azure ポータルの接続状態 | 対象セッションホストがずっと Pending のまま変化しない |
| セッションホスト上からの RDP | ローカルユーザーでログオン済みであれば、同ホスト/別ホストへ Entra ID ユーザーで RDP 可能 |
| ネットワーク | VNet ピアリングを追加しており、AAD DS（Azure AD Domain Services）の DC への疎通は可能に見える |
つまり、「内部からの RDP はうまくいくのに、外部の AVD クライアントからだけ Entra ID 認証が失敗する」という、非常にやっかいな状態です。
結論：DNS・ドメイン参加・VNet ピアリングの不備が主因
この事例での根本原因は、次の条件が同時に満たされていなかったことです。
- セッションホストが AAD DS（Azure AD Domain Services）のドメインに参加していなかった
- セッションホストの NIC が AAD DS の管理 IP を DNS として参照していなかった
- AAD DS が存在する VNet とセッションホストの VNet が分離され、ピアリングが不十分でドメイン関連の通信が取りこぼされていた
最終的に実施した対処は次の通りです。
- AAD DS 側 VNet とセッションホスト側 VNet の VNet ピアリングを正しく構成（双方向のトラフィック許可）
- セッションホスト NIC の DNS サーバーを AAD DS 管理 IP（2 つ）に設定変更
- セッションホストを AAD DS（マネージドドメイン）にドメイン参加し、セキュアチャネルを正常化
- 既存プールのホストは一時的に Drain モードにして、新規ホストから順番に再構成して切り替え
これにより、Windows アプリから外部端末でも Entra ID ユーザーで正常に接続できる状態に復旧しました。
AVD の参加方式をまず整理する：AAD DS か Entra ID か
AVD のトラブルシュートでは、「セッションホストがどこに参加しているか」を最初に確認するのが鉄則です。大きく次の 2 パターンが存在し、それぞれ前提条件がまったく違います。
| 方式 | 概要 | セッションホスト側の要件 | クライアント側の要件 |
|---|---|---|---|
| AAD DS ドメイン参加型 | AVD のセッションホストを、Azure AD Domain Services（AAD DS）のマネージドドメインに参加させる方式 | ホストは AAD DS ドメインに参加していること ホストの DNS が AAD DS の管理 IP を指していること AAD DS へのポート（Kerberos/LDAP/DNS など）が VNet/NSG で許可されていること | クライアントのドメイン参加は必須ではない AVD クライアントで Entra ID サインイン可能であればよい |
| Entra ID 参加（Entra ID Join）型 | セッションホスト自体を Entra ID 参加させる方式（Azure AD Join） | ホスト OS が Entra ID に参加していること 必要に応じて Intune 管理や条件付きアクセス（CA）と連携 | クライアントも同一テナントに Entra 参加 / ハイブリッド参加が推奨 条件付きアクセス（MFA/デバイス準拠性）などの影響を強く受ける |
今回のケースは前者の AAD DS ドメイン参加型であり、DNS とドメイン参加、VNet ピアリングという基本要件が満たせていなかったために、外部からの資格情報がドメインで最終確認できず、credentials did not work と表示されていました。
なぜ「内部からの RDP は成功するのに、外部だけ失敗」するのか
この手のトラブルがややこしいのは、「セッションホストから別ホストへの RDP は成功する」など、一見するとドメイン認証が動いているように見える点です。ここでは動作のイメージを簡単に押さえましょう。
外部の AVD クライアントから接続するときの流れ（イメージ）
- ユーザーがクライアントで Entra ID 資格情報を入力して AVD に接続
- AVD のブローカー / 接続インフラが、ユーザーの割り当てやホストの状態を確認
- 最終的に、セッションホスト上では ドメインアカウントとしてログオン処理（Kerberos/NTLM）が行われる
この 3 のタイミングで、セッションホストが正しくドメインに参加しておらず、DNS も AAD DS を見に行っていないと、ユーザー情報やパスワードの確認ができず、見かけ上は Entra ID ログインに失敗したように見える、というわけです。
一方で、セッションホスト上でローカルユーザーとしてログオンし、その状態から別ホストへ RDP するときには、たまたまドメインコントローラーに到達できてしまう経路が存在したり、キャッシュ情報が効いていたりするケースがあります。このため、
- 「内部からは成功」＝「構成が正しい」
とは言えません。外部クライアントからの AVD 接続は、AVD ブローカー経由でのドメイン認証が最終成功しているか、という視点で切り分ける必要があります。
典型的な原因と対処パターン
似たような障害でよく登場する原因と対処を一覧にまとめます。トラブルシュートの「当たり」を付ける際に便利です。
| 症状・状況 | よくある原因 | 確認 / 対処 |
|---|---|---|
ポータルで接続が「Pending」、クライアントに credentials did not work | セッションホストが AAD DS にドメイン参加していない DNS が AAD DS 管理 IP になっていない | sysdm.cpl や systeminfo でドメイン参加状態を確認 NIC の DNS を AAD DS 管理 IP に変更後、ドメイン参加し直し nltest /sc_verify:<ドメイン名> でセキュアチャネル確認 |
| 内部（ホスト上）からは Entra ID で RDP できるが、外部端末からは不可 | ホスト → AAD DS はギリギリ疎通できるが、ブローカー経路でのドメイン検証が不完全 VNet ピアリングや NSG で必要なポートが部分的に閉じている | VNet ピアリング / NSG / UDR を見直し AAD DS への Kerberos/LDAP/SMB/DNS など、必要ポートを 双方向に許可 |
| 新規ユーザーだけドメイン認証できない | AAD DS 用の パスワードハッシュが生成されていない | AAD DS 有効化後にユーザーがパスワード変更しているか確認 未変更ならパスワード変更を案内（反映までタイムラグに注意） |
| 一部ユーザーだけサインインそのものが弾かれる | AVD 利用に必要な Windows / AVD ライセンス未割り当て Desktop アプリグループ未割り当て ゲストユーザーの要件未充足 | 対象ユーザーに必要なライセンスと Desktop アプリグループを割り当て ゲストユーザーの場合はサポートされる構成か見直し |
| 外部端末からだけ失敗する | クライアント側の Entra 参加状態がバラバラ 条件付きアクセス（CA）や MFA によるブロック | クライアントで dsregcmd /status を実行し、AzureAdJoined などを確認 Entra ID のサインインログで CA によるブロック要因（場所/デバイス準拠性/MFA など）を確認 |
| 断続的に失敗する（時間帯によって違うなど） | 時刻ずれ（NTP が不適切） DNS 解決不良、フォワーダーの問題 | ホストと DC の NTP/時刻同期を整備 DNS フォワーダーやゾーンの解決を確認 セキュリティログのサブステータス（エラーコード）を突合 |
チェックリスト：再発防止のために押さえておきたいポイント
ここからは、実際に現場で使える形でチェック項目を並べていきます。そのまま手順書として流用できるレベルでまとめています。
セッションホスト側のチェック
- DNS 設定
ipconfig /allで NIC の DNS サーバーを確認- DNS が AAD DS 管理 IP（2 つ）になっていること
- ドメイン参加状態
systeminfoのDomain:が期待するドメイン名になっているかsysdm.cplからもコンピューター名/ドメインを確認
- セキュアチャネル
nltest /sc_verify:yourdomain.comTest-ComputerSecureChannel -Verbose- いずれも成功すること（失敗時はドメイン再参加を検討）
- イベントログの確認
- ログオン失敗は Security 4625 を確認（サブステータスが重要）
- TerminalServices-LocalSessionManager と AAD DS 関連ログも併せて確認
| 代表的なサブステータス | 意味 |
|---|---|
0xC000018B | 時刻ずれ（Kerberos チケットが無効） |
0xC000006A | パスワード不一致 |
0xC0000064 | ユーザー名不明 |
0xC000005E | ログオン サーバーが利用できない（DC に到達できていない可能性） |
ネットワーク・VNet 周りのチェック
- VNet ピアリング
- AAD DS が存在する VNet と、AVD セッションホストの VNet が 双方向ピアリングされているか
- 「仮想ネットワークのアクセスを許可」「リモート ゲートウェイを使用」等の設定が要件を満たしているか
- NSG / Firewall
- AAD DS への Kerberos（TCP/UDP 88）、LDAP（389/636）、SMB（445）、DNS（53）などを許可
- アウトバウンド/インバウンド両方のルールを確認
- UDR（ユーザー定義ルート）
- トラフィックが予期せぬ NVA や FW を経由してブロックされていないか
- オンプレとの VPN / ExpressRoute を併用している場合の経路も確認
クライアント端末側のチェック（必要に応じて）
- Entra ID 参加状態
- クライアントで
dsregcmd /statusを実行 - AzureAdJoined や EnterpriseJoined の値を確認
- クライアントで
- 条件付きアクセス（CA）
- Entra ID ポータルのサインインログで該当ユーザーのログを追跡
- MFA 未完了やデバイス非準拠、許可されていない場所からのアクセスなどがブロック要因になっていないか確認
アカウントとライセンスのチェック
- AVD 利用に必要な Windows ライセンス（例：Windows Enterprise / M365 E3/E5）を割り当て済みか
- ユーザーが対象の Desktop アプリグループに割り当てられているか
- AAD DS を利用している場合は、AAD DS 有効化後にパスワード変更済みであるか（パスワードハッシュ生成のため）
今回の現場で実施した復旧フロー（実績ベース）
実際に障害対応で行った手順を、流れに沿って整理します。類似環境では、これをそのままテンプレートとして使えます。
- AAD DS とセッションホスト VNet のピアリングを再構成
- 既存の VNet ピアリング設定を確認し、不足している方向のピアリングを追加
- 必要ポートが NSG/FW で許可されているかを確認
- 新規セッションホストを用意し、DNS を AAD DS 管理 IP に変更
- AVD ホストプールに新しい VM を追加
- 該当 VM の NIC 設定で、DNS サーバーを AAD DS 管理 IP（2 つ）に設定
- 新規ホストを AAD DS にドメイン参加
- ローカル管理者でログオンし、ドメイン参加ウィザードまたは PowerShell でドメイン参加
- 再起動後、
nltest /sc_verifyでセキュアチャネルが正常なことを確認
- テストユーザーで AVD 接続を検証
- Windows クライアントから AVD にサインインし、問題の新規ホストにセッションが割り当てられることを確認
credentials did not workのエラーが解消されているかチェック
- 既存ホストを Drain モードに切り替え、順次再構成
- 既存ホストは新規セッションを受け付けない Drain モードに変更
- 順番に DNS 設定変更 & ドメイン再参加を実施
- 作業完了後、Drain を解除して通常運用に戻す
このように、いきなり既存ホスト全台に手を入れるのではなく、新規ホストで「正しい構成」を一度完成させてから既存環境に横展開するのが、安全かつ再発防止にもつながるやり方です。
設計段階で意識したいポイント（ベストプラクティス寄り）
今回のような AVD 認証トラブルを避けるために、構成設計の時点で意識しておきたいポイントをいくつか挙げます。
- AAD DS は「ハブ」VNet に配置し、AVD は「スポーク」VNet から参照
- ハブ & スポーク構成にしておくと、DNS・ドメイン関連通信の経路を統一しやすい
- セッションホストの DNS はテンプレート化
- AVD 用のイメージや ARM/Bicep テンプレートに、AAD DS 管理 IP をあらかじめ組み込んでおく
- 手作業でバラバラな DNS 設定にならないようにする
- ホストプール単位で構成を揃える
- 同じホストプール内で、DNS やドメイン参加状態が混在しないようにする
- Drain モードを活用し、ローリング方式で変更を実施
- 運用設計に「定期的な sc_verify チェック」を組み込む
- セキュアチャネルの健全性チェックを、メンテナンスや監視項目に追加する
よくある勘違いと落とし穴
AVD の構成相談でよく出てくる勘違いを、今回の事例と関連付けて整理します。
- 「外部端末もドメイン参加が必須」ではない
- AAD DS ドメイン参加型の AVD では、クライアント端末はドメイン参加していなくても問題ありません。
- 必要なのは「AVD クライアントで Entra ID にサインインできること」です。
- Entra 参加型 AVD と AAD DS 型を混同しない
- Entra 参加型の AVD では、クライアント側の Entra 参加状態や条件付きアクセスの影響が大きくなります。
- どちらの方式を採用しているか、まず環境全体の方針を確認しましょう。
- 「Ping が通る = すべて OK」ではない
- AAD DS の IP に対して Ping が通るだけでは、Kerberos や LDAP、SMB など必要なポートが開いているとは限りません。
- 特に NSG / FW / UDR を多用している環境では、「一部だけ通らない」状態が頻発します。
- AAD DS の特性を軽視しない
- AAD DS はオンプレ AD と完全に同じではなく、レプリケーションスケジュールやパスワードハッシュ生成タイミングに特徴があります。
- 「AAD DS 有効化前に作ったユーザー」や「パスワード変更をしていないユーザー」が問題を起こすことも多いです。
すぐに使えるトラブルシュート用コマンド集
最後に、今回のような AVD 認証トラブルで即座に使えるコマンドをまとめます。PowerShell やコマンドプロンプトで実行し、状況確認に役立ててください。
クライアント（Entra 参加状態の確認）
dsregcmd /status
AzureAdJoinedやEnterpriseJoinedの値を確認し、想定通りのテナントに参加しているかチェックします。
セッションホスト（セキュアチャネルの確認）
nltest /sc_verify:yourdomain.onmicrosoft.com
Test-ComputerSecureChannel -Verbose
- いずれかが失敗する場合は、DNS やドメイン参加に問題がある可能性が高いです。
セッションホストをドメイン参加させる（再起動込み）
Add-Computer -DomainName "yourdomain.com" -Credential (Get-Credential) -Restart
- DNS を AAD DS 管理 IP に変更したうえで実行します。
- 再起動後、
nltest /sc_verifyでセキュアチャネルを再確認しましょう。
まとめ：AVD 認証トラブルは「DNS＋ドメイン＋ネットワーク」を疑う
Azure Virtual Desktop で「外部からの接続だけ Entra ID 認証が失敗する」「Azure ポータルの接続状態が Pending のまま」というトラブルが起きた場合、
- セッションホストの DNS が AAD DS 管理 IP を向いているか
- ホストが AAD DS ドメインに正しく参加しているか
- AAD DS との間の VNet ピアリング / NSG / UDR が適切か
この 3 点を最優先で疑うのが、もっとも近道です。そのうえで、
- 採用している方式が AAD DS ドメイン参加型か、Entra 参加型かを明確にし、
- クライアント側の Entra 参加状態や条件付きアクセス、ライセンス割り当てなどを順番に確認する
という流れで切り分けていけば、credentials did not work に代表される AVD 認証エラーの多くは、落ち着いて解消していくことができます。運用開始後に慌てないよう、構成設計の段階から「DNS・ドメイン・ネットワーク」をセットで見直しておくことを強くおすすめします。
コメント