Azure アプリケーションプロキシー（パススルー）でリモートデスクトップを公開する

2015年10月14日付で、本社の Application Proxy Blog に以下の記事が公開されました。

Publishing Remote Desktop with Azure Active Directory Application Proxy
https://blogs.technet.com/b/applicationproxyblog/archive/2015/10/14/publishing-remote-desktop-with-azure-active-directory-application-proxy.aspx

インフラの設計に大きく影響を与える、重要な機能向上です。

一言でいえば、社内のリモートデスクトップサービスを、Azure アプリケーションプロキシー （パススルー）を使用して社外に公開できるようになったということです。

（参考）
Windows Server 2012 R2 Web Application Proxy を使用したRDS（リモートデスクトップサービス）の外部公開については以下を参照してください。
Publishing Applications with SharePoint, Exchange and RDG
https://technet.microsoft.com/en-US/library/dn765486(WS.11).aspx

リモートデスクトップ環境を構築する場合、およそ以下のような構成になります。RD Web Access は RDS へのポータル画面です。WEBサービスなので、当然 HTTPS 通信です。実際にRD Session Host や Remote App に接続する際には RDP を使用することになりますが、インターネット上は HTTPS で通信を行い、RD Gateway がプロトコル変換をしてくれます。

今回の機能強化により、MSTSC と RD Gateway の間に、Azure アプリケーションプロキシを配置することができるようになりました。RDS への入り口に Azure アプリケーションプロキシーを使用できるので、社外から社内 RDP 接続性を簡単に高められるのはもちろんのこと、企業システムのインターネット側フロントエンドを Azure が肩代わりするので、フロントエンド特有の基本的なセキュリティ対策や DDoS 対策を企業が行う必要がないといったメリットがあります（もちろん、この部分に関してのみです）。

Azure アプリケーションプロキシーを経由して社内サービスを公開する際は、以下の2つの方法から選択することができます。

• Azure AD による事前認証を必須にする
• パススルー（Azure AD による認証なし）

今回の機能強化では「パススルー（認証なし）」で外部に公開することが可能になったということです。

展開方法は簡単です。

1. Azure アプリケーションプロキシーで RD Gateway を公開。このとき、パススルーを使用する。
   
2. RD Gateway に アプリケーションプロキシ コネクタ をインストール
3. MSTSC にアプリケーションプロキシーで設定したURLを RD ゲートウェイとして設定（本家 Blog のほうには https://rdg.contoso.com/）と書かれていますが、前後の「https:// と / 」は必要ありません）。

一方 RD Web Access を使用する場合はどうかといえば、これも Azure アプリケーションプロキシーで外部に公開することが可能です。この場合は以下の図の通り事前認証を使うことができます。この場合、Office 365 を使用するなど Azure AD に既にサインインしていると、RD Web Access には SSO でアクセスできます。

さて、問題はこの後なんです。

RD Gateway への接続はパススルーで公開できるという話はしました。パススルーで公開するってことは、RD Gateway を通過する際に認証を要求されるということです。

MSTSC を使用している場合であれば、MSTSC の「全般」タブで ユーザーID を指定し、あとからパスワードを入力しなければなりません。このとき「資格情報を保存できるようにする」をチェックしておけば、次回からはユーザー ID とパスワードの入力は回避することができます。

RD Web Access を使用して、ブラウザから直接リモートデスクトップ接続（Remote App も同様）した場合は、ブラウザ内で Active X クライアントを使用することになります（みなさん、Active X 覚えてますか？）。

この RD 用 Active X クライアントを使用して RD Gateway にアクセスする場合も、当然認証が必要なのですが、唯一 SSO が可能なシチュエーションがあります。それが、

• RD Web Access の認証フォームを経由して AD ドメインにログオンし、ローカルに資格情報をキャッシュした場合

です。

しかしながら、Azure アプリケーションプロキシーの Azure AD 事前認証を使用すると、Azure アプリケーションプロキシ コネクタ が Kerberos を使用してバックエンドの AD DS で認証を行います。SSO の前提条件である フォームによる AD 認証でないため、ローカルに資格情報はキャッシュされません。

つまり、RD Web Access にサインインし、アイコンをクリックしてリモートデスクトップ接続しようとすると、Active Directory ドメイによるサインイン画面が表示されることになります。

では、RD Web Access のサインインと RD Active X クライアントの SSO を実現しようとすると、どのように構成すべきでしょう？

以下の図のように、RD Web Access もパススルーで公開します。こうすることで、RD Web Access へのログオンは Active Directory ドメインに対するフォーム認証になります。その結果、資格情報はクライアントにキャッシュされるので、続いて呼び出される RD Active X クライアントは SSO で RD Gateway にアクセスすることができます。

まだ、いまいち美しくはありませんが、RD Gateway に Azure アプリケーションプロキシーが使用できるようになったというのは、「美しいハイブリッドクラウド設計」への第一歩だと思うのです。