注記: Windows Hello for Business は、Microsoft Intune または Active Directory 証明書サービスを介した証明書ベースの展開によって RDP サインインをサポートする、企業向けの別個の機能です。これには PKI インフラストラクチャ、証明書の展開、ドメイン コントローラー証明書が必要です。これは標準的なコンシューマーまたは SMB のセットアップでは利用できず、ここで説明しているコンシューマー向け PIN のシナリオとは無関係です。
方法A: 資格情報マネージャーでエントリを削除する
-
接続元のコンピューターで、資格情報マネージャーを開きます。スタートで検索するか、
control /name Microsoft.CredentialManagerを実行します。 -
Windows 資格情報をクリックします。
-
TERMSRV/で始まり、リモートマシンの名前またはIPアドレスが続くすべてのエントリを見つけてください。 -
各項目をクリックしてから、削除をクリックします。
-
再接続してください。Windows が新しい資格情報の入力を求めます。
方法 C: 保存した資格情報が保持されない場合は、汎用資格情報を手動で追加する
一部の構成では、セッション間で RDP 資格情報が保持されません。資格情報マネージャーで汎用資格情報のエントリを直接追加すると、Windows にそれを使用するよう強制できます。
-
資格情報マネージャー > Windows 資格情報を開きます。
-
汎用資格情報の追加 をクリックします。
-
インターネットまたはネットワーク アドレスに、
TERMSRV/の後にリモート コンピューターのホスト名または IP アドレスを続けて入力します。例:TERMSRV/103.27.76.117またはTERMSRV/COMPUTERNAME。 -
ユーザー名とパスワードを入力してください。
-
OK をクリックし、資格情報マネージャー を閉じて、再接続してください。
対処法 4: ユーザーをリモート デスクトップ ユーザー グループに追加し、ログオン権限を確認する
アカウントは、対象コンピューター上の Remote Desktop Users グループまたは Administrators グループのいずれかに属している必要があります。 Event ID 4625 にサブステータス 0xC000015B がある場合は、ユーザーに必要なログオンの種類が付与されていないことが確認されます。 グループ メンバーシップだけでは、ユーザー権利の割り当てで明示的な拒否によって依然としてブロックされる可能性があります。
-
対象のマシンで、管理者として次のコマンドを実行します:
net localgroup "Remote Desktop Users" /add "DOMAIN\username"または PowerShell で:Add-LocalGroupMember -Group "Remote Desktop Users" -Member "DOMAIN\username" -
ファイル名を指定して実行を開き、
secpol.mscと入力します。 -
ローカル ポリシー > ユーザー権利の割り当てに移動します。
-
リモート デスクトップ サービスを介したログオンを許可をダブルクリックします。
-
ユーザーまたはグループの追加 をクリックします。
-
アカウント名を入力して、OKをクリックします。
-
同じ一覧で、リモート デスクトップ サービスを介したログオンを拒否のエントリにユーザーまたはそのグループが含まれていないか確認してください。明示的な拒否エントリは削除してください。
対処法 5: 接続元のコンピューターで資格情報の委任に関するグループ ポリシーを修正する
接続元のコンピューターで資格情報の委任ポリシーが資格情報の転送方法を制限している場合、正しいパスワードであっても RDP クライアントは認証を通過できません。これはすべてのアカウント種別に当てはまり、リモート デスクトップで資格情報が機能しない原因として最も見落とされがちなものの一つです。対処はリモート側ではなくクライアント側のコンピューターで行います。
-
接続元のマシンで、ファイル名を指定して実行を開き、
gpedit.mscと入力します。 -
コンピューターの構成 > 管理用テンプレート > システム > 資格情報の委任 に移動します。
-
保存された資格情報の委任を拒否する を
未構成に設定します。 -
新しい資格情報の委任を拒否する を
未構成に設定します。
-
Allow delegating saved credentials with NTLM-only server authentication を開きます。
有効に設定します。
-
リストにサーバーを追加の横にある表示をクリックし、
TERMSRV/*を入力します。OKをクリックします。
-
手順 5 を次の項目について繰り返します： 保存された資格情報の委任を許可する、NTLM のみのサーバー認証で新しい資格情報の委任を許可する、および 新しい資格情報の委任を許可する。
-
次の場所に移動します コンピューターの構成 > 管理用テンプレート > Windows コンポーネント > リモート デスクトップ サービス > リモート デスクトップ接続 クライアント.
-
パスワードの保存を許可しない を
未構成に設定します。 -
クライアント コンピューターで資格情報の入力を求める を
未構成に設定します。
-
グループ ポリシー エディターを閉じ、管理者権限のコマンド プロンプトで
gpupdate /forceを実行します。
対処法 6: 対象のコンピューターでグループ ポリシーを使用して RDP のセキュリティ レイヤーを変更する
他の解決策がすべて失敗した後、この修正で解決したと複数のユーザーが確認しています。クライアントとターゲットの間でネゴシエートされるセキュリティ層が合意に至らない場合、資格情報が完全に評価される前に認証が拒否されます。
-
対象のコンピューターで、ファイル名を指定して実行を開き、
gpedit.mscと入力します。 -
コンピューターの構成 > 管理用テンプレート > Windows コンポーネント > リモート デスクトップ サービス > リモート デスクトップ セッション ホスト > セキュリティ に移動します。
-
リモート (RDP) 接続で特定のセキュリティ レイヤーの使用を要求するを開きます。
-
Enabledに設定します。ドロップダウンで、RDP を セキュリティ層 として選択します。
-
OK をクリックしてから、管理者権限で開いたコマンド プロンプトで
gpupdate /forceを実行します。
対処法 7: ターゲット マシンで “Always Prompt for Password” を無効にする
このポリシーがリモート コンピューターで有効になっている場合、クライアント上の保存された資格情報を上書きし、再認証のプロンプトを強制します。そのプロンプトはサイレントに失敗し、パスワード ダイアログが表示されるのではなく、資格情報エラーになります。
-
対象のコンピューターで、ファイル名を指定して実行を開き、
gpedit.mscと入力します。 -
コンピューターの構成 > 管理用テンプレート > Windows コンポーネント > リモート デスクトップ サービス > リモート デスクトップ セッション ホスト > セキュリティ に移動します。
-
接続時に常にパスワードの入力を求める を開きます。
-
無効または未構成に設定します。
-
サインアウトしてサインインし直すか、
gpupdate /forceを実行してください。
対処法 9: 対象マシンで LAN Manager 認証レベルを設定する
接続元マシンとリモートマシンの間の認証レベルの不一致により、パスワードの正誤にかかわらず、NTLMネゴシエーション層で資格情報が拒否されます。
-
対象のコンピューターで、ファイル名を指定して実行を開き、
gpedit.mscと入力します。 -
コンピューターの構成 > Windows の設定 > セキュリティの設定 > ローカル ポリシー > セキュリティ オプションに移動します。
-
ネットワーク セキュリティ: LAN Manager 認証レベル を開きます。
-
次の3つの動作確認済みの値のいずれかに設定してください:
Send NTLMv2 response only、Send NTLMv2 response only. Refuse LM、またはSend NTLMv2 response only. Refuse LM and NTLM。いずれを選んでも不一致は解消されます。まず試すべき最も制限が緩いオプションはSend NTLMv2 response onlyです。 -
OK をクリックします。
対処法 10: fDenyTSConnections レジストリ キーと RDP ポートを確認する
設定でRDPが有効になっているように見えるのに、接続が依然として失敗する場合、2つのレジストリ値がUI設定を上書きしている可能性があります。Microsoftは、fDenyTSConnectionsを、リモート デスクトップ サービスを使用してユーザーがリモートで接続できるかどうかを制御する設定として文書化しています。
-
管理者としてレジストリ エディター（
regedit.exe）を開きます。 -
次の場所に移動:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server
-
fDenyTSConnectionsが0に設定されていることを確認してください。 -
こちらも確認してください:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services。ここにfDenyTSConnectionsが1に設定された状態で表示される場合、グループ ポリシーがブロックを強制しています。ローカルの値を変更しても維持されません。GPO はソースで修正する必要があります。 -
RDP ポートが既定値から変更されていないことを確認するには、次の場所に移動します:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-tcp
-
PortNumberを見つけてください。表示基数をDecimalに切り替えてください。
-
値は
3389である必要があります。そうでない場合は、RDP クライアントは代わりにそのカスタムポートに、hostname:PORTの形式で接続する必要があります。
修正 11: 対象アカウントの空のパスワードに対処する
Windows は、パスワードが設定されていないアカウントに対して既定で RDP をブロックします。これは RDP の設定ではなく、ローカル セキュリティ ポリシーによる制限です。
-
ファイル名を指定して実行 を開き、
gpedit.mscと入力します。 -
コンピューターの構成 > Windows の設定 > セキュリティの設定 > ローカル ポリシー > セキュリティ オプションに移動します。
-
アカウント: 空のパスワードを持つローカル アカウントの使用をコンソール ログオンのみに制限する を開きます。
-
それを
Disabledに設定します。
プロのヒント: リモートで管理するすべてのマシンには、Microsoft Account のサインインを使用しない専用のローカル管理者アカウントを1つ保持してください。MSA、PIN、または証明書の問題で RDP がブロックされた場合でも、ローカルアカウントなら MSA の資格情報パイプラインを完全にバイパスでき、アクセス手段を確保できます。
複数のマシンでリモート作業を行う IT サポートチームにとっては、RDP と併用するツールとして HelpWire を用意しておく価値があります。セッションは、リモートユーザーにシステム設定を操作させるのではなく、リンクから開始できます。つまり、リモートマシンで RDP の認証に失敗しても、サポートセッションの開始が妨げられません。ローカル管理者の資格情報は、あなた自身のマシンの Credential Manager にキャッシュするのではなく、パスワードマネージャーに保管してください。
