Azure Virtual Desktop(AVD)で新しいセッションホストを追加したら、なぜか一般ユーザーだけ「資格情報が正しくありません」と弾かれる――管理者だけ入れる、既存ホストには入れる、でも新ホストだけダメ。そんな“あるあるトラブル”の代表格が、Entra ID 参加ホストと RDP プロパティの設定漏れです。本記事では、原因と対処方法を具体的な手順とチェックリスト付きで詳しく解説します。
Azure Virtual Desktop 新規セッションホストで発生する典型的な症状
まずは、よくある状況を整理します。
- 新しい ホストプール と アプリ グループ を作成
- 新しい セッションホスト(VM) もデプロイ済み
- Azure 側の RBAC やアプリ グループの割り当て も一通り設定
- 「リモート デスクトップ(新)」アプリに新しい ワークスペース は表示される
- しかしユーザーが接続すると「資格情報が正しくありません」と表示されてサインインできない
- VM 作成時に指定したローカル管理者アカウント だけはサインインできる
つまり、「AVD やネットワークは生きているが、ユーザーの資格情報だけが通らない」ように見える状態です。このパターンでは、多くの場合セッションホストの 参加形態(Entra ID 参加など) と、ホストプールの RDP プロパティ設定 の不整合が原因になっています。
結論:Entra ID 参加ホストには targetisaadjoined:i:1; が必須
今回のケースのポイントを一言で言うと、
「セッションホストが Microsoft Entra ID 参加なのに、ホストプールの RDP プロパティで AAD 参加ホスト用フラグが設定されていない」
という状態です。
Azure Virtual Desktop では、セッションホストが Entra ID(旧 Azure AD)に参加している場合、クライアントは Entra ID ベースの認証 を前提に接続してきます。その際、ホストプールのカスタム RDP プロパティに、
targetisaadjoined:i:1;
が設定されていないと、クライアント側は「これは Entra ID 参加ホストだ」と認識できず、結果として資格情報が一致しない扱いになり、「資格情報が正しくありません」 というエラーで弾かれます。
一方で、VM 作成時のローカル管理者アカウントは、VM 上のローカルアカウントとして認証されるため、この不一致の影響を受けずにサインインできてしまうのです。
なぜ既存ホストでは問題が出なかったのか
「以前からある別のホストプールや VM では、targetisaadjoined:i:1; を設定していなくても普通に接続できている」というケースも多くあります。これは多くの場合、
- そのホストが Entra ID 参加ではない
- つまり オンプレ AD ドメイン参加 または ハイブリッド参加(Entra+AD)である
といった理由によるものです。参加形態によって、必要な認証方式と RDP プロパティが異なる点に注意しましょう。
ホスト参加形態とログインパターンの整理
混乱を避けるために、セッションホストの参加形態と、利用すべきアカウント・設定の関係を整理します。
| ホストの参加形態 | 想定されるログインアカウント | RDP プロパティのポイント | よくあるエラー |
|---|---|---|---|
| Microsoft Entra ID 参加 | Microsoft Entra ID アカウント(UPN) 例:[email protected] | targetisaadjoined:i:1; を必ず設定 | 資格情報が正しくありません |
| オンプレ AD ドメイン参加 | ドメインユーザー 例:contoso\user または [email protected] | 通常 targetisaadjoined は不要 | ドメインコントローラー到達不可時の接続失敗など |
| ハイブリッド参加(AD + Entra) | AD アカウント or Entra アカウント(構成による) | 設計に応じて設定。多くは AD ログインを前提に構成 | どのアカウントで入るべきか分からない混乱 |
今回のように Entra ID 参加ホスト なのに RDP プロパティで AAD 参加を示していないと、クライアントは AD ドメイン参加ホストのように扱おうとして認証エラーになります。
最短ルートの解決手順:RDP プロパティにフラグを追加
一番シンプルで効果が高い解決手順は次のとおりです。
Azure ポータルからの設定変更
- Azure ポータルに管理者アカウントでサインイン
- 検索ボックスで「Azure Virtual Desktop」を検索し、ホスト プール を選択
- 問題が発生しているホストプールをクリック
- 左メニューの「RDP プロパティ」を選択
- 「接続情報」または「カスタム RDP プロパティ」欄に、以下を追加して保存
targetisaadjoined:i:1;
既に別の設定が入っている場合は、末尾にセミコロン区切りで追記します。
redirectclipboard:i:1;audiocapturemode:i:1;targetisaadjoined:i:1;
クライアント側でのワークスペース更新
- ユーザーの PC で「リモート デスクトップ(新)」アプリを起動
- 対象の ワークスペース を右クリック(または「…」メニュー)
- 「更新」 を実行
- アプリ グループ(デスクトップ)を再度ダブルクリックして接続
この時点で、一般ユーザーの Entra ID アカウントで接続できるか確認します。多くのケースでは、この手順だけで問題が解消します。
CLI からまとめて設定する場合
複数のホストプールに対して同じ設定を適用したい場合、Azure CLI が便利です。
az desktopvirtualization hostpool update \
--resource-group <RG名> \
--name <ホストプール名> \
--custom-rdp-property "targetisaadjoined:i:1;"
既にカスタム RDP プロパティがある場合は、現在の値を確認し、targetisaadjoined:i:1; を追加した文字列を指定してください。
再発防止のために必ず確認しておきたい設定
今回の問題は RDP プロパティだけが原因でしたが、実運用では他の設定も絡んで問題が複雑化しがちです。ここでは、再発を防ぐために最低限押さえておきたいポイントを整理します。
RBAC ロールの付与状況
Azure Virtual Desktop を Entra ID 参加ホストで利用する場合、ユーザーには少なくとも以下のロールが必要です。
| ロール名 | 用途 | 推奨スコープ |
|---|---|---|
| Virtual Machine User Login | Windows に対するユーザーとしてのサインイン許可 | VM / リソースグループ / サブスクリプション のいずれか |
| (必要に応じて)Virtual Machine Administrator Login | 管理者としてのサインイン許可 | 管理者アカウント用に限定付与 |
特に検証環境では、つい「サブスクリプション全体にロールを付与してしまう」こともありますが、本番環境では最小権限を意識して、リソースグループや特定 VM のスコープで付与するのがおすすめです。
アカウント種別と参加形態の整合性
ログインに使うアカウント種別が、ホストの参加形態と一致しているかも重要です。
| ホストの参加形態 | 利用すべきアカウント種別 | よくある間違い |
|---|---|---|
| Entra ID 参加 | Entra ID アカウント(例:[email protected]) | オンプレ AD のドメインアカウントでログインしようとする |
| ドメイン参加(オンプレ AD) | ドメインアカウント(例:contoso\user) | Entra ID アカウントだけしか用意していない |
| ハイブリッド参加 | 設計に応じて AD or Entra | どちらでログインすべきか運用ルールが決まっていない |
AVD 診断でサインインエラーを確認
Azure ポータルの「Azure Virtual Desktop 診断」は、ユーザーの接続トラブルを解析する上で非常に有用です。特に、
- ユーザー名 / UPN の誤り
- RBAC 不足
- ライセンスの不足
- ネットワーク接続失敗
などを視覚的に確認できるので、「まずは診断を一度眺める」ことをルール化しておくと、原因特定にかかる時間を大きく削減できます。
ホストから参加状態を確認:dsregcmd /status
セッションホストが実際にどのような状態で Entra ID に登録されているかは、ホスト上で次のコマンドを実行して確認できます。
dsregcmd /status
出力の中で特に確認すべき項目は以下のとおりです。
| 項目 | 期待値 | 意味 |
|---|---|---|
| AzureAdJoined | YES | Entra ID に参加しているかどうか |
| DomainJoined | YES / NO(構成による) | オンプレ AD ドメインに参加しているか |
| DeviceId | GUID | Entra ID 上のデバイス ID |
AzureAdJoined = YES であれば、今回のように targetisaadjoined:i:1; を設定すべきホストであると判断できます。
運用上のコツ:設計時から「参加形態」と「RDP プロパティ」を台帳化する
一度トラブルを経験すると、「あのホストは Entra 参加だったか、ドメイン参加だったか?」とあとから確認するのは意外と面倒だと気づきます。そこでおすすめなのが、ホストプール単位で次のような台帳を作っておくことです。
| ホストプール名 | セッションホスト参加形態 | RDP プロパティ | 備考 |
|---|---|---|---|
| HP-Prod-AVD-01 | Entra ID 参加 | targetisaadjoined:i:1;redirectclipboard:i:1; | 本番用・Entra ログインのみ |
| HP-Dev-AVD-01 | ドメイン参加(contoso.local) | redirectclipboard:i:1; | 検証用・開発者のみ |
このような表を一度用意しておくと、
- 新しいホストを追加する際に、どの構成を踏襲すべきか一目で分かる
- トラブル時にも「本来あるべき設定」との差分が明確になる
といったメリットが生まれます。
IaC(Bicep / Terraform)で targetisaadjoined:i:1; を標準化する
ヒューマンエラーを減らすには、「手で設定しない」 のが一番です。Azure Virtual Desktop のホストプールを Bicep や Terraform で構成管理している場合は、Entra ID 参加のホストプールには必ず targetisaadjoined:i:1; を含めるようテンプレート化してしまいましょう。
例:Bicep のイメージ(概略)
resource hostPool 'Microsoft.DesktopVirtualization/hostPools@2022-02-10' = {
name: hostPoolName
location: location
properties: {
hostPoolType: 'Pooled'
loadBalancerType: 'BreadthFirst'
customRdpProperty: 'targetisaadjoined:i:1;redirectclipboard:i:1;'
// ほかのプロパティ
}
}
ポイントは、「Entra ID 参加ホスト専用のテンプレート」 として切り出しておくことです。ドメイン参加ホスト用テンプレートと混在させると、いつか必ず設定ミスが発生します。
クライアント側のベストプラクティス
サーバー側の設定だけでなく、クライアント側にもいくつか意識しておきたいポイントがあります。
リモート デスクトップ(新)アプリは常に最新に
AVD の機能は頻繁にアップデートされています。古いクライアントを利用していると、
- Entra ID ベースの認証まわりの挙動
- シングルサインオン
- マルチモニターや印刷リダイレクト
などで思わぬ不具合に遭遇することがあります。特に、Entra ID 参加ホストへの接続に関しては、クライアントバージョン依存の事象も報告されているため、運用として「クライアントは最新へ」を徹底しておくと安心です。
ワークスペース更新を定期的な運用に組み込む
ホストプールやアプリ グループの設定を変更しても、クライアント側のワークスペース情報が古いままだと、反映されないことがあります。トラブル時の初動として、
- 「一度ワークスペースを削除して再登録する」
- または「ワークスペースの更新」を行う
という手順を利用者向けヘルプにも記載しておくと、現場オペレーションがスムーズになります。
よくある質問と補足
Q. 既に動いているホストプールにも targetisaadjoined:i:1; を付けるべき?
A. ホストが Entra ID 参加であれば付けるべきです。ドメイン参加のホストプールに誤って付けてしまうと挙動が変わる可能性があるため、事前に dsregcmd /status で参加形態を確認した上で設定してください。
Q. 追加設定後も「資格情報が正しくありません」が消えない場合は?
次のポイントを順番に確認してください。
- RDP プロパティのタイプミスがないか
targetisaadjoined:i:1;のスペルミスやセミコロン漏れがないか確認します。 - ユーザーに Virtual Machine User Login が付いているか
付与スコープ(VM / RG / サブスクリプション)のいずれかで有効になっているかを確認します。 - ログインに使っているアカウントが Entra ID アカウントか
ドメインアカウントと混同していないか確認します。 - AVD 診断に別のエラーが出ていないか
ライセンス不足やネットワーク問題など、別の原因が混在していないかチェックします。
最終チェックリスト
最後に、本記事で紹介したポイントをチェックリストとしてまとめます。トラブルシューティング時だけでなく、新しいホストプールを作る際にも、このリストを一通り確認する運用にしておくと安心です。
| チェック項目 | 確認内容 |
|---|---|
| 1. ホストの参加形態 | 対象ホストで dsregcmd /status を実行し、AzureAdJoined = YES か確認したか。 |
| 2. RDP プロパティ | ホストプールの RDP プロパティに targetisaadjoined:i:1; が設定されているか。 |
| 3. RBAC ロール | 対象ユーザーに Virtual Machine User Login ロールが付与されているか。 |
| 4. アカウント種別 | Entra ID 参加ホストには Entra ID アカウント、ドメイン参加ホストにはドメインアカウントでログインしているか。 |
| 5. AVD 診断 | Azure Virtual Desktop 診断でサインイン関連のエラーが出ていないか確認したか。 |
| 6. クライアント更新 | リモート デスクトップ(新)アプリが最新バージョンであり、ワークスペースを更新しているか。 |
ここまで確認しても問題が解決しない場合は、
- 対象ユーザーのサインインログ(Entra ID サインインログ)
- セッションホスト上のイベントログ(
Microsoft-Windows-TerminalServices-RemoteConnectionManagerなど)
を合わせて確認し、どの段階で認証が失敗しているかを切り分けると、次の一手が見えやすくなります。
まとめ:Entra ID 参加ホストでは targetisaadjoined:i:1; を忘れない
Azure Virtual Desktop で新しいセッションホストに接続できず、「資格情報が正しくありません」 と表示される場合、
- セッションホストが Microsoft Entra ID 参加 である
- ホストプールの RDP プロパティに
targetisaadjoined:i:1;が設定されていない
という組み合わせが非常に多い原因です。
まずはホストの参加形態を確認し、Entra ID 参加であることが分かったら、迷わず RDP プロパティに targetisaadjoined:i:1; を追加しましょう。その上で、RBAC・アカウント種別・AVD 診断を合わせて確認すれば、ほとんどの「資格情報が通らない」トラブルはスムーズに解消できます。
運用設計の段階で、
- ホストプールごとの参加形態と RDP プロパティを台帳化する
- IaC テンプレートに
targetisaadjoined:i:1;を組み込んでおく - クライアント更新とワークスペース更新を運用ルールに入れておく
といった工夫をしておけば、今後の拡張やトラブルシューティングも格段に楽になります。Entra ID 参加の AVD 環境を運用している方は、ぜひ本記事の内容を自社環境の標準ルールに落とし込んでみてください。

コメント