Share via


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 がプロトコル変換をしてくれます。

image

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

image

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

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

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

展開方法は簡単です。

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

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

image

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

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

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

image

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 にアクセスすることができます。

image

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