リモートデスクトップ接続時に「認証エラーが発生しました。資格情報が正しくありません」や「リモートデスクトップは接続できませんでした」といったエラーが表示され、特に社内ネットワークにいるPCだけが接続できないケースがあります。このような現象は、ネットワークレベル認証(NLA)が有効な環境で発生しやすく、原因は接続元PCの設定やドメイン環境の構成、証明書の不一致など多岐にわたります。本記事では、社内PCのみNLAで弾かれる場合の原因を体系的に切り分け、管理者やユーザーが取るべき対応を具体的に解説します。
【要点】この記事で確認すること
- 最初に見る場所: 接続元社内PCの「リモートデスクトップ」設定とNLAの有効状態、および接続先サーバーのNLA要件。
- 切り分けの軸: 端末側(OS設定・証明書・資格情報)、ネットワーク側(ファイアウォール・VPN・プロキシ)、アカウント側(ドメイン資格・認証方式)、管理設定側(グループポリシー・レジストリ)。
- 注意点: 会社PCではグループポリシーやセキュリティポリシーが適用されているため、勝手にレジストリやサービスを変更するとドメインログオンに影響する場合があります。必ず管理者に確認してから対処してください。
ADVERTISEMENT
目次
1. NLAとは何か:社内PCだけ弾かれるメカニズム
ネットワークレベル認証(NLA)は、リモートデスクトップ接続の際に完全なセッションを確立する前にユーザー認証を完了させる機能です。NLAが有効な接続先では、クライアントがCredSSP(Credential Security Support Provider)プロトコルを使用してサーバーと認証情報をやり取りします。外部からのアクセスには有効ですが、社内ネットワーク内のPCから接続する場合、認証に必要な証明書やKerberos構成の違いが原因で弾かれることがあります。
典型的なシナリオとして、「社内Wi-Fiに接続したノートPCからサーバーへRDPできないが、スマホのテザリング経由では接続できる」という現象があります。これは、社内ネットワークがドメイン環境や特定の認証方式を要求する一方、外部ネットワークではNTLMや基本認証がフォールバックとして機能するためです。また、クライアントのCredSSPのバージョンやグループポリシーが原因で、社内PCだけNLAに失敗するケースが頻繁に報告されています。
2. 原因を切り分けるためのチェックポイント
問題の原因を特定するには、以下の3つの視点で確認を進めてください。それぞれに具体的な確認項目を挙げます。
2-1. 接続元PC側の設定
- NLAの有効状態: コントロールパネル → システム → リモート設定で、「ネットワークレベル認証を使ってリモートデスクトップを実行しているコンピュータからのみ接続を許可する」がオンになっているか確認します。社内PCのみオフになっていると、NLA要件が不一致で弾かれる場合があります。
- CredSSPのバージョン: レジストリキー
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters\AllowEncryptionOracleの値が2(脆弱性修正済み)や0(強制)の場合、古い接続先と互換性がなくなることがあります。管理者ポリシーで書き換えられていないか確認してください。 - 証明書の信頼: 接続先サーバーが自己署名証明書を使用している場合、社内PCがその証明書を信頼していないとNLAで弾かれます。特にドメイン参加PCでは、グループポリシーで信頼されたルート証明機関のみ許可する設定があると、自己署名証明書がブロックされます。
- 資格情報マネージャー: 保存された古い資格情報がRDP接続時に誤って使用され、認証失敗を引き起こすことがあります。Windowsの資格情報マネージャーで該当サーバーのエントリーを削除してから再試行してください。
2-2. 接続先サーバー側の設定
- NLAの強制: サーバーのシステムプロパティ → リモートで「ネットワークレベル認証を使ってリモートデスクトップを実行しているコンピュータからのみ接続を許可する」がオンになっている必要があります。オフになっている場合、クライアント側のNLA設定と矛盾することがあります。
- 認証方式の制限: サーバーのローカルセキュリティポリシーまたはグループポリシーで「ネットワークアクセス: ローカルアカウントの共有とセキュリティモデル」が「ゲストのみ」や「クラシック – ローカルユーザーとして認証」に設定されていると、ドメインユーザー以外が弾かれます。
- ファイアウォールの例外: 社内ネットワークからのRDP接続は通常3389ポートを使用しますが、NLAでは追加でRPCエンドポイントマッパー(135)やKerberos(88)が必要になる場合があります。ファイアウォールでこれらのポートがブロックされていないか確認します。
2-3. ネットワークとドメイン環境
- DNS名前解決: 社内PCが接続先サーバーのFQDNを正しくIPアドレスに変換できない場合、Kerberos認証が失敗しNLAが弾かれます。コマンドプロンプトで
nslookup サーバーFQDNを実行し、正しいIPが返るか確認してください。 - Kerberosチケットの有効性: 社内PCのドメインアカウントのKerberosチケットが期限切れや破損していると、NLAが要求するKerberos認証に失敗します。
klistコマンドでチケットの有無を確認し、klist purgeでクリア後に再試行します。 - ネットワークプロファイル: 社内ネットワークが「パブリック」ネットワークとして認識されている場合、WindowsファイアウォールがRDPをブロックすることがあります。ネットワークプロファイルを「ドメイン」または「プライベート」に変更してください。
3. 状況別の比較表:社内PCのみ発生 vs 全端末で発生する場合
| 症状 | 社内PCのみ発生 | 全端末で発生 |
|---|---|---|
| エラーメッセージ | 「認証エラーが発生しました。資格情報が正しくありません」または「リモートデスクトップは接続できませんでした」 | 「リモートデスクトップライセンスサーバーがない」や「リモートコンピュータが見つかりません」 |
| 主な原因 | CredSSPの不一致、証明書非信頼、Kerberosチケット問題、グループポリシー | サーバー自体のNLA無効、ライセンス切れ、RDPサービス停止、ネットワーク障害 |
| 確認すべき設定 | クライアントのCredSSPレジストリ、証明書ストア、資格情報マネージャー、ネットワークプロファイル | サーバーのNLA設定、RDPポート開放、サービスの状態、ライセンス診断 |
| 対処例 | レジストリ修正(AllowEncryptionOracle)、証明書インストール、Kerberosチケット更新、グループポリシー確認 | サーバー側のNLA有効化、ポート開放、ライセンスサーバー追加、RDPサービスの再起動 |
4. 具体的なトラブルシューティング手順
以下の手順を順に実行し、問題の切り分けを行ってください。
- 手順1:接続元PCのNLA設定を確認する – 「システムのプロパティ」→「リモート」タブを開き、「ネットワークレベル認証を使ってリモートデスクトップを実行しているコンピュータからのみ接続を許可する」チェックボックスがオンになっていることを確認します。オフになっている場合はオンにして再試行。
- 手順2:CredSSPのレジストリ設定を確認する – レジストリエディターで
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parametersに移動します。AllowEncryptionOracleの値が2の場合は、0または1に変更(管理者承認が必要)。変更後はPCを再起動。 - 手順3:Kerberosチケットを更新する – コマンドプロンプトを管理者として実行し、
klist purgeと入力して既存のチケットをクリア。その後、klistで新しいチケットが取得できているか確認。 - 手順4:資格情報マネージャーをクリアする – コントロールパネル→「資格情報マネージャー」→「Windows資格情報」で、該当サーバー名のエントリーを削除。その後RDPを再試行。
- 手順5:ネットワークプロファイルを確認する – 「設定」→「ネットワークとインターネット」→「Wi-Fi」→プロパティで、ネットワークプロファイルが「ドメイン」または「プライベート」になっているか確認。「パブリック」の場合は変更。
- 手順6:接続先サーバーの証明書を確認する – RDP接続時に表示される証明書の警告をクリックし、発行元が信頼されているか確認。自己署名証明書の場合は、クライアントの信頼されたルート証明機関に追加する。
- 手順7:グループポリシーの一時遮断を確認する – 管理者に依頼し、
gpresult /h gp.htmlで適用されているポリシーを確認。「コンピューターの構成→管理用テンプレート→Windowsコンポーネント→リモートデスクトップサービス→リモートデスクトップセッションホスト→セキュリティ」で「リモート接続にNLAを使用する」が有効になっているか確認。
5. よくある失敗パターンと対処法
実際に多くのサポート事例で報告されている失敗パターンをまとめました。
パターン1:CredSSPの脆弱性修正によるブロック
2018年のセキュリティ更新プログラム以降、WindowsはCredSSPの脆弱性(CVE-2018-0886)に対応するため、クライアントとサーバー間のバージョン不一致を厳格にチェックするようになりました。社内PCのみ古いパッチのまま、またはレジストリのAllowEncryptionOracleがデフォルトの0(修整)になっていると、サーバー側が更新済みの場合に認証が拒否されます。対処として、社内PCに最新の更新プログラムを適用するか、管理者の承認のもとAllowEncryptionOracleを1(脆弱)に一時的に変更します。
パターン2:自己署名証明書が信頼されていない
検証目的で構築されたサーバーが自己署名RDP証明書を使用している場合、ドメイン参加PCはグループポリシーで信頼されたルート証明機関以外の証明書を拒否します。社内PCだけエラーになるのは、外部PCは証明書警告を無視できるからです。解決策は、サーバーに正規の証明書(内部CA発行)をインストールするか、クライアント側の信頼されたルートに証明書を追加することです。
パターン3:ネットワークプロファイルがパブリック
社内ネットワークが「パブリック」として認識されると、WindowsファイアウォールがRDP接続をブロックします。特に、社内LANに接続した際にネットワークプロファイルが正しくドメインに認識されない場合に発生します。対処として、ネットワーク設定からプロファイルを「プライベート」または「ドメイン」に変更します。なお、ドメイン参加PCでは通常自動的にドメインプロファイルになりますが、DNSサフィックスが正しく設定されていないと認識されません。
6. 管理者に確認すべき情報と依頼内容
社内PCでNLAに弾かれる問題が発生した場合、以下の情報を管理者に伝えることで解決がスムーズになります。
- エラーの正確なメッセージ: 「認証エラーが発生しました。要求された関数はサポートされていません」や「CredSSPの暗号化オラクルの修整」といった具体的な文言を伝えます。
- 接続元PCのOSバージョンとパッチレベル:
winverで表示されるOSビルド番号と、インストール済みの更新プログラムの一覧(特にKBの番号)を伝えます。 - 接続先サーバーのOSバージョン: サーバー管理者に確認してもらい、同じくパッチレベルを伝えてください。
- ドメイン環境の有無: 社内PCがドメイン参加しているか、Active Directoryを使用しているかを明確にします。
- 他端末での接続可否: 同じネットワーク上の別のPCや、外部ネットワークからの接続結果を伝えると原因切り分けに役立ちます。
管理者への依頼内容としては、グループポリシーでNLA関連の設定(CredSSPの暗号化オラクルの修整ポリシー、証明書の信頼ポリシー)が適用されていないかの確認、または該当PCのみポリシーの適用除外を一時的に試験することを提案します。
7. よくある質問(FAQ)
Q1. NLAを無効にすれば問題は解決しますか?
会社PCでは、ファイアウォールやウイルス対策ソフトを自己判断で無効にしないでください。接続先、表示されたエラー、利用中の回線を記録し、会社のIT部門へ確認します。
Q2. レジストリのAllowEncryptionOracleを変更しても問題ありませんか?
この設定はセキュリティに直接関わるため、通常は管理者のみが変更すべきです。特にドメイン環境ではグループポリシーによって強制されるため、個別のレジストリ変更はポリシーで上書きされる場合があります。変更前に必ずIT部門に相談してください。
Q3. 外部ネットワークからは接続できるのに社内からだけ接続できないのはなぜですか?
外部ネットワーク経由では、VPNやDirectAccessなどを使用している場合、別の認証方式(NTLMなど)がフォールバックとして機能することがあります。社内ネットワークではKerberos認証が優先され、その設定不備が原因で弾かれている可能性が高いです。特にCredSSPのバージョン不一致やKerberosチケットの問題を重点的に調査してください。
Q4. グループポリシーが原因の場合、自分で解除できますか?
ローカルグループポリシーエディターで一部設定を変更できる場合がありますが、ドメインポリシーが優先されるため、実質的には管理者によるポリシー変更が必要です。自分で解除しようとするとポリシーの競合が発生し、予期しない動作を引き起こす可能性があります。
まとめ
リモートデスクトップのNLAで社内PCだけ弾かれる場合、ほとんどの原因はクライアント側のCredSSP設定、Kerberosチケットの状態、証明書の信頼、またはネットワークプロファイルにあります。最初にレジストリのAllowEncryptionOracleと資格情報マネージャーを確認し、次にKerberosチケットの更新やネットワークプロファイルの変更を行うことで多くの問題が解決します。それでも改善しない場合は、グループポリシーやセキュリティポリシーが影響している可能性が高いため、管理者にエラー内容と調査結果を伝えて対応を依頼してください。NLAはセキュリティ上有効な機能であるため、根本解決を目指すことが重要です。
超解決 第一編集部
疑問解決ポータル「超解決」の編集チーム。正確な検証と、現場視点での伝わりやすい解説を心がけています。
Office・仕事術の人気記事ランキング
- 【神技】保存せずに閉じたExcel・Wordファイルを復元する!消えたデータを復活させる4つの救出法
- 【Outlook】添付ファイルが「Winmail.dat」に化ける!受信側が困らない送信設定
- 【Word】差し込み印刷で数字の桁を整える!金額にカンマ(桁区切り)を入れる設定
- 【Teams】メッセージを「保存済み」にして後で読む!重要なチャットをブックマークして整理する技
- 【Excel】文字が入っているセルの「個数」を数える!COUNTA関数の簡単な使い方
- 【Word】校閲機能の基本!赤字(変更履歴)とコメントで修正を見える化する
- 【PDF】PDFに入力した文字の「フォント・サイズ・色」を変更するプロパティ設定
- 【Copilot】「サービスに接続できません」エラーの原因切り分けと対処法
- 【Outlook】予定表の「祝日」が表示されない!最新カレンダーの追加と二重表示の修正手順
- 【Teams】画面共有時に「音声」も共有する方法!音が流れない時の設定手順
