リモートデスクトップ接続時、ログインできるコンピューターがシステム管理者により制限されています。と表示される場合の対処方法

リモートデスクトップで接続できない！？

リモートデスクトップを使って別のPCに接続し、遠隔操作をしようとしたところ、以下のようなエラーが表示されてしまい、接続できないことがあります。

リモート デスクトップ接続

ログインできるコンピューターがシステム管理者により制限されています。
別のコンピューターにログインしてみてください。

問題が解決されない場合は、システム管理者かテクニカル サポートに問い合わせてください。

(リモート デスクトップ接続時のエラーメッセージより引用)

このエラーはいくつかの条件が重なると表示される比較的珍しいメッセージのため、ネット上でも情報が少なく対処に困っている方も多いはず。

そこで今回はこの『ログインできるコンピューターがシステム管理者により制限されています。別のコンピューターにログインしてみてください。』というエラーに対処し、リモートデスクトップで接続可能とできるかもしれない方法をご紹介します！

エラーが発生する条件

このエラーはたとえば、以下のような設定・条件でリモートデスクトップ接続を試みた際に発生します。

• リモートデスクトップが可能となるような権限(『リモート デスクトップ サービスを使ったログオンを許可』ポリシーの構成、Remote Desktop Usersに追加するなど)周りの設定や、ファイアーウォールの設定が適切にできている。
• 接続を行うユーザーは、接続先PCにログオン可能な資格情報(ログインIDやパスワード)を把握している。
• リモートデスクトップの接続先がActive Direcotryドメインに参加しているドメインコンピューターである。
• リモートデスクトップの認証に、NLA(ネットワークレベル認証※詳細は後述)を使用している。(NLAを有効にしている)
• リモートデスクトップで接続する際に使用するユーザーアカウントに対して、ログオン先の設定が行われている。(ログオン先が制限されている)

具体的には、以下のようなケースが条件に該当します。

• 2台のPC、XとYが存在し、リモートデスクトップによる接続を行うPC(リモートデスククライアント)をPC_X。
  リモートデスクトップによる接続を受けるPC(リモートデスクトップホスト)をPC_Yとする。
• リモートデスクトップによる接続を行う際に使用するユーザーアカウントは、USER_Aとする。(USER_Aは、PC_Xへのログオンには使用しない。)
  USER_Aには、ログオン先(ログオンできるワークステーション)としてPC_Yのみを設定している。
• リモートデスクトップクライアントであるPC_X自体にログオンするユーザーは、すべてのコンピューターにログオン可能なユーザー、USER_Bとする。
• リモートデスクトップホストPC_Yは、リモートデスクトップによる接続を許可している。
  ただしNLA(ネットワークレベル認証※詳細は後述)でリモートデスクトップを実行しているPCからのみ、接続を許可する設定となっている。

以上の条件でPC_XからPC_Yに、USER_Aを使用してリモートデスクトップによる接続を行った際にエラーが発生します。

エラーの原因

このエラーは、USER_Aに設定しているログオン先の制限と、NLA(ネットワークレベル認証)の組み合わせにより発生しています。

そのため、これらの組み合わせをエラーが出ない組み合わせとすればエラーが発生しなくなり、リモートデスクトップによる接続が正常に行えるようになります。

そしてこのエラーを解決する方針は大きくは2つ。

ログオン先の制限をゆるめるか、NLA(ネットワークレベル認証)を無効化するか、これらのどちらかの対応を行う必要があります。

ログオン先の制限をゆるめてエラーを解決する方法

リモートデスクトップホストが、NLA(ネットワークレベル認証)でリモートデスクトップを実行しているPCからのみ接続を許可する設定の場合、リモートデスクトップ接続に使用するユーザーが、リモートデスクトップクライアントとリモートデスクトップホスト双方にログオン可能である必要があります。

そのためNLA(ネットワークレベル認証)を有効としたままエラーを解決する場合、以下の2つの対処が考えられます。

ログオン先の制限を解除する

この方法では、USER_Aに設定しているログオン先(ログオンできるワークステーション)の設定を『すべてのコンピューター』に変更します。

これによりUSER_Aに適用されていたログオン先の制限が解除され、USER_Aによる(USER_Aの資格情報を使用した)PC_XからPC_Yへのリモートデスクトップが可能となります。
※PC_XへのログオンはUSER_A、USER_Bのどちらでも構いません。

ログオン先にリモートデスクトップクライアントを追加する

ログオン先の制限を解除する方法では、USER_Aに対してすべてのコンピューターへのログオンを許可することになります。

これが運用上問題となる場合には、USER_Aのログオン先(ログオンできるワークステーション)にPC_Xを追加してください。

以上のような設定により、リモートデスクトップ接続に使用するユーザーが、リモートデスクトップクライアントとリモートデスクトップホスト双方にログオン可能な状態とすれば、リモートデスクトップによる接続が可能となるはずです。

NLA(ネットワークレベル認証)を無効化する方法…でもその前に知っておくべきこと

先にご紹介したログオン先の制限をゆるめてエラーを解決する方法は、簡単でとてもお手軽な対処方法です。
ですがこの方法は、運用上の問題となることも多いでしょう。

というのも、そもそもUSER_Aのログオン先をPC_Yのみに制限したのには、何らかの理由があるはず。
だからUSER_Aにあらかじめ設定しておいたログオン先の制限をゆるめることはできない、ということの方が多いんじゃないでしょうか。

この場合にはどうにもできないのかというと、そうではありません。
このケースでは、NLA(ネットワークレベル認証)を無効化することで、リモートデスクトップ接続が可能となります。

ただNLA(ネットワークレベル認証)を無効化すれば接続可能になると言われても、名前から認証に関係しそうな機能であることは間違いない…。
となると、認証に関わることなのでセキュリティーレベルの低下につながらないか心配である。

そのためNLA(ネットワークレベル認証)を無効化して良いのかどうか、判断がつかない！
というように考えてしまう方もいらっしゃると思います。

そこでまずはNLA(ネットワークレベル認証)について少しご紹介します。

NLA(ネットワークレベル認証)とは？

NLA(Network Level Authentication = ネットワークレベル認証)については、MicrosoftさんのTechNetに詳しく書かれているので、以下に一部を引用します。

ネットワーク レベル認証は、セッションが作成される前に RD セッション ホスト サーバーに対してユーザー認証を要求して、RD セッション ホスト サーバーのセキュリティを強化するために使用する認証方法です。

ネットワーク レベル認証は、リモート デスクトップ接続の確立とログオン画面の表示が行われる前にユーザー認証を完了します。

これは、リモート コンピューターを悪意のあるユーザーやソフトウェアから保護するのに役立つ、より安全性の高い認証方法です。

ネットワーク レベル認証の利点は次のとおりです。

• 最初に必要なリモート コンピューターのリソースが少なくて済みます。
  ユーザーを認証する前には、リモート コンピューターでは以前のバージョンのように完全なリモート デスクトップ接続が開始されず、限られた数のリソースしか使用されません。
• サービス拒否攻撃のリスクを低減することができ、セキュリティの強化に役立ちます。

(Microsoft – リモート デスクトップ サービス接続のネットワーク レベル認証を構成するより引用)

これらを読むと、とりあえず『より安全性の高い認証方法』なんだな、というようなことは分かると思います。

ただどうして『より安全なのか』。
また、もう一つのメリットとして挙げている『リモート コンピューター(リモートデスクトップホスト)のリソースが少なく済む』のはなぜか。

これらを理解するのは、上記文面を読むだけではちょっと難しいかもしれません。

ポイントは事前認証！

NLA(ネットワークレベル認証)の最大の特徴は、実は先の解説中に書いてある『リモート デスクトップ接続の確立とログオン画面の表示が行われる前にユーザー認証を完了』することなんです。(事前認証)

そしてこの特徴により、先の2つのメリットが発生しているんです！

NLAを有効にしている(NLAでリモートデスクトップを実行しているコンピューターからのみ接続を許可しているリモートデスクトップホストの)場合、リモートデスクトップセッションが開始(確立)される前に、リモートデスクトップクライアントに資格情報を要求します。

そして提示された資格情報がリモートデスクトップホストへのリモートデスクトップ接続を許可されている場合にのみ、リモートデスクトップセッションが開始されます。

つまり接続できるかどうか確認ができるまではリモートデスクトップセッションを開始せず、認証に必要な最低限の通信のみを行うにとどめる。
これにより処理コストの高いリモートデスクトップセッションの開始処理をムダに行わずにすむ、というわけ。

これに対してNLA(ネットワークレベル認証)が無効のケースでは、とりあえずまずは『リモートデスクトップセッションを開始 = ログオン画面を表示』してから資格情報を確認するため、ムダな処理を多く行ってしまう可能性があります。(接続を許可されていないユーザーに対しても、リモートデスクトップセッションを開始してしまうため。)

最近の高性能なPCやサーバーであれば、リモートデスクトップセッションの開始処理一つ一つは、さほど大きな処理コストを発生させるわけではありません。

ですがたとえば外部に公開されているリモートデスクトップホストで、接続経路の途中にリモートデスクトップの接続元を制限するようなファイアーウォールなどの設定が行われていない場合、NLA(ネットワークレベル認証)が無効のケースでは、同時に多数のリモートデスクトップセッションの開始処理が発生し、大きな負荷がかかってしまう可能性があります。

この特性を利用すれば、悪意のあるユーザーがサービス拒否(DoS)攻撃を行い、リモートデスクトップホストをダウンさせることができるかもしれません。

ところがNLA(ネットワークレベル認証)が有効であれば、リモートデスクトップ接続を許可されていることを確認した場合にのみ、リモートデスクトップセッションが開始されるため、サービス拒否(DoS)攻撃に一定の防御効果を期待できます。

これらを簡潔に書いたのが、先のMicrosoftさんのTechNetで挙げていた2つの利点となります。

またこれらについての詳細は、TechNet内の別のページでもふれられていますので、併せてご覧いただくと良いでしょう。(以下は2つのメリットについての解説部分の引用。)

セッションを作成する前に資格情報を提示するのが良いことである理由を説明しましょう。

接続を試行しているユーザーに接続する権利があるかどうかを確認するまでセッションを作成しない主なメリットは 2 つあります。

それは、サービス拒否 (DoS) 攻撃に対する防御層を提供することと、仲介の処理速度を上げられることです。

セッションを開始するには (単にログオン画面を表示するだけでも)、サーバー側で、セッションをサポートするのに必要な多くのプロセス (Csrss.exe や Winlogon.exe など) を作成する必要があります。
そのため、セッションの作成には、コストと時間がかかります。

多数の権限のないユーザーが同時にセッションへの接続を試行すると、サーバーでは、不正なログイン資格情報を受け取るためにセッションを作成するため、他のユーザーがサーバーを使用できなくなる可能性があります。

(Microsoft – Windows Server 2008 R2: ネットワーク レベル認証を使用すべき理由より引用)

NLA(ネットワークレベル認証)を無効化しても良いのか

これは運用環境によるので一概には言えません。

ただNLA(ネットワークレベル認証)を無効化することで2つのメリットが失われることが許容されるのであれば、NLA(ネットワークレベル認証)を無効化しても大きな問題は起こらないはずです。

たとえば会社内のネットワークに、リモートデスクトップクライアントとリモートデスクトップホストが存在し、外部ネットワークからの接続はすべてブロックしている場合。(社内に攻撃者はいないだろう、という前提。)
または外部ネットワークからのリモートデスクトップホストへの接続要求は、UTMやルーターといった機材のパケットフィルタリング機能などで適切に制御されているということであれば、NLA(ネットワークレベル認証)を無効化しても、大きな問題にはならないでしょう。

NLA(ネットワークレベル認証)を無効化する方法

さて、ここまでの説明でNLA(ネットワークレベル認証)を無効化しても良いか判断できるようになったはずなので、最後にNLAを無効化する方法について。

これはグループポリシーの設定により行うのですが、OSのバージョンにより設定方法が異なり、現状では以下にご紹介する5パターンで対応可能です。(Windows 10から一部のポリシーの規定値が変更されているため。)

そのためOSのバージョンや運用ポリシーを検討し、設定する方法を決めていただければと思います。

NLA(ネットワークレベル認証)の無効化に関係するグループポリシーは3つ！

先ほどNLA(ネットワークレベル認証)を無効化する方法は5つある、と書きましたが、これは3つのポリシーの組み合わせによるもの。

そして3つのポリシーは、『コンピューターの構成』-『管理用テンプレート』-『Windows コンポーネント』-『リモート デスクトップ サービス』-『リモート デスクトップ セッション ホスト』-『セキュリティ』と階層をたどっていった中にある以下の3つ。

• クライアント接続の暗号化レベルを設定する
• リモート (RDP) 接続に特定のセキュリティレイヤーの使用を必要とする
• リモート接続にネットワーク レベル認証を使用したユーザー認証を必要とする

これらを組み合わせた設定をリモートデスクトップホスト(リモートデスクトップ接続を受ける側のPC)に設定することで、NLA(ネットワークレベル認証)を無効化します。

尚、暗号化レベルの詳細について気になる方は、Microsoftさんが公開している『サーバー認証と暗号化レベルを構成する』を参照ください。

リモートデスクトップホストがWindows 8.1 / Windows Server 2012 R2までの場合

リモートデスクトップホストがWindows 8.1、またはWindows Server 2012 R2までの場合、以下の3パターンの設定のうちのどれかを適用することで、NLA(ネットワークレベル認証)を無効化します。

パターン1

• クライアント接続の暗号化レベルを設定する → 『有効』かつ暗号化レベルを『低レベル』
• リモート接続にネットワーク レベル認証を使用したユーザー認証を必要とする → 『無効』

パターン2

• リモート (RDP) 接続に特定のセキュリティレイヤーの使用を必要とする → 『有効』かつセキュリティレイヤーを『RDP』
• リモート接続にネットワーク レベル認証を使用したユーザー認証を必要とする → 『無効』

パターン3

• クライアント接続の暗号化レベルを設定する → 『有効』かつ暗号化レベルを『低レベル』
• リモート (RDP) 接続に特定のセキュリティレイヤーの使用を必要とする → 『有効』かつセキュリティレイヤーを『RDP』
• リモート接続にネットワーク レベル認証を使用したユーザー認証を必要とする → 『無効』

リモートデスクトップホストがWindows 10の場合

リモートデスクトップホストがWindows 10の場合、以下の2パターンの設定のどちらかを適用することで、NLA(ネットワークレベル認証)を無効化します。

パターン1

• リモート (RDP) 接続に特定のセキュリティレイヤーの使用を必要とする → 『有効』かつセキュリティレイヤーを『RDP』
• リモート接続にネットワーク レベル認証を使用したユーザー認証を必要とする → 『無効』

パターン2

• クライアント接続の暗号化レベルを設定する → 『有効』かつ暗号化レベルを『低レベル』
• リモート (RDP) 接続に特定のセキュリティレイヤーの使用を必要とする → 『有効』かつセキュリティレイヤーを『ネゴシエート』
• リモート接続にネットワーク レベル認証を使用したユーザー認証を必要とする → 『無効』

暗号化レベル：低 = NLAの無効化ではありません！

設定に関連する3つのグループポリシーを見ていると、クライアント接続の暗号化レベルを設定する → 『低レベル』= NLAの無効化という印象を受けてしまいますが、そうではないのでご注意ください。

またこのNLA(ネットワークレベル認証)関連の仕様により、『リモート デスクトップ接続時にユーザーのパスワード変更ができない』現象が発生することがあります。
これは仕様にのっとった動作であり、NLAの無効化で解決できるかもしれません。

詳細はTechNetの『Windows Server 2012 R2 および Windows 8.1 以降のネットワーク レベル認証の動作について』に記載されているので、この現象でお困りの方は参照されると良いでしょう。