Windows Server 2022 RDSで解決！ドメインユーザーのRDP接続トラブル対応策

Windows Server 2022にリモートデスクトップサービス(RDS)を導入すると、ドメインユーザーからのリモートデスクトップ接続がうまくいかずに困ってしまうケースがあります。今回は、実際にRDSホストにはリモート接続ができるのに、そこからドメイン内の別サーバーへ接続するときにだけドメインユーザーが弾かれてしまう状況を想定し、その原因や解決策を詳しく解説します。多くのユーザーがRDSを利用する際に発生しやすいトラブルを網羅しながら、設定時のポイントや注意点も踏まえてお伝えします。

RDS導入直後に起こりがちなリモート接続のトラブル背景

Windows Server 2022でRDSを導入した直後、管理者アカウント(ローカルユーザー)では問題なくリモートデスクトップ接続ができるのに、ドメインユーザーだけが別サーバーにアクセスできないという症状は意外と多く報告されています。原因としてはライセンス周りの設定不足や、グループポリシーによる権限の問題、あるいはネットワーク レベル認証(NLA)の挙動などが挙げられます。また、評価版を導入中の場合、正式なRDS CAL(クライアントアクセスライセンス)を設定していないことが影響していることも少なくありません。
ここでは、実践的な対処方法としてライセンス設定やユーザー権限の見直し、NLAのチェックポイントなど、確認すべき項目を段階的に整理してみましょう。

ライセンスサーバーの確認とRDS CALの導入

リモートデスクトップサービス(RDS)には、一般的に「RDSライセンスサーバー」の存在が不可欠です。評価版を利用している場合でも、ライセンスサーバーの役割をインストールしていない、あるいはクライアントアクセスライセンス(CAL)を正しく登録していないと、ドメインユーザーでの接続に制限がかかる可能性があります。

RDSライセンスサーバーの役割を追加する

通常、RDS環境では以下の役割が必要とされます。

• リモートデスクトップ セッションホスト(RDSH)
• リモートデスクトップ ライセンスサーバー(RD Licensing)
• リモートデスクトップ ゲートウェイ(RD Gateway) (必要に応じて)
• リモートデスクトップ 接続ブローカー(RD Connection Broker) (必要に応じて)

評価版の段階でも、ライセンスサーバーの役割をインストールしておかないと、一定期間(グレース期間)が過ぎた後にドメインユーザーからの接続が制限される場合があります。まずは、サーバーマネージャーの「役割と機能の追加」からライセンスサーバーを正しくインストールし、RDSライセンスマネージャー上でライセンス(CAL)を登録する作業が必要です。

ライセンス認証の状態を確認する

ライセンスサーバーをインストールしたら、次の点を確認してみてください。

1. ライセンスサーバーが「アクティブ化されている」状態か
2. ユーザーCALまたはデバイスCALが適切な数だけ登録されているか
3. RDSHサーバーからライセンスサーバーとして認識されているか

特にRDSHサーバーの「RDSライセンス診断」ツールを使用すると、ライセンスサーバーが正しく認識されているかどうかが分かります。ここで「ライセンスサーバーが見つかりません」「ライセンスが不足しています」といったエラーが出るようであれば、ライセンス関連が原因の可能性が高いです。

ドメインユーザーの権限とグループポリシー設定

ライセンスに問題がない場合や、あるいはライセンスは大丈夫そうだが接続が弾かれるという場合、ユーザーの権限設定やグループポリシーに原因があることも多いです。特に、RDSHサーバーから他サーバーに接続する際は、ドメインユーザーアカウントが「リモート デスクトップ ユーザー」グループ、もしくはリモートデスクトップのアクセスを許可されたグループに含まれているかどうかが重要になります。

「リモート デスクトップ ユーザー」グループへの追加

Windows Server上でドメインユーザーがRDP接続をする場合、以下の設定を確認しましょう。

1. RDSHサーバーのコンピュータの管理 > 「ローカル ユーザーとグループ」 > 「グループ」 > 「Remote Desktop Users(リモート デスクトップ ユーザー)」
2. ここに接続を許可したいドメインユーザー、あるいはドメイングループが含まれているかを確認する

サーバーがドメインに参加している場合、グループポリシーによってこの「リモート デスクトップ ユーザー」グループへの追加・削除がコントロールされることもあります。そのため、ドメインコントローラー側で適用されているGPOについても意識しておくとよいでしょう。

「リモート デスクトップ サービス経由のログオンを許可」ポリシーの確認

グループポリシー(gpedit.msc)の以下のパスにある「ユーザー権利の割り当て」も重要なポイントです。

コンピューターの構成 
   > Windowsの設定 
       > セキュリティの設定 
           > ローカルポリシー 
               > ユーザー権利の割り当て 
                   > リモート デスクトップ サービス経由のログオンを許可

ここに追加されていないユーザー(もしくはグループ)は、RDS経由のログオンができない可能性があります。特に、ドメイン環境であれば「ドメインユーザー」を含んだグループがここに追加されているか確認してみましょう。

ネットワーク レベル認証(NLA)の考慮

Windows Serverの既定設定では、RDP接続にNLA(ネットワーク レベル認証)を有効にしている場合があります。NLAが有効だと、クライアント(ユーザー)側が接続要求を行う段階で、Active Directoryで認証ができないアカウントは弾かれてしまいます。環境によってはNLA周りの設定ミスで、ドメインユーザーが認証エラーとなることがあります。

NLAを一時的にオフにしてテスト

一時的にNLAをオフにして接続テストをしてみると、NLAが原因かどうかを切り分けられます。NLAをオフにするには、以下の手順を行います。

1. サーバーマネージャーから「ローカル サーバー」の「リモート デスクトップ」設定をクリック
2. 「リモート デスクトップのユーザー」タブから、ネットワーク レベル認証を使用する設定を解除
3. 適用後に、ドメインユーザーで接続できるかテスト

もしNLAをオフにしたら接続できるようになる場合は、認証方式に関する設定が誤っている可能性が高いです。セキュリティ上NLAはなるべく有効にしておきたいので、正しいドメイン環境下で認証を行えるように、グループポリシーやユーザーアカウントの設定を再確認する必要があります。

接続先サーバー側のリモート設定とファイアウォール

RDSHサーバーから他のドメイン内サーバーへRDP接続を行う場合、接続先のサーバー側にもリモート デスクトップ ユーザーへの許可設定やファイアウォールの例外設定(ポート3389)が必要です。下記のような点を再確認してみてください。

リモート設定(システムのプロパティ)のチェック

接続先のサーバーで、

1. 「このコンピューターへのリモート接続を許可する」がオンになっている
2. 「ネットワーク レベル認証のみでリモート デスクトップを実行しているコンピューターからの接続を許可する」にチェックが入っているかどうか
3. 「ユーザーの選択」ボタンでドメインユーザーまたはグループが追加されているか

これらの項目を確認します。もしここでドメインユーザーが許可されていない場合は、接続そのものが拒否されてしまいます。

Windowsファイアウォールの受信規則

特にテスト環境や評価版で導入したばかりだと、意外と見落としがちなのがWindowsファイアウォールです。接続先サーバーの受信規則でRDP(ポート3389)が許可されていなければ、いかにRDSやグループポリシーを正しく設定していても接続が拒否されます。
以下の手順で確認できます。

1. 「Windows セキュリティ」を開く
2. 「ファイアウォールとネットワーク保護」から「詳細設定」を選択
3. 「受信の規則」の一覧に「リモート デスクトップ (TCP-In)」があり、有効になっているかチェック

もしルールが無効になっていたり、特定のScope(範囲)だけが許可されていたりすると、ドメインユーザーの接続が遮断されるケースがありますので要注意です。

評価版RDSで多くのユーザーが利用可能にするためのポイント

評価版の段階で運用する場合、早い段階でライセンス管理の仕組みを整えておくことが大切です。特にドメイン環境では、「台数分またはユーザー数分のRDS CALを用意する」ことが基本です。グレース期間内であれば動作するように見える場合もありますが、期限を過ぎると急に接続不可になるリスクがあります。

ライセンス構成例

以下のような形でライセンス構成を行うとスムーズです。

項目	設定内容
ライセンスサーバー	Windows Server 2022上にRD Licensing役割をインストール
CALの種類	ユーザーCAL or デバイスCAL (運用に応じて選択)
ライセンスの登録方法	RDSライセンス マネージャーからインターネット認証 or 電話認証で登録
使用できるRDS CALの有効期限	ライセンスサーバーがアクティブ化されていれば期限はライセンスに準拠
ドメインユーザーへの割り当て	ユーザーCALを利用する場合はドメインユーザー数分を確保

評価版であっても、ライセンスサーバーを立ててCALの登録だけ済ませておくと、多くのドメインユーザーに対してリモートデスクトップ経由の利用を続けやすくなります。逆に未設定だと、グレース期間が終了後に突然「ライセンスが不足しているため接続できません」というメッセージが出てしまうケースもあるので要注意です。

具体的なトラブルシューティング手順

ここでは、RDSHサーバーからドメイン内の別サーバーへの接続をドメインユーザーで行うときに失敗する場合の、具体的な確認手順を例示します。

ステップ1: ライセンス関連のチェック

1. RDSライセンスサーバーがインストールされているか
2. ライセンスマネージャーでCALが有効か
3. RDSHサーバー側でライセンスサーバーを見つけられているか(「RDSライセンス診断」を参照)

ステップ2: ドメインユーザー権限の確認

1. ドメインユーザーがRDSHサーバーの「Remote Desktop Users」グループ、あるいは「リモート デスクトップ サービス経由のログオンを許可」権限を持つグループに属しているか
2. GPOによってユーザー権利の割り当てが上書きされていないか

ステップ3: NLAと認証の確認

1. RDSHサーバーおよび接続先サーバーでNLAが有効かどうか
2. 一時的にNLAを無効にしてみて接続結果をテスト
3. ドメインコントローラーとの通信に問題はないか(イベントログ要確認)

ステップ4: 接続先サーバーのリモート設定とファイアウォール

1. 接続先サーバーが「このコンピューターへのリモート接続を許可する」になっているか
2. 「Remote Desktop Users」グループにドメインユーザーやグループが追加されているか
3. Windowsファイアウォールでポート3389が解放されているか

ステップ5: イベントビューア(ログ)の確認

1. RDSHサーバー、接続先サーバー双方の「アプリケーションとサービス ログ」(Microsoft > Windows > TerminalServices-LocalSessionManager など)
2. エラーや警告が出ている場合はイベントIDを手掛かりに調査

このように段階的にトラブルシューティングを行うことで、「ライセンスの問題なのか」「グループポリシーや権限周りの問題なのか」「ネットワークレベル認証やファイアウォールの問題なのか」を切り分けることができます。問題の切り分けを丁寧に行うことで解決が早まるのはもちろん、再発防止にもつながります。

よくある誤解と追加のヒント

RDSの評価版を導入した際、「管理者アカウントでは接続できるし、問題ないのでは？」と思いがちですが、多くのドメインユーザーが接続を希望する運用を想定しているなら、早めにライセンスサーバーや権限設定をきちんと固めておくことをおすすめします。以下に補足的なヒントをまとめました。

誤解1: グレース期間中は無制限にドメインユーザーが使える

実際には一定期間(通常は120日程度)のグレース期間が過ぎると、ライセンスがない状態ではドメインユーザーは接続が制限されます。評価版でも同様なので、実運用であれば早期にライセンス導入が必要です。

誤解2: ローカルユーザーが接続できるならドメインユーザーも問題ない

ローカルユーザーはあくまでRDSHサーバー上のアカウントであり、ドメイン環境とは切り離されていることが多いです。ドメインユーザーの場合はActive Directory上のアカウント情報とグループポリシーが関連してくるため、別途設定が必要になる場合がほとんどです。

誤解3: NLAを無効にすればすべてうまくいく

たしかにNLAをオフにすることで接続はしやすくなりますが、セキュリティレベルが下がり、ブルートフォース攻撃などのリスクが増大します。ドメイン環境で運用するなら、NLAを正しく活かせるように設定することが望ましいでしょう。

運用フェーズで押さえておきたい管理ポイント

多くのユーザーが利用するRDS環境は、運用フェーズでの管理もしっかり行う必要があります。定期的なライセンス使用状況の把握や、ユーザー権限の見直しを行うことで、スムーズかつ安全なリモートデスクトップ環境を提供できます。

ライセンスサーバーの監視と更新

• RDSライセンス マネージャーでライセンスの有効期限やアクティブなセッション数を定期的にチェックする
• ドメイン内でユーザー数が増加する場合は、それに応じてRDS CALが十分に足りるか確認する

グループポリシーの整合性

• 新たにユーザーを追加・変更した場合、適用されるグループポリシーが正しく機能しているかをテストする
• GPOを変更した場合はグループ ポリシーの更新(gpupdate /force)後に動作確認を忘れない

セキュリティ対策

• パスワードポリシーやアカウントロックアウトポリシーなどの基本的なセキュリティ設定の強化
• 可能であればRD GatewayやVPNなどを活用し、直接3389ポートを外部公開しない設計にする
• 多要素認証(MFA)や証明書ベースの認証を組み合わせることでセキュリティを高める

まとめ：正しいライセンスと権限設定が鍵

Windows Server 2022でRDSを導入した際、ドメインユーザーのみリモートデスクトップがうまくいかない場合は、ライセンスサーバーの設定やグループポリシーでの「リモート デスクトップ サービス経由のログオンを許可」権限、NLA周りの設定などを重点的に確認することが解決の近道です。
加えて、接続先サーバーのリモート設定やファイアウォールの許可ルールなど、複数の側面を総合的にチェックしておくと、トラブルシューティングが効率的に進むでしょう。多くのユーザーが利用するRDS環境では、評価版の段階からライセンス管理と権限設定をきちんと行うことで、運用開始後のスムーズなリモートデスクトップ活用を実現できます。