Windows2008R2およびWindows2012リモートデスクトップサービスの証明書要件

月にTECHNETで最初に公開24, 2014

おはようアスクパーフ！ あなたのための質問とここのKiran:なぜ私達は証明書を必要とするか。 さて、証明書は2つのマシン間の通信に署名するために使用されます。 クライアントがサーバーに接続すると、接続を受信しているサーバーのid、およびクライアントからの情報が証明書を使用して検証されます。

これはman-in-the-middle攻撃の可能性を防ぐために行われます。 クライアントとサーバーの間に通信チャネルが設定されている場合、証明書を発行/生成する機関は、サーバーが本物であることを保証しています。

そのため、クライアントが通信しているサーバーを信頼している限り、サーバーとの間で送受信されるデータは安全であるとみなされます。 これは私を次の質問に連れて行きます:

RDSにはどのような種類の証明書が必要ですか。

次のブログには、証明書の種類と、ドメインの内部CAを使用して証明書を作成する方法に関する情報が記載されています。

http://blogs.msdn.com/b/rds/archive/2010/04/09/configuring-remote-desktop-certificates.aspx

リモートデスクトップ証明書の基本要件:

  1. 証明書は、コンピューターの”個人用”証明書ストアにインストールされます。
  2. 証明書には対応する秘密鍵があります。
  3. “拡張キー使用法”拡張機能の値は、”サーバー認証”または”リモートデスクトップ認証”(1.3.6.1.4.1.311.54.1.2). 「Enhanced Key Usage」拡張子のない証明書も使用できます。

それが実行する機能が示唆するように、私たちは’サーバー認証’証明書が必要です。 この証明書は、’Workstation Authentication’テンプレートを使用して生成できます(必要な場合)。

ここに正確なプロセスがあります:

  1. CERTSRVを開きます。MSCと証明書を設定します。
  2. 認証局を開きます。
  3. 詳細ペインで、講師のコンピュータ名を展開します。
  4. 証明書テンプレートを右クリックし、管理を選択します。 Workstation Authenticationを右クリックし、Duplicate Templateをクリックします。
  5. [全般]タブで、テンプレートの表示名をクライアントサーバー認証に変更し、[Active Directoryで証明書を発行]をオンにします。
  6. [拡張機能]タブで、[アプリケーションポリシー]をクリックし、[編集]をクリックします。 「追加」をクリックし、「サーバー認証」を選択します。 [Ok]をクリックして、[新規テンプレートのプロパティ]ダイアログに戻ります。
  7. セキュリティタブをクリックします。 ドメインコンピュータの場合は、”自動登録を許可する”チェックボックスをクリッ [OK]をクリックします。 証明書テンプレートコンソールを閉じます。
  8. certsrvスナップインで、証明書テンプレートを右クリックし、新規を選択し、発行する証明書テンプレートを選択します。
  9. “クライアント-サーバー認証”を選択し、”OK”をクリックします。

これは、次のように”証明書”MMCスナップインで証明書を表示するときに表示されます:

証明書を開くと、”一般”タブには、以下に示すように、この証明書の目的が”サーバー認証”であることも含まれます:

これを検証する別の方法は、証明書の「詳細」セクションに移動し、「拡張キー使用法」プロパティを確認することです:

接続するクライアントマシンを制御する場合、証明書を取得する最も簡単な方法は、Active Directory証明書サービスを使用することです。 独自の証明書を要求して展開することができ、ドメイン内のすべてのマシンによって信頼されます。

ユーザーが外部からの接続を許可し、ドメインの一部ではない場合は、パブリックCAから証明書を展開する必要があります。 GoDaddy、Verisign、Entrust、Thawte、DigiCert

必要な証明書の種類がわかったので、証明書の内容について話しましょう。

Windows2008/2008R2では、DNSラウンドロビンに従って、最初にリダイレクター、接続ブローカーの横、最後にセッションをホストするサーバーに送られるファーム名に接続します。

Windows2012では、接続ブローカーに接続し、コレクション名を使用してコレクションにルーティングします。

展開する証明書には、ユーザーが接続しているサーバーの名前と一致するサブジェクト名またはサブジェクト代替名が必要です。 したがって、たとえば、発行する場合、証明書にはコレクション内のすべてのRDSHサーバーの名前が含まれている必要があります。 RDWebの証明書には、ユーザーが接続する名前に基づいて、URLのFQDNが含まれている必要があります。 ユーザーが外部から接続している場合、これは外部名である必要があります（接続先と一致する必要があります）。 RDwebに内部的に接続しているユーザーがいる場合は、名前が内部名と一致する必要があります。 シングルサインオンの場合は、サブジェクト名がコレクション内のサーバーと一致する必要があります。

この例では、次のマシンを含むRDS展開を考えてみましょう。

RDSH1.RENDER.COM リモートアプリが構成されたセッションホスト

RDSH2.RENDER.COM リモートアプリが構成されたセッションホスト

RDVH1。レンダリングします。VDI Vmが構成されたCOM仮想化ホスト

RDVH2.RENDER.COM VDI Vmが構成された仮想化ホスト

RDCB.RENDER.COM 接続ブローカー

RDWEB.RENDER.COM RDWeb and Gateway server

クライアントが内部的に接続すると、webページをホストするサーバーのFQDNが入力されます。RDWEB.RENDER.COM.

証明書の名前は、ユーザーが接続を開始するURLのこの名前である必要があります。 しかし、接続はここで終わるだけではないことを覚えておく必要があります。 その後、接続はwebサーバーからセッションホストまたは仮想化ホストのいずれか、および接続ブローカーに流れます。

証明書は、これらのすべてのサーバーで共通にすることができます。 このため、証明書のサブジェクト代替名には、展開の一部である他のすべてのサーバーの名前を含めることをお勧めします。 要するに、私の環境の証明書は次のようになります。

タイプ：サーバー認証

名前：RDWEB.RENDER.COM

さん:RDSH1.RENDER.COM;RDSH2.RENDER.COM;RDVH1.RENDER.COM;RDVH2.レンダリングします。COM;RDCB.RENDER.COM

これは、展開内に5つ以下のサーバーがある限り、必要なすべてです。 しかし、展開に多くのサーバーがある場合、問題が発生します。 これは、設計上、証明書のSAN（サブジェクト代替名）には5つのサーバー名しか含めることができないためです。 それ以上のものがある場合は、展開内のすべてのサーバーをカバーするために発行されたワイルドカード証明書を取得する必要があります。 ここで私の証明書は次のように変更されます：

タイプ：サーバー認証

名前：RDWEB.RENDER.COM

さん：*。レンダリングします。COM

次のシナリオに関しては、まだいくつかの課題に遭遇しています。 これは、展開にアクセスする外部ユーザーがいる場合にのみ当てはまることに注意してください。

外部名:RDWEB.RENDER.com

内部名:RDWEB.レンダリングします。ローカル

ここで、証明書を取得する場合RDWEB.RENDER.COM 名前には、証明書のエラーが表示されます。 これは、証明書がFQDNを持つサーバーを検証することになっているためです。RDWEB.RENDER.COMただし、サーバーは「RDWEB」です。レンダリングします。ローカル’と’.com’に’。local’magicは、ポート転送を使用してパブリックファイアウォール/ルーターでのみ発生します（最も一般的なシナリオ）。

このようなシナリオでは、以前は、証明書の名前に’.com’名が含まれ、SANに’が含まれていることをお勧めしました。ローカル名。

最近、すべての公開証明書プロバイダが’で証明書の発行を停止しています。ローカル’それらの中に。 Windows8およびWindows Server2012以降では、証明書に外部名と内部名を含める必要がなくなりました。

外部クライアントが接続しており、プライベートな内部ドメインサフィックス(DOMAIN.ローカル）では、外部（RDWEB.DOMAIN.COM)インターネットに公開されているのはRD WebアクセスおよびRDゲートウェイの役割のみであるため、この役割に名前を付けてバインドします。 RD接続ブローカーの発行およびRD接続ブローカーのシングルサインオンを有効にする場合は、’ドメインを持つ内部証明書を使用できます。その上にローカル’名前。 ただし、前述したように、これはRDC8.0以上を介して接続するクライアントでのみ機能します。

RDゲートウェイおよびリモートデスクトップクライアントバージョン8.0(およびそれ以上)は、外部ユーザーに展開への安全な接続を提供します。 展開に接続すると、内部証明書は’。local’nameは、リモートアプリ署名（公開）とシングルサインオンを処理します。

さて、私たちが持っている証明書を設定する場所を見てみましょう:

接続ブローカーサーバーでサーバーマネージャーを開き、左端のペインでリモートデスクトップサービスをクリックします。

ここに入ると、下の図のように展開が表示されます。 タスクをクリックし、”展開プロパティの編集”を選択します”

これにより、展開のプロパティシートが表示されます。 左側のペインで証明書オプションを選択します:

これで、前述したように、画面の下部にある[既存の証明書の選択]ボタンを使用して作成された証明書を選択できます。

は’を指すだけです。pfx’ファイルとロールの証明書をインポートできるようにします。

クライアントがドメインの内部にのみ存在する場合は、単純なワイルドカード証明書(*.レンダリングします。ローカル）とそれをすべてのロールにバインドします。

この展開の一部である複数のサーバーがある場合でも、サーバーマネージャーは、展開内のすべてのサーバーに証明書をインポートし、それらをマシンの信頼されたルートに配置し、それぞれのロールにバインドすることに注意してください。

-Kiran Kadaba

Write a Comment

メールアドレスが公開されることはありません。