Azure AD に参加した Windows 10 / Windows 11 端末から Windows Server 2019 などへリモートデスクトップ接続をしようとしたときに、正しいはずのユーザー名とパスワードで The credentials supplied to the package were not recognized エラーが出てしまう――本記事では、この現象の原因と、実際に多くの環境で有効だった解決策を「なぜそうなるのか」も含めて詳しく解説します。
RDP接続時に出る「The credentials supplied to the package were not recognized」エラーとは
まずは、問題となっているエラー内容を整理します。
Azure AD に参加済みの Windows 10 / Windows 11 から、オンプレミスやクラウド上の Windows Server 2019（または 2016 / 2022 など）へ mstsc.exe を使って RDP 接続しようとすると、次のようなメッセージが表示されることがあります。
An authentication error has occurred.
The credentials supplied to the package were not recognized.
状況としてよくあるのが、次のようなパターンです。
- ユーザー名・パスワードは合っている（別の PC からはログオンできる）
- Azure AD に参加していない、通常のワークグループ PC からは接続できる
- 問題が起きるのは「Azure AD 参加 PC」からの RDP 接続だけ
この場合、多くのケースで原因は「ユーザー名の書き方」にあります。特に Azure AD 参加 PC では、サーバーに渡す資格情報として、どの認証元（Azure AD / オンプレ AD / ローカル）を使うのかが曖昧になることがあり、結果として誤った認証パッケージが選ばれてしまいます。
解決のカギとなるのは、ユーザー名に「修飾子」を付けて、どのアカウントで認証させたいかを明示することです。
最短で直す結論：ユーザー名に「修飾子」を付ける
このエラーを最短で解消するためのポイントはシンプルです。
ユーザー名に、AzureAD・ドメイン名・ローカルを示す接頭辞（修飾子）を付けるだけです。
代表的な書き方は次のとおりです。
- Azure AD アカウントを使う場合：
AzureAD\ユーザー名またはAzureAD\ユーザーUPN - 接続先サーバーのローカルアカウントを使う場合：
.\ユーザー名またはサーバー名\ユーザー名 - オンプレ AD ドメインアカウントを使う場合：
ドメイン名\ユーザー名
重要なのは、次の点です。
- 「/（スラッシュ）」ではなく「\（バックスラッシュ）」を使う
- ユーザー名だけではなく、「どの認証元のユーザーなのか」をセットで書くイメージ
ユーザー名の使い分け早見表
| 接続元端末 | 接続先サーバー | 入力するユーザー名の例 |
|---|---|---|
| Azure AD 参加 PC | サーバーのローカルアカウント | .\admin / SERVER01\admin |
| Azure AD 参加 PC | オンプレ AD 参加サーバー | CONTOSO\taro |
| Azure AD 参加 PC | Azure AD アカウントでサインインさせたい | AzureAD\hanako / AzureAD\[email protected] |
特に Azure AD 参加 PC → Windows Server という組み合わせでは、ユーザー名に何も付けず「hanako」や「[email protected]」とだけ入れるとトラブルの元になりやすいため、意識的に修飾子を付ける習慣にしておくと安全です。
シナリオ別：具体的な入力例と注意点
Azure AD アカウントで接続する場合
まず、前提として押さえておきたいのは、一般的な Windows Server は、そのままでは Azure AD アカウントだけでサインインできないという点です。
- Azure AD Domain Services（Azure AD DS）を構成している
- オンプレ AD と Azure AD を同期させている（ハイブリッド環境）
など、サーバー側で適切な構成が行われている場合に限り、Azure AD のユーザーがサーバー上にも存在する形になり、実質的に Azure AD アカウントでのサインインが可能になります。
そのうえで Azure AD 参加 PC から RDP 接続する際は、次のように入力します。
- ユーザー名：
AzureAD\ユーザー名例）AzureAD\hanako - ユーザー名（UPN形式）：
AzureAD\ユーザーUPN例）AzureAD\[email protected]
ポイントは、「AzureAD\」というプレフィックスが必須であることです。これを付けることで、クライアント側が「これは Azure AD の資格情報として扱うべきだ」と判断し、適切な認証パスでサーバーへ資格情報を渡します。
単に [email protected] とだけ入れた場合、クライアントはそれを UPN としか認識できません。「Azure AD のユーザーなのか、オンプレ AD の UPN なのか、ローカルユーザー名なのか」が曖昧になるため、誤ったパッケージが選択されてエラーとなることがあります。
サーバーのローカルアカウントで接続する場合
クラウド上の VM（AWS / Azure / さくらのクラウド 等）へ接続するケースや、小規模なオンプレ環境などでよく出てくるのが、サーバーのローカルアカウントでの接続です。
この場合は、次のいずれかの形式を使います。
- ローカルマシンであることを明示：
.\ユーザー名
例）.\Administrator、.\rdpuser - サーバー名で明示：
サーバー名\ユーザー名
例）WSRV01\rdpuser
「.\」は「今接続しようとしているマシンのローカルアカウントである」という意味を持っています。Azure AD 参加 PC から見ると、単に Administrator と入力しただけでは「これは Azure AD アカウントかもしれない」と解釈される余地があります。そこで、.\ を付けることで、ローカルアカウントであることを明示し、認証の取り違えを防ぐことができます。
なお、AWS や Azure で VM を作成したときに自動で作られるローカル管理者アカウント（例：Administrator や azureuser）でも .\Administrator のように指定すれば同様に接続できます。
オンプレ AD ドメインアカウントで接続する場合
オンプレミスで Active Directory ドメインが構成されており、サーバーがドメインに参加している場合は、古典的な「ドメイン名\ユーザー名」形式が最も確実です。
- ユーザー名：
CONTOSO\taro - UPN で接続して失敗する場合：
[email protected]ではなくCONTOSO\taroに切り替える
Azure AD 参加 PC 側から見ると、[email protected] という文字列が「Azure AD の UPN にも見えるし、オンプレ AD の UPN にも見える」ため、環境によってはうまく解決できず、結果として認証エラーになることがあります。このため、「ドメイン名\ユーザー名」形式を優先するのが安全です。
なぜユーザー名の書き方でエラーが直るのか
ここからは少し内部動作寄りの話になりますが、エラーの背景を理解しておくと、トラブルシューティングの精度が一気に上がります。
Azure AD 参加 PC では「認証元」が複数存在する
従来のワークグループ PC やドメイン参加 PC では、認証のパターンは比較的シンプルでした。
- ローカルアカウント
- オンプレ AD ドメインアカウント（Kerberos / NTLM）
ところが、Azure AD 参加 PC ではさらに次の要素が加わります。
- Azure AD アカウント（クラウドベース）
- デバイス自体も Azure AD に登録されている
- 条件付きアクセスや多要素認証など、クラウド側のポリシーも絡む
RDP の資格情報を処理する際、クライアントは「これは Azure AD のユーザーなのか？オンプレ AD のユーザーなのか？ローカルアカウントなのか？」を判断する必要があります。しかし、単に「taro」や「[email protected]」とだけ入力した場合、その判断が曖昧になり、誤った認証プロバイダーが選択されてしまうことがあります。その結果として、The credentials supplied to the package were not recognized というエラーとなるわけです。
ユーザー名の「修飾子」で認証パスを固定する
そこで重要になるのが、ユーザー名の前に付ける「修飾子」です。
AzureAD\→ Azure AD のアカウントとして扱うドメイン名\→ 指定したオンプレ AD ドメインのアカウントとして扱う.\/サーバー名\→ 接続先サーバーのローカルアカウントとして扱う
このように明示することで、クライアント側は「どの認証元に対して、どの認証方式を使って資格情報を組み立てればよいか」を正しく判断できます。結果として、誤った認証パッケージを選ぶことがなくなり、エラーが解消されるという仕組みです。
実践ステップ：RDPクライアントの設定手順
ここからは、実際に Azure AD 参加 PC から RDP 接続を行う際の具体的な操作手順を紹介します。
RDP クライアントで正しいユーザー名を指定する
Win + Rキーを押し、mstscと入力して RDP クライアントを起動します。- 「コンピューター」欄に、接続したいサーバー名または IP アドレスを入力します。
- 「ユーザー名」欄に、前述のいずれかの形式でユーザー名を入力します。
- ローカルアカウント：
.\Administratorなど - ドメインアカウント：
CONTOSO\taroなど - Azure AD アカウント：
AzureAD\hanakoなど
- ローカルアカウント：
- 「オプションの表示（詳細）」をクリックし、「詳細設定」タブを開きます。
- 「資格情報を常に求める」にチェックを入れておくと、キャッシュされた誤った資格情報が使われるのを防げます。
- 設定を保存したい場合は、「全般」タブで「名前を付けて保存」を行い、.rdp ファイルとして保管します。
資格情報マネージャーのキャッシュをクリアする
正しいユーザー名形式にしてもまだエラーが出る場合、過去に保存された資格情報が悪さをしている可能性があります。この場合は、次の手順でキャッシュをクリアします。
- コントロールパネルを開き、「ユーザーアカウント」→「資格情報マネージャー」をクリックします。
- 「Windows 資格情報」タブを選択します。
- 一覧の中から、接続先サーバー名や IP アドレスに対応する項目を探します。
- 対象の資格情報をクリックし、「削除」を実行します。
- 再度 RDP クライアントから接続し、正しい形式のユーザー名とパスワードを入力し直します。
これにより、以前の誤ったユーザー名形式（例：単純な UPN や ローカルユーザー名のみ）がキャッシュされていた場合でも、新しい形式での認証が行われるようになります。
うまくいかないときのチェックリスト（詳細版）
ここからは、ユーザー名の形式を修正してもまだ問題が解消しない場合に確認すべきポイントを、より詳しく解説します。
1. 保存済み資格情報の削除
前述のとおり、資格情報マネージャーに古い情報が残っていると、そちらが優先的に使われてしまうことがあります。特に、次のようなケースでよく問題になります。
- 以前はワークグループ PC からローカルアカウントで接続していた
- 環境の途中でドメインに参加させたり、Azure AD 参加に切り替えたりした
- 一度間違った形式（例：
[email protected]だけ）で保存してしまった
このような場合は、一度すべての関連資格情報を削除した上で、改めて接続し直すのが近道です。
2. RDP クライアント側で「資格情報を常に求める」を有効にする
資格情報のトラブルを減らすもう一つのテクニックが、RDP クライアントの「資格情報を常に求める」の設定です。
mstscを起動し、「オプションの表示」をクリックします。- 「詳細設定」タブを開き、「接続時に資格情報を常に求める」にチェックを入れます。
- この状態で接続すると、毎回ユーザー名とパスワードの入力を求められます。
毎回入力するのは手間ですが、環境を切り替えている最中やトラブルシューティング中は、この設定を有効にしておくと原因切り分けがしやすくなります。
3. サーバー側で接続許可が付与されているか確認
クライアント側の設定が正しくても、サーバー側で接続が許可されていなければログオンできません。次の点を確認しましょう。
- 対象ユーザーがサーバーのローカル管理者、または「リモート デスクトップ ユーザー」グループのメンバーになっているか
- ドメイン環境の場合、グループポリシーで RDP 接続が制限されていないか
- ネットワークレベル認証（NLA）の設定が環境に合っているか
ローカルユーザーで接続する場合、ローカル管理者権限があればデフォルトで RDP 接続が許可されますが、制限を厳しくしている環境では明示的な設定が必要なこともあります。
4. NLA（ネットワーク レベル認証）の有効・無効による切り分け
NLA はセキュリティ強化のために推奨される機能ですが、古いクライアントや一部の設定では相性問題が起きることがあります。原因切り分けとして、一時的に NLA をオフにしてみるのも有効です。
- サーバー上で「システムのプロパティ」を開き、「リモート」タブを選択します。
- 「リモート デスクトップ」セクションで、「ネットワーク レベル認証でリモート デスクトップを実行しているコンピューターからのみ接続を許可する」のチェックを外します。
- 設定を保存し、再度 RDP 接続を試します。
ここで接続できるようになる場合、NLA を使った認証プロセスのどこかで問題が発生している可能性が高いため、クライアント・サーバー双方の認証設定やセキュリティ更新状況を確認します。最終的には、可能な限り NLA を有効に戻すことを忘れないようにしましょう。
5. Windows Hello（PIN / 顔認証）がそのまま RDP に使えない点に注意
Azure AD 参加 PC では、ログオンに PIN や 顔認証（Windows Hello）を使っているケースが多く見られます。しかし、RDP 接続では PIN や顔認証そのものをサーバー側に渡せるわけではありません。
RDP の認証では、最終的にはユーザー名とパスワードとして評価されるため、次の点に注意が必要です。
- RDP 用には、必ず「パスワード」が設定されている必要がある
- PIN しか設定していない Azure AD アカウントでは、RDP 接続に失敗する場合がある
- パスワードを忘れている場合は、Azure AD（または Microsoft アカウント）のパスワードリセットを行う
PIN ログオンに慣れているとパスワードの存在を忘れがちですが、RDP ではいまだに「ユーザー名＋パスワード」が基本であることを意識しておきましょう。
6. UPN 形式で失敗するときは「ドメイン\ユーザー名」形式へ切り替える
オンプレ AD 環境で、[email protected] のような UPN 形式で接続しようとして失敗するケースもよくあります。この場合、「ドメイン名\ユーザー名」形式に切り替えるだけで解決することが多いです。
理由は前述のとおり、UPN 形式だけではクライアント側から見たときに「Azure AD の UPN なのか、オンプレ AD の UPN なのか」が判別しづらい場合があるためです。CONTOSO\taro のように書くことで、クライアントは迷うことなくオンプレ AD の認証を選択できます。
よくある失敗パターンと対処法一覧
| 失敗パターン | 典型的な症状 | 対処・回避策 |
|---|---|---|
| ユーザー名を「taro」だけで入力 | 資格情報エラーでログオンできない | .\taro または CONTOSO\taro など、修飾子を付ける |
| UPN 形式のみで入力（例：[email protected]） | Azure AD とオンプレ AD のどちらの UPN か曖昧になり失敗 | まずは ドメイン名\ユーザー名 形式に切り替える |
| 資格情報マネージャーに古い情報が残っている | 昔のユーザー名が勝手に補完される / 正しいパスワードでもエラー | 資格情報マネージャーで該当エントリを削除してから再接続 |
| NLA と相性の悪い古いクライアント | 接続直後に認証エラー、またはエラーコードが変化 | 一時的に NLA をオフにして切り分け、その後クライアント更新を検討 |
| Windows Hello だけ設定していてパスワードを忘れている | PIN では接続できない / パスワード欄に何を入れればよいか分からない | Azure AD / Microsoft アカウントのパスワードをリセットし、パスワードで認証 |
セキュリティと運用の観点からのベストプラクティス
エラーを回避するだけでなく、実運用で安全かつ快適に RDP 接続を活用するには、次のようなポイントも意識しておくとよいでしょう。
資格情報の保存は最小限にする
- 共有 PC や持ち出し端末では、RDP の資格情報を保存しない
- 管理者アカウントのパスワードは、極力キャッシュさせない
- RDP 用アカウントを分ける（普段使いアカウントと管理用アカウントを分離する）
特に管理者権限を持つアカウントを使って RDP 接続する場合、端末の盗難・紛失時のリスクが大きくなります。資格情報の保存は必要最小限にとどめ、定期的に見直すことが重要です。
RDP を公開する場合は VPN や Gateway を併用する
インターネット越しに RDP を直接公開するのは、セキュリティ上非常にリスクが高い構成です。どうしてもリモートから RDP を使う必要がある場合は、次のような構成を検討しましょう。
- VPN で社内ネットワークに接続した上で RDP を利用する
- Azure AD Application Proxy や RDP Gateway を用意し、直接の 3389/TCP 公開を避ける
- IP 制限や多要素認証を組み合わせる
今回のテーマは認証エラーの解決ですが、せっかく Azure AD を活用しているのであれば、条件付きアクセスや MFA などのクラウド側のセキュリティ機能も積極的に組み合わせるのがおすすめです。
よくある質問（Q&A）
Q. UPN 形式（[email protected]）では絶対に接続できないの？
A. 環境によっては UPN 形式だけでも問題なく接続できることがあります。しかし、Azure AD 参加 PC からオンプレ / ローカルサーバーへ接続するケースでは、認証元の判定が曖昧になりやすく、トラブルの原因になりがちです。そのため、トラブルシューティングの観点では、まず AzureAD\ や ドメイン名\ を付ける方法を優先することをおすすめします。
Q. 「AzureAD\ユーザー名」と「AzureAD\ユーザーUPN」はどちらを使うべき？
A. どちらでも認証できるケースが多いですが、ユーザー名に重複がある環境では UPN の方が安全です。たとえば、hanako というユーザー名が複数のドメインにまたがって存在する場合、AzureAD\[email protected] のように UPN まで指定することで、誤認識の可能性をさらに減らせます。
Q. そもそも Windows Server に Azure AD アカウントだけでサインインできるの？
A. 通常のオンプレミス Windows Server は、単体では Azure AD と直接連携してログオンを受け付けることはできません。実際には、次のような仕組みを使って Azure AD と「間接的に」連携させるケースがほとんどです。
- Azure AD Domain Services（Azure AD DS）
- オンプレ AD と Azure AD のディレクトリ同期（Azure AD Connect 等）
上記のような仕組みによって、サーバー上に「オンプレ AD アカウント」としてユーザーが存在する状態を作り、そのアカウントに対して RDP 接続を行うイメージです。「ユーザー名に AzureAD\ を付けるテクニック」は、クライアント側の認証先の取り違えを防ぐ目的であり、サーバー側の構成そのものを変えるものではありません。
Q. Azure AD 参加 PC から、同じネットワーク上のワークグループサーバーへ接続するときは？
A. この場合は、多くのケースで .\ユーザー名 または サーバー名\ユーザー名 の形式を使用します。ドメインに参加していないサーバーでは、ローカルアカウントでの接続が基本になります。Azure AD 参加 PC から見ても、サーバー側には Azure AD アカウントの情報がないため、ローカルアカウントとして明示することが重要です。
まとめ：まずは「ユーザー名の先頭」を見直す
Azure AD 参加 PC から RDP 接続を行う際に The credentials supplied to the package were not recognized エラーが発生する場合、最初に疑うべきはユーザー名の書き方です。
- Azure AD アカウントなら：
AzureAD\ユーザー名/AzureAD\ユーザーUPN - サーバーのローカルアカウントなら：
.\ユーザー名/サーバー名\ユーザー名 - オンプレ AD ドメインアカウントなら：
ドメイン名\ユーザー名
そして、うまくいかないときは次のチェックポイントを順番に確認していきましょう。
- 資格情報マネージャーの古いエントリを削除したか
- RDP クライアントで「資格情報を常に求める」を有効にしたか
- サーバー側で RDP 接続が許可されているか
- NLA の有効/無効で挙動が変わるか
- Windows Hello ではなく「パスワード」で認証しているか
- UPN だけでなく「ドメイン名\ユーザー名」形式も試したか
多くの環境で、「ユーザー名に “AzureAD\” / “.\” / “ドメイン\” を付ける」だけで問題は解決します。まずはここから試し、必要に応じて本記事のチェックリストをもとに切り分けを進めてみてください。
コメント