Windows Server 2008 R2 テクノロジ入門 (日経BPソフトプレス)
http://ec.nikkeibp.co.jp/item/books/A09600.html
Windows Server 2008 R2 機能評価ガイド[仮想化編]仮想デスクトップ インフラストラクチャ (VDI)http://download.microsoft.com/download/D/D/1/DD187274-7AF3-45FA-BA2D-C7033F097C66/R2RTM_EvalGuide_VDI.pdf
Windows XP SP3 や Windows Vista 用の最新のリモートデスクトップ接続クライアント (RDP 7.0 対応) など、クライアント側のコンポーネントも出そろったので、注意点などをまとめておきます。
フォーム ベースの認証の RD Web アクセス
Web SSO は、RemoteApp プログラムへのシングル サインオンを実現する認証機能です。RDS の RD Web アクセスおよび、RD Web アクセスのフィードを受信する Windows 7 の 「RemoteApp とデスクトップ接続」でサポートされます。Web SSO が利用可能な場合、RD Web アクセスにドメインアカウントで1度サインインすると、その資格情報を使用して RemoteApp プログラムを (資格情報の再入力なしで) 起動できます。
Web SSO が利用できない場合 (サポートされない環境または構成が間違っている場合) 、右の画面のように資格情報の入力が求められます。
ちなみに、RD Web アクセスで Windows 認証を使用するには、C:\Windows\Web\RDWeb\pages\Web.config ファイルを変更し、IIS マネージャーを使用して RD Web アクセスの仮想ディレクトリで Windows 認証を有効にします。その方法は、Web.config ファイルの中に簡単に記述されています。Windows 認証を有効にすると、RD Web アクセスの認証ページをスキップできますが、Web SSO が機能しなくなるため、右画面と同じように、RemoteApp プログラム起動時に資格情報の入力が要求されます。
RDP 7.0 とネットワーク レベル認証 (NLA)
Web SSO は、RDP 7.0 対応のリモートデスクトップ接続クライアント (Mstsc.exe) でサポートされます。RDP 7.0 は、Windows 7 の標準です。Windows Vista SP1 以降および Windows XP SP3 は、次の更新プログラムでサポートされます。
Description of the Remote Desktop Connection 7.0 client update for Remote Desktop Services (RDS) for Windows XP SP3, Windows Vista SP1, and Windows Vista SP2
Web SSO のためには、接続先の RDS との間でネットワーク レベル認証 (NLA: Network Level Authentication) が利用できる必要があります。NLA は RDP 6.1 以降からサポートされていますが、Windows XP SP3 では既定で無効になっています。Windows XP SP3 クライアントで NLA を有効にするには、次のサポート技術情報にしたがって、CredSSP を有効化する必要があります。
Description of the Credential Security Support Provider (CredSSP) in Windows XP Service Pack 3
RemoteApp プログラムへのデジタル署名
RD セッション ホストでは、「RemoteApp マネージャー」を使用して、公開する RemoteApp プログラムに “信頼された発行元”の証明書を使用してデジタル署名する必要があります。「RemoteApp マネージャー」のアクション ペインにある「デジタル署名の設定」から構成できます。
デジタル署名に使用される証明書は、“信頼された発行元”であることが重要です。RD セッション ホストで自動生成される証明書はテスト用のものなので、使用に適しません。Active Directory 証明書サービスを使用して、エンタープライズ PKI を準備することをお勧めします。
RD 接続ブローカー使用時のデジタル署名の一致
RD Web アクセスの RemoteApp ソース (RD セッション ホスト) を、RD 接続ブローカーから取得するように構成されている場合 (例えば、複数のRD セッション ホストを 1 つの RD Web アクセスでサポートする場合や、VDI の仮想デスクトップと RemoteApp の両方を展開する場合)、RemoteApp プログラムのデジタル署名に使用する証明書と、RD 接続ブローカーがデジタル署名の使用する証明書 ( RD 接続マネージャーで構成する) が同一である必要があります。RD 接続ブローカーと異なる証明書を使用した RemoteApp プログラムを起動しようとした場合、Web SSO は機能せず、資格情報の入力が求められます。
例えば、RD 接続ブローカー用に発行された証明書 (rdcnb.contoso.com) で Web SSO を構成しようという場合は、この証明書を使用して、すべての RD セッション ホストの RemoteApp プログラムを署名する必要があります。それには、RD 接続ブローカーのサーバーで「RemoteApp マネージャー」を起動し、スナップインをリモートの RD セッション ホストに接続して証明書を変更します。「RemoteApp マネージャー」が存在しない場合は、機能の追加を実行し、「リモート サーバー管理ツール\役割管理ツール\リモート デスクトップ サービス ツール\リモート デスクトップ セッション ホスト ツール」をインストールしてください。
RD 接続ブローカーを使用する場合、Web SSO の問題は、おそらくこの証明書の構成の問題が原因となることが多いでしょう。「RD 接続マネージャー」のデジタル署名の設定は、「仮想デスクトップ: リソースと構成」にありますが、RD 接続ブローカーの対象とする RemoteApp ソース (RD セッション ホスト) の Web SSO にも関係するため、非常にわかりにくくなっています。
これが最も重要かもしれませんが、Web SSO が利用できるのは RemoteApp プログラムだけです。通常のリモートデスクトップ接続や、VDI の個人用仮想デスクトップ、仮想デスクトップ プールへの接続には、Web SSO は適用されません。接続するたびに、資格情報の入力が求められます。
SSO といっても、ユーザーから見れば 2 回目の認証
シングル サインオン (SSO) とは言っても、エンドユーザーから見れば、少なくても 2 回の認証が発生します。1 回目は、Windows にログオンするための認証です。2 回目が RD Web アクセスへのフォーム ベース認証です。RD Web アクセスを Windows 認証で構成した場合、Web SSO は機能しないため、Windows ログオンの資格情報を使用して、RemoteApp プログラムをパススルー認証で実行するということはできません。“シングル” というのが Windows ログオンからのように誤解しそうなので注意してください。ただし、Windows 7 の新機能である「RemoteApp とデスクトップ接続」コントロールパネルを使うと、Windows へのログオン認証によるシングル サインオンが実現できます。これについては後述します。(2010.07.21 追記)
RDP ファイルを使用した資格情報の保存
「RemoteApp マネージャー」を使用すると、RD Web アクセスでの公開以外に、RDP ファイルや MSI ファイル (RDP ファイルをスタートメニューやデスクトップに登録し、ファイルの関連付けをシステムに登録するためのインストーラー) を作成して配布するという選択肢があります。RDP ファイルであれば、初回の認証時に資格情報を保存するように指定できます。資格情報の入力は 1 回だけでよく、RD Web アクセスへのサインインも不要なので、この方法のほうがエンドユーザーにとっては使い勝手が良いかもしれません。
仮想デスクトップへの接続には資格情報の入力が必須 !?
Web SSO を構成しても、VDI の仮想デスクトップへの接続では、資格情報の入力が求められます。(2010.07.21 追記)
VDI の接続では、直接、仮想デスクトップに RDP 接続するのではなく、まず、RD 接続ブローカーに接続します。RDP ファイルを使用した場合も、RDP ファイル内に最終宛先のコンピューター名が記述されているわけではないので、接続先と関連付けて資格情報を保存することができません (「資格情報を記憶する」オプションが表示されません)。
VDI の接続では、直接、仮想デスクトップに RDP 接続するのではなく、まず、RD 接続ブローカーに接続します。RDP ファイルを使用した場合も、RDP ファイル内に最終宛先のコンピューター名が記述されているわけではないので、接続先と関連付けて資格情報を保存することができません (「資格情報を記憶する」オプションが表示されません)。
仮想デスクトップへの接続時に資格情報の入力を省略するためには、Windows 7 のコントロールパネルの新機能「RemoteApp とデスクトップ接続」を使用します。Web SSO を構成しただけでは、スタートメニューの「RemoteApp とデスクトップ接続」に登録されたショートカットをクリックすると、1 度だけ資格情報の入力が求められます (おそらく RD Web アクセスへのログオンのため)。
これを回避するためには、ローカル ポリシーやグループ ポリシーで次のポリシーを構成します。
コンピューターの構成\管理用テンプレート\システム\資格情報の委任\既定の資格情報の委任を許可する: 有効
サーバーを一覧に追加: TERMSRV/* (またはTERMSRV/FQDN、またはTERMSRV/*.ドメイン名)
これで、「RemoteApp とデスクトップ接続」のショートカットからRemoteApp プログラムや仮想デスクトップに接続しても、資格情報の入力が求められることはありません。
なお、このポリシーを構成しても、RD Web アクセスで仮想デスクトップに接続する場合は、資格情報の入力が求められるようです。つまり、Web SSO とは関係ないようです。(2010.07.21 追記)
参考情報
Web SSO の機能や制約、具体的な構成方法については、以下のサイトが参考になります。
RemoteApp とデスクトップ接続のセキュリティについて
Remote Desktop Services (Terminal Services) Team Blog: Introducing Web Single Sign-On for RemoteApp and Desktop Connections
(2010.07.21 以下も追加しておきます)
Remote Desktop Services (Terminal Services) Team Blog: How to enable Single Sign-On for my Terminal
Server connections
http://blogs.msdn.com/b/rds/archive/2007/04/19/how-to-enable-single-sign-on-for-my-terminal-server-connections.aspx
When you enable SSO for a terminal server from a Windows XP SP3-based client computer, you are still prompted for user credentials when you log on to the terminal server
http://support.microsoft.com/kb/953760/en-us
(2011.04.25 追記)
RD Web アクセスにおいて、RemoteApp 以外でも Web SSO を可能にする Hotfix が出ました。詳しくは、こちらの投稿で。RD Web アクセスを通じて完全なリモート デスクトップ接続を開始しようとすると、シングル ・ サイン ・ オン機能 Windows 7 または Windows Server 2008 R2 で動作しません。
http://support.microsoft.com/kb/2524668/ja
ユーザから見ると、2 回目の認証になってしまうのは、資格情報の委任が設定されていないからでは?
返信削除GPO または LPO で以下を設定してみてください。
コンピューターの構成/管理用テンプレート/システム/資格情報の委任/
既定の資格情報の委任を許可する 有効 サーバーを一覧に追加: TERMSRV/*
いわゆる SSO が実現できます。
negineji 様、ご指摘ありがとうございます。
返信削除Windows Server 2008 以前からあるターミナルサービス向けの資格情報の委任設定ですが、Web SSO (SSO ではなく)とは直接関係ないため、失念していました。資格情報の委任設定をすることで、「RemoteApp とデスクトップ接続」使用時の資格情報入力が省略できましたので、投稿の内容を修正しました。Web SSO については、あくまでもフォーム認証が必要ですが、資格情報の委任設定をすることで、RDP ショートカットの起動から最終目的地 (RemoteApp または仮想デスクトップ) までサーバー認証でいけるようです。
RDWeb上で提供するRemoteAPPプログラムをシングルサインオンで起動させるため、こちらのサイトを参考にさせていただきました。
返信削除RDWebログイン後にRemoteAPPプログラムをクリックすると、RemoteAPPの接続画面が出てきてしまいます。そして、そこで接続を押すと、「RDセッションホストファームの資格情報を入力してください。これらの資格情報は、リモートコンピュータへの接続時に使用されます。」といったメッセージが出て、再度、ユーザー名とパスワードを求められ、シングルサインオンが出来ません。
デジタル証明書は、RD接続ブローカーそしてRDセッションホストと全て同じにしており、発行元もちゃんと認識されております。
まだ設定が不足しているものなのでしょうか。ご教授お願いできませんでしょうか。
よろしくお願いいたします。
yuu 様
返信削除この Web SSO に関する投稿は、Microsoft VDI 環境と1台のRemoteAppソースがあることしか念頭にありませんでした。RD セッションホストのサーバーファーム構成の場合は、ファームの構成方法によって変わってくると思います。同一構成のRemoteAppソースとして構成し、RemoteAppを負荷分散したい場合は、次のいずれかになると思います。
(1) DNSラウンドロビンの方法またはNLB を使う方法
ファームのFQDNと一致する証明書をファーム内の各RDセッションホストのサーバー認証用に割り当てます(RDセッションホストの構成を使用して、RDP-Tcpの接続に証明書を割り当てます)。
RD Webアクセスの構成で、[1つまたは複数のRemoteAppソース]を選択して、ファームのFQDNを設定します。
(2) 専用のリダイレクターを使う方法
リダイレクターとして構成するRDセッションホストのIPアドレスに関連付けられた、ファームのFQDNをDNSに登録し、そのFQDNと一致するサーバー証明書を、リダイレクターとファームのメンバーのRDP-Tcpの接続に割り当てます。RD Webアクセスの構成で、[1つまたは複数のRemoteAppソース]を選択して、ファームのFQDNを設定します。
どちらの場合も、接続ブローカーは負荷分散のために必要ですが、RD Webアクセスのために使用する必要はありません。使用することもできますが、その場合は接続ブローカーのRemoteAppソースとしてファームのFQDNを追加し、RD Webアクセスで接続ブローカーを指定します。VDIとの混在の場合は、後者を選択することになります。
同一構成でないRemoteAppソースを複数台設置して、1つのRD Webアクセスに統合する場合は、単純にRD Webアクセスの構成で、[1つまたは複数のRemoteAppソース]にRDセッションホストをカンマ区切りで指定します。サーバー証明書は、それぞれのRDセッションホストのFQDNと一致した証明書を、それぞれのRDセッションホストのRDP-Tcpの接続に割り当てます。
ご教授ありがとうございます。
返信削除RDP-Tcpのプロパティでファーム名と同じ証明書を選択したところ、リモートデスクトップ接続すらできなくなってしまいました。
WindowsXPクライアントからリモート接続すると、予期しないサーバー認証証明書を受け取ったためエラー。
Windows7クライアントからリモート接続すると、失効状態の確認ができませんといったエラー。
現在、RDSをインターネットから利用することを想定した構成になっております。そのため、RemoteAPPマネージャーのRDセッションホストサーバー設定では外部からアクセスできるFQDNを指定しております。また、ファームは外部からアクセスできる同じFQDNに指定しております。
証明書の発行先も外部からアクセスできる同じFQDNとなっており、ADで発行しております。証明書の有効期限はまだ切れておりません。
ネットワークレベル認証は有効になっておりますが、NPS(ネットワークポリシーサーバー)の設定は特にいじっておりません。
サーバー証明書の作成方法がおかしいのでしょうか。
たびたび申し訳ありませんが、以上よろしくお願いいたします。
yuu 様
返信削除(1) 外部からのアクセスにADのCAが発行した証明書を利用する場合は、証明書失効リスト(CRL)の配布ポイントをインターネットからアクセスできる場所に準備する必要があると思います。できない場合は、公共のCAが発行した証明書(インターネットからCRLにアクセスできる)を使用することになります。
(2) 外部からアクセスする場合は、RDゲートウェイを介してアクセスするように構成した方が良いと思います。その場合、RDゲートウェイサーバーのFQDNに対応したサーバー証明書(とRD WebアクセスのSSLサーバー証明書)だけ用意すればよく、社内のRDセッションホストやファームは社内で利用するのと同じ構成(証明書を含め)にできると思いますし、セキュリティ上も望ましいと思います。
証明書というかPKI基盤の問題のようにも見えますが、切り分けが必要かと思います。テストのための閉じた環境で、まず非ファーム構成で正しく動作することを確認し、次にRD Webアクセスなしでファームが正しく動作することを確認、次にRD Webアクセスを介した構成、さらにRDゲートウェイを追加した構成、外部FQDNを使用した接続...という具合に構築していけばよいかと。