「Webアプリケーションプロキシ」はマルチデバイス環境におけるリモートアクセスの“要”vNextに備えよ! 次期Windows Serverのココに注目(24)(2/2 ページ)

» 2015年08月25日 05時00分 公開
[山市良テクニカルライター]
前のページへ 1|2       

リモートデスクトップサービスの公開、新旧プロキシでの違い

 アプリケーションの公開設定では、追加設定が必要な特殊なケースについて、以下のドキュメントで具体的に説明されています。

 「リモートデスクトップサービスの公開」は、現在のWebアプリケーションプロキシでも可能です。では、どこが新しくなるのかというと、リモートデスクトップサービスの外部向けサービスである「リモートデスクトップ(RD)Webアクセス」と「リモートデスクトップ(RD)ゲートウェイ」の両方を、AD FS事前認証に基づいてセキュアに公開できることです。

 現在のWebアプリケーションプロキシの場合、RD WebアクセスはAD FS事前認証で、RDゲートウェイはパススルーで公開することができます。RD WebアクセスからRDゲートウェイを経由した社内へのリモートデスクトップ接続は、RD Webアクセスのフォーム認証の資格情報で最終ホストまでSSOとなります。しかし、RDゲートウェイはパススルーで公開されているため、RD Webアクセスを経由しないRDゲートウェイへのアクセスができてしまうという問題があります。

 新しいWebアプリケーションプロキシは、RD WebアクセスとRDゲートウェイの両方をAD FS事前認証で公開することができ、RDゲートウェイを経由したリモートデスクトップ接続をRD Webアクセスのフォーム認証で認証されたものだけに限定できます。RDゲートウェイへの直接アクセスは、AD FS事前認証およびRD Webアクセスのフォーム認証が行われていないためブロックされます。

 実は、Windows Server 2012 R2のWebアプリケーションプロキシでも、修正プログラム(Windows Server 2012 R2向けの2014年11月の更新ロールアップに含まれる)の適用で、同様の公開方法が使用できるようになっています。これまでは具体的な手順が示されていませんでしたが、前出のドキュメント(Publishing Applications with SharePoint, Exchange and RDG)の公開でようやく構成できるようになりました(図1)。

図1 図1 新しいWebアプリケーションプロキシによる、RD WebアクセスおよびRDゲートウェイの公開

 ここで具体的な手順を説明することはしませんが、次の四つの構成が重要なポイントになります。

[1]一度のAD FS事前認証でRD WebアクセスとRDゲートウェイ両方のHTTPSアクセスをAD FSで事前認証済みとするために、AD FSに要求対応アプリケーションとしてRD Webアクセスの証明書利用者信頼(Relying Party Trusts)を登録する

[2]RD WebアクセスとRDゲートウェイを、同じ証明書利用者信頼を用いて公開する

[3]RD Webアクセスでアイコンをクリックしたときに呼び出されるActiveXコントロールに対し、RD Webアクセスのフォーム認証のクッキー情報を渡せるように、RD Webアクセスの公開設定でWebアプリケーションプロキシの「HttpOnly」機能を無効化する(「Set-WebApplicationProxyApplication -DisableHttpOnlyCookieProtection:$true」コマンドレットを使用)

[4]RD接続ブローカーサーバーにおいて、セッションコレクションでカスタムRDPプロパティにRD Webアクセスの事前認証を必須とするように構成する

 実際に、新しいRD Webアプリケーションプロキシで公開したRD WebアクセスおよびRDゲートウェイに、インターネット上のクライアントからアクセスしてみました。

 Webブラウザーで「https://<RD WebアクセスのFQDN>/RDWeb」にアクセスすると、AD FS事前認証のためのフォーム認証ページにリダイレクトされます(画面4)。

画面4 画面4 「https://<RD WebアクセスのFQDN>/RDWeb」にアクセスすると、AD FSの認証ページにリダイレクトされる

 AD FS事前認証をパスすると、今度はRD Webアクセスの通常のポータルが表示されるので、こちらにも同じ資格情報を入力してサインインします。残念ながら、AD FS事前認証に基づいて、SSOでRD Webアクセスの認証をパスするということはできません(画面5)。AD FS事前認証は、RD Webアクセスのポータル、および後でRDゲートウェイにアクセスするために使用されています。

画面5 画面5 AD FS事前認証をパスすると、RD Webアクセスのサ インインページが表示される。ここで、2回目のサインインを行う

 RD Webアクセスのポータルへのサインインが完了すると、企業内で公開設定されているデスクトップコレクションやRemoteAppプログラムのアイコンをクリックして、RDゲートウェイ経由での接続を開始できます。

 RDゲートウェイおよび最終ホストに対する接続は、RD Webアクセスが備えるSSO機能で行われるため、あらためて資格情報の入力を求められることはありません(画面6)。また、RD Webアクセスを使用せずに、RDゲートウェイのURLに直接アクセスした場合は、AD FS事前認証とRD Webアクセス事前認証の制約により、ブロックされます。

画面6 画面6 RD Webアクセスにサインイン後は、SSOで最終ホストにRDゲートウェイ経由でアクセスできる

 リモートデスクトップサービスの公開で、AD FS事前認証とRD Webアクセスのポータルのフォーム認証の、2回の認証が必要なのは、回避することはできないようです。

 RD WebアクセスのポータルでWindows統合認証を使用するように変更して、AD FS事前認証によるSSOを実現することも可能です。しかしその場合、SSOはポータルへのサインインまでしか機能しません。RD Webアクセスがもともと備えるRDゲートウェイおよび最終ホストへのSSOアクセスは、ポータルにフォーム認証でサインインすることを前提として作られているからです。

Windows Server 2016最新情報

 2015年8月20日(日本時間)に3回目のプレビューリリースとなる「Windows Server 2016 Technical Preview 3」がリリースされました。次回からは、Technical Preview 3をベースに解説します。いよいよ、Docker対応のWindows Serverコンテナーの登場です。


「vNextに備えよ! 次期Windows Serverのココに注目」バックナンバー

筆者紹介

山市 良(やまいち りょう)

岩手県花巻市在住。Microsoft MVP:Hyper-V(Oct 2008 - Sep 2015)。SIer、IT出版社、中堅企業のシステム管理者を経て、フリーのテクニカルライターに。マイクロソフト製品、テクノロジを中心に、IT雑誌、Webサイトへの記事の寄稿、ドキュメント作成、事例取材などを手がける。個人ブログは『山市良のえぬなんとかわーるど』。


前のページへ 1|2       

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。