Windows が「ユーザー アカウントがリモート ログオンを許可されていないため接続が拒否されました」と表示する場合、原因はパスワードではありません。パスワードは受け付けられており、その次の段階である認可時にセッションが拒否されています.
結果を決める確認は2つあります: アカウントがローカルの Remote Desktop Users グループまたは Administrators グループに属していること、そして secpol.msc の リモート デスクトップ サービスを介したログオンを許可する ポリシーに含まれていることです。どちらか一方でも満たしていないと、このエラーになります。
両方に優先する設定が1つあります: リモート デスクトップ サービスを介したログオンを拒否する。アカウント本人、またはそれが属するいずれかのグループがその一覧に含まれている場合、他の設定がどうであれブロックされます。
ドメインに参加しているマシンでは第4の層があります。ドメインや OU レベルのグループ ポリシーが、次回の更新時にローカル設定を静かにリセットし、数分前に完了したように見えた修正を元に戻してしまうことがあります。
まずはグループ メンバーシップから確認しましょう。これが最も一般的な原因です。
クイック修正の手順
詳しい説明を読まずにすぐに始めたい場合は、以下を順に実行し、エラーが解消したら停止してください。
-
対象コンピューターの Remote Desktop Users ローカル グループにアカウントを追加します。
-
secpol.msc を開き、そのアカウントが属するグループが「リモート デスクトップ サービスを介したログオンを許可する」に表示されていることを確認します。
-
同じ場所で、リモート デスクトップ サービス経由でのログオンを拒否」を確認し、アカウントがそこに含まれていないことを確認します。
-
コンピューターがドメインに参加している場合は、secpol.msc のローカルポリシーだけでなく、GPMC でドメインの GPO を確認してください。
-
上記のポリシー設定が正しいことを確認した後にのみ、資格情報マネージャーから保存済みの古い資格情報を削除してください。
このエラーについて実際のユーザーが報告している内容
フォーラム全体で最も一般的な不満: すべて正しく見えるのに、それでもエラーが残る。Microsoft Q&A のドメイン管理者は、グループ メンバーシップが正しく、ローカルの secpol.msc も見た目はクリーンなのに、管理者以外の RDP 接続をすべて拒否する Windows 11 ワークステーションについて述べた。実際の阻害要因は、ローカル設定を静かに上書きしていたドメイン レベルの GPO だった。 (Microsoft Q&A、2024年9月)
Azure VM では、関連する問題がループとして表面化する: 手動でアカウントを追加するとセッションは動作するが、再起動後にそのアカウントが消え、エラーが戻ってくる。原因は、ポリシー更新のたびにメンバーシップを剥奪する Restricted Groups の GPO で、GPO 自体が更新されるまで UI での修正は保持されない。 (Microsoft Tech Community、2023年6月)
保存済みの資格情報は、見落としがちなトリガーだ。何年も問題なく動いていた RDS プールが、突然このエラーで全ユーザーを拒否し始めた。権限は変更されていなかった。保存されたパスワードを削除して手動で再入力すると即座に解決し、同じスレッドで複数のユーザーにより確認された。 (Microsoft Q&A、2022年10月)
ドメイン参加済みの Azure VM で、1,000 人のユーザーを管理する管理者が、Allow log on through Remote Desktop Services ポリシーにアカウントを追加し、gpupdate /force を実行したが、それでもこのエラーに直面した。欠けていた手順は、VM 自体のローカル Remote Desktop Users グループにユーザーを追加すること。両方の確認が必要だ。 (Microsoft Q&A、2022年11月)
Intune 管理下の環境では、lusrmgr.msc に Azure ドメインが利用可能な場所として表示されないため、標準的なグループ メンバーシップの修正は適用できない。正常に適用された Intune 構成ポリシーだけでは不十分だ。Entra 参加デバイスには、Allow log on through Remote Desktop Services 権限を対象にした別のポリシーが必要となる。 (Microsoft Q&A、2024年12月)
ユーザー アカウントがリモート ログオンを許可されていないため接続が拒否される問題の解決方法
修正 1: ユーザーをリモート デスクトップ ユーザー グループに追加する
スタンドアロン マシンでは、このエラーの最も一般的な原因はグループ メンバーシップの欠如です。これらの手順は、接続元のマシンではなく、リモート PC で実行してください。なお、Windows Home エディションでは lusrmgr.msc は利用できません。また、Home エディションは RDP ホストとしても動作できません。
-
Win + R キーを押し、lusrmgr.msc と入力して Enter キーを押します。
-
左側のペインで Groups を選択し、次に Remote Desktop Users をダブルクリックします。
-
追加をクリックします。
-
ユーザー名を入力し、名前の確認をクリックしてユーザー名が解決されることを確認し、OK をクリックします。
-
グループのプロパティ ウィンドウを閉じるには、OK をクリックします。
システムのプロパティからの手早い方法: Win + R を押し、sysdm.cpl と入力し、[リモート] タブを選択して、[ユーザーの選択] をクリックし、そこでアカウントを追加します。
リモート マシンの管理者権限の PowerShell プロンプトから:
Add-LocalGroupMember -Group “Remote Desktop Users” -Member “username”
username を実際のアカウント名に置き換えてください。再起動は不要です。
対処法 2: リモート デスクトップ サービス経由でのログオンを許可するポリシーを確認する
グループ メンバーシップとユーザー権限ポリシーはそれぞれ独立して確認されます。両方を満たす必要があり、どちらか一方だけを修正しても、もう一方が未対応のままだとエラーはそのまま残ります。これらの手順はリモート PC で実行してください。
-
Win + R を押し、secpol.msc と入力して、Enter を押します。
-
セキュリティの設定 > ローカル ポリシー > ユーザー権利の割り当て に移動します。
-
リモート デスクトップ サービスを介したログオンを許可するをダブルクリックします。
-
Remote Desktop Users と Administrators の両方が一覧に表示されていることを確認します。どちらかが見つからない場合は、Add User or Group をクリックし、グループ名を入力して、OK をクリックします。
-
OK をクリックし、管理者権限のコマンド プロンプトから次を実行します: gpupdate /force
ドメインに参加しているコンピューターでは、競合するドメイン GPO によって、保存してから数分以内にこの設定が上書きされることがあります。設定が元に戻る場合は、修正 4 に進んでください。
修正 3: 許可設定を上書きする拒否ポリシーがないか確認する
リモート デスクトップ サービスを介したログオンを拒否するポリシーは、グループ メンバーシップや許可ポリシーに関係なくアクセスをブロックします。許可の設定が完全に見える場合でも、これを確認してください。
-
secpol.msc で、セキュリティの設定 > ローカル ポリシー > ユーザー権利の割り当て に移動します。
-
「リモート デスクトップ サービスを介したログオンを拒否する」をダブルクリックします。
-
リストを確認してください。接続しているアカウント、またはその所属グループ（ゲストやドメイン ゲストを含む）のいずれかがここに表示されている場合は、それを選択して削除をクリックしてください。
-
OK をクリックし、gpupdate /force を実行します。
保存して gpupdate /force を実行しても設定が元に戻る場合、ドメイン GPO が制御しています保存して gpupdate /force を実行しても設定が元に戻る場合、ドメイン GPO がドメイン レベルで制御しています。ローカル セキュリティ ポリシーまたはグループ ポリシーの管理でのみこのポリシーを管理してください。ユーザー権利の割り当てをレジストリで直接編集しようとしないでください。許可および拒否のログオン権限は、単純なレジストリ値ではなく、Windows によって名前付き特権定数（SeRemoteInteractiveLogonRight および SeDenyRemoteInteractiveLogonRight）として管理されています。監査には、secpol.msc、gpresult、または secedit を使用してください。
解決策4: ドメイン GPO に直接対処する
ドメインに参加しているコンピューターでローカルの変更が繰り返し元に戻る場合、ドメインの GPO がそれらを上書きしています。この修正にはグループ ポリシー管理コンソールへのアクセスが必要で、通常はドメイン コントローラーまたは RSAT がインストールされたコンピューターで利用できます。
-
サーバー マネージャー > ツール > グループ ポリシーの管理 から GPMC を開きます。
-
ドメインを展開し、対象のコンピューターを制御している GPO を右クリックして、編集を選択します。
-
コンピューターの構成 > ポリシー > Windows の設定 > セキュリティの設定 > ローカル ポリシー > ユーザー権利の割り当てに移動します。
-
Allow logon through Remote Desktop Services を開き、Remote Desktop Users と Administrators の両方が一覧に表示されていることを確認します。
-
「リモート デスクトップ サービスを介したログオンを拒否」を開き、影響を受けるアカウントおよびそのグループが一覧に含まれていないことを確認します。
-
変更を保存してから、対象のマシンで次を実行してください: gpupdate /force
該当する GPO がすぐに明らかでない場合は、影響を受けているコンピューターで次を実行し、生成されたファイルを開いて、どのポリシーがユーザーの権利の割り当てを制御しているかを特定してください:
gpresult /h gpreport.html
対処法 5: 資格情報マネージャーから古くなった保存済みの資格情報を削除する
これはあまり一般的な原因ではありませんが、グループ メンバーシップとポリシー設定が正しいことを確認したうえで、確認しておく価値があります。保存された RDP 資格情報は、パスワードの変更、アカウントの移行、RDS プールの変更などの後に古くなることがあります。場合によっては、承認エラーに似たログイン失敗を引き起こします。長年にわたり保存された資格情報を使用していた RDS プールで、突然すべてのユーザーで失敗が発生したという Microsoft Q&A のスレッドに記録されている対処法は、保存されたエントリをクリアして資格情報を手動で再入力することでした。
-
コントロール パネルを開き、ユーザー アカウントに移動して、資格情報マネージャーをクリックします。
-
Windows 資格情報を選択します。
-
TERMSRV/で始まり、その後にリモートPCのマシン名またはIPアドレスが続くエントリを探してください。
-
該当する各項目を展開し、削除をクリックします。
-
資格情報マネージャーを閉じ、再度 RDP 接続を試み、プロンプトが表示されたら資格情報を手動で入力してください。
対処法 6：RDP を修正している間、無料の代替手段として HelpWire を使用する
権限エラーが今すぐ必要なマシンへのアクセスを阻んでいる場合、HelpWire を使えば、ポリシー構成を調整している間も動作するリモート接続を確保できます。これは Windows Remote Desktop サービスやポート 3389 を使用しないため、”user account not authorized” エラーを引き起こすグループ メンバーシップやユーザー権利の問題の影響を受けません。
HelpWire は Windows、macOS、Linux で動作し、無料で利用できます。セットアップは数分で完了します: 自分のマシンにオペレーター クライアントをインストールし、リモート マシンに HelpWire エージェントをインストールして、接続します。管理しているマシンへの無人アクセス用に、エージェントをバックグラウンド サービスとして実行するよう設定でき、リモート側で各接続を都度承認してもらう必要はありません。
よくある質問
管理者アカウントはローカルの Administrators グループに属しており、Windows はこのグループを常に Allow log on through Remote Desktop Services ポリシーに含めます。標準ユーザー アカウントは既定では Remote Desktop Users にも Allow log on through Remote Desktop Services ポリシーにも追加されないため、両方が明示的に構成されるまでアクセスは拒否されます。
はい。ドメイン、サイト、または OU レベルで適用されたドメイン GPO の設定は、グループ ポリシーの更新のたびにローカルの secpol.msc の設定を上書きします。ローカルでの修正が元に戻ってしまう場合は、競合する GPO が有効になっています。GPMC を使用してドメイン レベルで対処し、影響を受けるマシンで gpresult /h gpreport.html を実行して、どのポリシーがユーザー権利の割り当てを制御しているかを特定してください。
それに記載されているアカウント、またはそのアカウントを含むグループからの RDP 経由での接続をブロックします。拒否ポリシーは、リモート デスクトップ サービス経由でのログオンを許可する」設定と「リモート デスクトップ ユーザー」グループのメンバーシップの両方よりも優先されます。たとえば、多くの堅牢化された環境では既定で拒否ポリシーに含められている「ゲスト」グループに所属していることなどにより、アカウントが誤って拒否グループに入ってしまう場合があります。
“ユーザー アカウントがリモート ログオンを許可されていないため、接続が拒否されました” は、セッション要求が対象のコンピューターに到達したものの、認可レイヤーで拒否されたことを意味します。典型的な原因は、必要なグループ メンバーシップの欠如、ユーザー権利の割り当てポリシーの不備、または明示的な拒否ポリシーの有効化です。”アクセスが拒否されました” はより広い意味を持ち、Credential Guard の制限、SAM へのアクセス制限、またはリモート ログオン権限とは直接関係のない一般的なアクセス許可の問題を示す場合もあります。この違いは、たどるべきトラブルシューティングの経路が異なるため、重要です。
