SharePoint、Exchange、および RDG によるアプリケーションの発行
適用対象: Windows Server 2022、Windows Server 2019、Windows Server 2016
この内容はオンプレミス版の Web アプリケーション プロキシに関連しています。 クラウドでオンプレミス アプリケーションに安全にアクセスする方法については、「Microsoft Entra アプリケーション プロキシのコンテンツ」を参照してください。
このトピックでは、Web アプリケーション プロキシを介して SharePoint Server、Exchange Server またはリモート デスクトップ ゲートウェイ (RDP) を公開するために必要となるタスクについて説明します。
注意
この情報は現状のまま提供されます。 リモート デスクトップ サービスは、Azure App Proxy を使用して、オンプレミス アプリケーションへの安全なリモート アクセスを提供することをサポートし、推奨しています。
SharePoint Server の公開
SharePoint サイトに要求ベース認証または統合 Windows 認証を構成する際、Web アプリケーション プロキシ経由で SharePoint サイトを公開できます。 事前認証に Active Directory フェデレーションサービス (AD FS) を使用する場合は、いずれかのウィザードを使用して証明書利用者を構成する必要があります。
SharePoint サイトで要求ベース認証を使用する場合、証明書利用者信頼の追加ウィザードを利用し、アプリケーションに証明書利用者信頼を構成する必要があります。
SharePoint サイトで統合 Windows 認証を使用する場合、非要求ベースの証明書利用者信頼の追加ウィザードを利用し、アプリケーションに証明書利用者信頼を構成する必要があります。 KDC を構成する場合、要求ベースの Web アプリケーションと共に IWA を使用できます。
統合 Windows 認証を利用した認証をユーザーに許可するには、Web アプリケーション プロキシ サーバーがドメインに参加する必要があります。
Kerberos 制約の委任をサポートするようにアプリケーションを構成する必要があります。 この作業は、どのアプリケーションについてもドメイン コントローラーで実行できます。 Windows Server 2012 R2 または Windows Server 2012 で実行されている場合、バックエンド サーバーでアプリケーションを直接構成することもできます。 詳細については、「 Kerberos 認証の新機能」を参照してください。 Web アプリケーション プロキシ サーバーがバックエンド サーバーのサービス プリンシパル名 (SPN) への委任用に構成されていることを確認する必要もあります。 統合 Windows 認証を利用してアプリケーションを公開するように Web アプリケーション プロキシを構成する方法については、「統合 Windows 認証を使用するようにサイトを構成する」を参照してください。
SharePoint サイトを代替アクセス マッピング (AAM) とホスト名の付いたサイト コレクションのいずれかを利用して構成する場合、異なる外部 URL とバックエンド サーバー URL を使用してアプリケーションを公開できます。 ただし、AAM またはホスト名の付いたサイト コレクションを使用して SharePoint サイトを構成しない場合、同じ外部 URL とバックエンド サーバー URL を使用する必要があります。
Exchange Server の公開
次の表は、Web アプリケーション プロキシ経由で公開できる Exchange サービスとそれらのサービスでサポートされる事前認証をまとめたものです。
| Exchange サービス | 事前認証 | メモ |
|---|---|---|
| Outlook Web アプリ | - 非要求ベース認証を使用するAD FS - パススルー - 社内 Exchange 2013 Service Pak 1 (SP1) の要求ベース認証を使用した AD FS |
詳細については、次のトピックを参照してください。 AD FS のクレームベース認証を Outlook Web App および EAC で使用する |
| Exchange コントロール パネル | パススルー | |
| Outlook Anywhere | パススルー | Outlook Anywhere が正しく機能するには次の追加の URL を公開する必要があります。 - 自動検出、EWS、およびOAB (Outlookキャッシュモードの場合) のURL。 |
| Exchange ActiveSync | パススルー HTTP 基本承認プロトコルを使用する AD FS |
|
| Exchange Web サービス | パススルー | |
| 自動検出 | パススルー | |
| オフライン アドレス帳 | パススルー |
統合 Windows 認証を使用して Outlook Web アプリを公開するには、非要求ベースの証明書利用者信頼の追加ウィザードを利用し、アプリケーションに証明書利用者信頼を構成する必要があります。
ユーザーが Kerberos の制約付き委任を使用して認証できるには、Web アプリケーション プロキシ サーバーをドメインに参加させる必要があります。
アプリケーションが Kerberos 認証の委任をサポートするように構成する必要があります。 さらに、Web サービスが実行されるアカウントにサービス プリンシパル名 (SPN) を登録する必要があります。 これは、ドメイン コントローラーまたはバックエンド サーバーで行います。 負荷分散された Exchange 環境では、これには代替サービス アカウントを使用する必要があります。「負荷分散されたクライアント アクセス サーバーの Kerberos 認証の構成」を参照してください。
Windows Server 2012 R2 または Windows Server 2012 で実行されている場合、バックエンド サーバーでアプリケーションを直接構成することもできます。 詳細については、「 Kerberos 認証の新機能」を参照してください。 Web アプリケーション プロキシ サーバーがバックエンド サーバーのサービス プリンシパル名 (SPN) への委任用に構成されていることを確認する必要もあります。
Web アプリケーション プロキシを介したリモート デスクトップ ゲートウェイの公開
リモート アクセス ゲートウェイへのアクセスを制限し、リモート アクセスの事前認証を追加する場合は、Web アプリケーション プロキシ を使用して展開できます。 これは、MFA を含む RDG の豊富な事前認証を確認する優れた方法です。 事前認証なしで発行することもできます。この場合、システムへの単一のエントリ ポイントが提供されます。
Web アプリケーション プロキシ パススルー認証を使用して RDG でアプリケーションを公開する方法
インストールは、RD Web アクセス (/rdweb) ロールと RD ゲートウェイ (rpc) ロールが同じサーバー上にあるか、異なるサーバーにあるかによって異なります。
RD Web アクセス および RD ゲートウェイの役割が同じ RDG サーバーでホストされている場合は、https://rdg.contoso.com/ などの Web アプリケーション プロキシでルート FQDN を発行するのみです。
また、https://rdg.contoso.com/rdweb/ や https://rdg.contoso.com/rpc/ など、2 つの仮想ディレクトリを個別に公開することもできます。
RD Web アクセスと RD ゲートウェイが別々の RDG サーバーでホストされている場合は、2 つの仮想ディレクトリを個別に公開する必要があります。 https://rdweb.contoso.com/rdweb/ と https://gateway.contoso.com/rpc/ など、同じ外部 FQDN または異なる外部 FQDN を使用 できます。
外部 FQDN と内部 FQDN が異なる場合は、RDWeb 公開ルールで要求ヘッダーの変換を無効に「しない」必要があります。 このためには、Web アプリケーション プロキシ サーバーで次の PowerShell スクリプトを実行しますが、既定で有効であるはずです。
Get-WebApplicationProxyApplication applicationname | Set-WebApplicationProxyApplication -DisableTranslateUrlInRequestHeaders:$false注意
RemoteApp とデスクトップ接続、iOS リモート デスクトップ接続などのリッチ クライアントをサポートする必要がある場合、これらは事前認証をサポートしていないため、パススルー認証を使用して RDG を発行する必要があります。
Web アプリケーション プロキシ パススルー認証を使用して RDG でアプリケーションを公開する方法
RDG を使用したWeb アプリケーション プロキシの事前認証は、Internet Explorer によって取得された事前認証 Cookie を リモート デスクトップ接続 クライアント (mstsc.exe) に渡して動作します。 これは次に、リモート デスクトップ接続クライアント (mstsc.exe) によって使用されます。 これは、リモート デスクトップ接続クライアントによって認証の証明として使用されます。
次の手順は、クライアントに送信されるリモート アプリ RDP ファイルに必要なカスタム RDP プロパティを含めることをコレクション サーバーに指示します。 これらは、事前認証が必要であることをクライアントに通知して、事前認証サーバー アドレスの Cookie をリモート デスクトップ接続クライアント (mstsc.exe) に渡します。 これにより、Web アプリケーション プロキシ アプリケーションで HttpOnly 機能を無効にすると同時に、リモート デスクトップ接続 クライアント (mstsc.exe) がブラウザーから取得した Web アプリケーション プロキシ Cookie が利用できるようになります。
RD Web アクセス サーバーへの認証では、引き続き RDWeb アクセス フォームのログオンを使用します。 これにより、RD Web アクセス ログオン フォームがクライアント側の資格情報ストアを作成し、その後のリモート アプリの起動にリモート デスクトップ接続クライアント (mstsc.exe) で使用できるため、ユーザー認証プロンプト数が最小化されます。
まず、要求対応アプリを発行する場合と同様に AD FS で証明書利用者信頼を手動で作成します。 つまり、事前認証を適用するために存在するダミーの証明書利用者信頼を作成する必要があります。これにより、公開サーバーへの Kerberos の制約付き委任なしで事前認証を取得できます。 ユーザーが認証されると、他のすべてが渡されます。
警告
委任を使用する方が望ましいと思われるかもしれませんが、mstsc SSO 要件は完全には解決しません。また、クライアントは RD ゲートウェイ 認証自体を処理する必要があるため、/rpc ディレクトリに委任する際に問題が発生します。
手動で証明書利用者信頼を作成するには、次の AD FS 管理コンソールの手順に従います。
証明書利用者信頼の追加 ウィザードを使用する
「証明書利用者に関するデータを手動で入力する」を選択します。
すべての既定値を受け入れます。
[証明書利用者信頼識別子] に、RDG アクセスに使用する外部 FQDN (例: https://rdg.contoso.com/) を入力します。
これは、Web アプリケーション プロキシでアプリを発行するときに使用する証明書利用者の信頼となります。
サイトのルート (たとえば、https://rdg.contoso.com/) を Web アプリケーション プロキシで公開します。 事前認証を AD FS に設定して、上で作成した証明書利用者信頼を使用します。 これにより、/rdweb と /rpc が同じ Web アプリケーション プロキシ認証 Cookie を使用できるようになります。
/rdweb と /rpc を個別のアプリケーションとして公開したり、さらに異なる公開サーバーを使用することもできます。 Web アプリケーション プロキシのトークンが証明書利用者信頼に対して発行されるのと同じ証明書利用者信頼を使用して両方を公開することを確認する必要があります。これにより、同じ証明書利用者信頼で公開されるアプリケーション全体で有効となります。
外部 FQDN と内部 FQDN が異なる場合は、RDWeb 公開ルールで要求ヘッダーの変換を無効に「しない」必要があります。 このためには、Web アプリケーション プロキシ サーバーで次の PowerShell スクリプトを実行しますが、これは既定で有効であるはずです。
Get-WebApplicationProxyApplication applicationname | Set-WebApplicationProxyApplication -DisableTranslateUrlInRequestHeaders:$trueRDG で発行されたアプリケーション上の Web アプリケーション プロキシ HttpOnly Cookie プロパティを無効にします。 RDG ActiveX コントロールが Web アプリケーション プロキシ 認証 Cookie にアクセスできるためには、Web アプリケーション プロキシ Cookie で HttpOnly プロパティを無効にする必要があります。
これには、Windows RT 8.1、Windows 8.1、Windows Server 2012 R2 (KB3000850) の 2014 年 11 月の更新プログラム ロールアップをインストールする必要があります。
修正プログラムをインストールした後、関連するアプリケーション名を指定して、Web アプリケーション プロキシ サーバーで次の PowerShell スクリプトを実行します。
Get-WebApplicationProxyApplication applicationname | Set-WebApplicationProxyApplication -DisableHttpOnlyCookieProtection:$trueHttpOnly を無効にすると、RDG ActiveX 制御が Web アプリケーション プロキシ認証 Cookie にアクセスできます。
コレクション サーバーで関連する RDG コレクションを構成して、リモート デスクトップ接続 クライアント (mstsc.exe) が rdp ファイルで事前認証が必要であることを把握できるようにします。
Windows Server 2012 および Windows Server 2012 R2 では、これは、RDG コレクション サーバーで次の PowerShell コマンドレットを実行することで達成できます。
Set-RDSessionCollectionConfiguration -CollectionName "<yourcollectionname>" -CustomRdpProperty "pre-authentication server address:s: <https://externalfqdn/rdweb/>`nrequire pre-authentication:i:1"独自の値に置き換える場合は、< と > をの角かっこを必ず削除します。たとえば、
Set-RDSessionCollectionConfiguration -CollectionName "MyAppCollection" -CustomRdpProperty "pre-authentication server address:s: https://rdg.contoso.com/rdweb/`nrequire pre-authentication:i:1"Windows Server 2008 R2 では、次の操作を行います。
管理者特権を持つアカウントでターミナル サーバーにログオンします。
スタート>管理ツール>ターミナル サービス>TS RemoteApp マネージャー に移動します。
[RDP 設定] の隣の [TS RemoteApp マネージャー] の Overview ウィンドウで、[変更] をクリックします。
[カスタム RDP 設定] タブで、[カスタム RDP 設定] ボックスに次の RDP 設定を入力します。
pre-authentication server address: s: https://externalfqdn/rdweb/require pre-authentication:i:1完了したら [適用する] をクリックします。
これにより、クライアントに送信される RDP ファイルにカスタム RDP プロパティを含めるようにコレクション サーバーに指示されます。 これらは、事前認証が必要であることをクライアントに通知して、事前認証サーバー アドレスの Cookie をリモート デスクトップ接続クライアント (mstsc.exe) に渡します。 これにより、Web アプリケーション プロキシ アプリケーションで HttpOnly を無効にすると同時に、リモート デスクトップ接続 クライアント (mstsc.exe) がブラウザーから取得した Web アプリケーション プロキシ認証が利用できるようになります。
RDP の詳細については、「TS ゲートウェイ OTP シナリオの構成」を参照してください。