AD FS 事前認証を使用してアプリケーションを公開する

  • [アーティクル]

適用対象: Windows Server 2022、Windows Server 2019、Windows Server 2016

この内容はオンプレミス版の Web アプリケーション プロキシに関連しています。 クラウドでオンプレミス アプリケーションに安全にアクセスする方法については、「Microsoft Entra アプリケーション プロキシのコンテンツ」を参照してください。

このトピックでは、Active Directory フェデレーション サービス (AD FS) 事前認証を使用して Web アプリケーション プロキシ経由でアプリケーションを公開する方法について説明します。

AD FS 事前認証を使用して公開できるすべての種類のアプリケーションについて、フェデレーション サービスに AD FS 証明書利用者信頼を追加する必要があります。

一般的な AD FS 事前認証フローは次のようになります。

注意

この認証フローは、Microsoft Store アプリを使用するクライアントには適用されません。

  1. クライアント デバイスは、特定のリソース URL (https://app1.contoso.com/ など) にある、公開された Web アプリケーションにアクセスしようとします。

    リソース URL は Web アプリケーション プロキシが受信 HTTPS 要求をリッスンするパブリック アドレスです。

    HTTP から HTTPS へのリダイレクトが有効になっている場合、Web アプリケーション プロキシは受信 HTTP 要求もリッスンします。

  2. Web アプリケーション プロキシは、リソース URL や appRealm (証明書利用者の識別子) を含め、URL でエンコードされたパラメーターを使用して、AD FS サーバーに HTTPS 要求をリダイレクトします。

    ユーザーは、AD FS サーバーで必要とされる認証方法を使用して認証を行います。たとえば、ユーザー名とパスワード、ワンタイム パスワードを使用する 2 要素認証などです。

  3. ユーザーが認証された後、AD FS サーバーは、以下の情報を含む "エッジ トークン" と呼ばれるセキュリティ トークンを発行し、HTTPS 要求を再び Web アプリケーション プロキシ サーバーにリダイレクトします。

    • ユーザーがアクセスしようとしているリソースの識別子。

    • ユーザー プリンシパル名 (UPN) としてのユーザーの ID。

    • アクセス許可の承認有効期限。つまり、ユーザーは、期間限定でアクセスを許可されますが、期限を過ぎると再び認証する必要があります。

    • エッジ トークンの情報の署名。

  4. Web アプリケーション プロキシは次のように、エッジ トークンを使って AD FS サーバーからリダイレクトされた HTTPS 要求を受け取り、トークンを検証して使用します。

    • エッジ トークンの署名が、Web アプリケーション プロキシの構成で構成されたフェデレーション サービスで作成されたものであることを検証します。

    • トークンが適切なアプリケーション用に発行されていることを検証します。

    • トークンが期限切れになっていないこと検証します。

    • 必要に応じてユーザー ID を使用します。たとえば、バックエンド サーバーが統合 Windows 認証を使用するように構成されているときに、Kerberos チケットを取得するような場合です。

  5. エッジ トークンが有効である場合、Web アプリケーション プロキシは、HTTP または HTTPS を使用する公開された Web アプリケーションに HTTPS 要求を転送します。

  6. これで、クライアントは、公開された Web アプリケーションにアクセスできるようになります。ただし、公開されたアプリケーションで、ユーザーに追加の認証を要求するように構成されている場合があります。 たとえば、公開された Web アプリケーションが SharePoint サイトであり、追加の認証を要求しない場合、ユーザーのブラウザーに SharePoint サイトが表示されます。

  7. Web アプリケーション プロキシは、クライアント デバイスに Cookie を保存します。 この Cookie は、Web アプリケーション プロキシによって使用され、このセッションが既に事前認証済みであり、それ以上の事前認証が必要ではないことを識別します。

重要

外部 URL とバックエンド サーバーの URL を構成するときに、IP アドレスではなく、完全修飾ドメイン名 (FQDN) を含めます。

注意

このトピックでは、説明した手順の一部を自動化するのに使用できる Windows PowerShell コマンドレットのサンプルを示します。 詳細については、「コマンドレットの使用」を参照してください。

Web ブラウザー クライアント用の要求ベースのアプリケーションを公開する

認証の要求を使用するアプリケーションを公開するには、フェデレーション サービスにアプリケーションの証明書利用者信頼を追加する必要があります。

要求ベースのアプリケーションを公開し、ブラウザーからアプリケーションにアクセスする場合、一般的な認証フローは次のとおりです。

  1. クライアントが Web ブラウザーを使用して要求ベースのアプリケーション (https://appserver.contoso.com/claimapp/ など) にアクセスしようとします。

  2. Web ブラウザーが Web アプリケーション プロキシ サーバーに HTTPS 要求を送信し、このサーバーが AD FS サーバーに要求をリダイレクトします。

  3. AD FS サーバーは、ユーザーとデバイスを認証し、Web アプリケーション プロキシにその要求をリダイレクトします。 この要求にはエッジ トークンが含まれています。 ユーザーは既に AD FS サーバーに対して認証を実行しているため、AD FS サーバーはシングル サインオン (SSO) の Cookie を要求に追加します。

  4. Web アプリケーション プロキシはトークンを検証して固有の Cookie を追加し、バックエンド サーバーに要求を転送します。

  5. バックエンド サーバーは AD FS サーバーに要求をリダイレクトしてアプリケーション セキュリティ トークンを取得します。

  6. 要求は AD FS サーバーによってバックエンド サーバーにリダイレクトされます。 この要求には、アプリケーション トークンと SSO の Cookie が含まれています。 ユーザーはアプリケーションへのアクセスを許可され、ユーザー名またはパスワードを入力する必要はありません。

この手順では、Web ブラウザー クライアントからアクセスする、SharePoint サイトなどの要求ベースのアプリケーションを公開する方法について説明します。 開始する前に、次の作業が完了していることを確認します。

  • AD FS 管理コンソールでアプリケーションの証明書利用者信頼を作成する。

  • Web アプリケーション プロキシ サーバーの証明書が、公開するサンプル アプリケーションに適していることを確認する。

要求ベースのアプリケーションを公開するには

  1. Web アプリケーション プロキシ サーバーで、リモート アクセス管理コンソールの [ナビゲーション] ペインに示されている Web アプリケーション プロキシをクリックし、[タスク] ウィンドウで [公開] をクリックします。

  2. 新しいアプリケーションの公開ウィザードの [ようこそ] ページで [次へ] をクリックします。

  3. [事前認証] ページで、[Active Directory フェデレーション サービス (AD FS)] をクリックし、[次へ] をクリックします。

  4. [サポート対象のクライアント] ページで、[Web および MSOFBA] を選択し、[次へ] をクリックします。

  5. [証明書利用者] ページの証明書利用者の一覧から、公開するアプリケーションの証明書利用者を選択し、[次へ] をクリックします。

  6. [公開設定] ページで、次の操作を行い、[次へ] をクリックします。

    • [名前] ボックスに、アプリケーションのフレンドリ名を入力します。

      この名前は、リモート アクセス管理コンソールの公開するアプリケーションの一覧でのみ使用されます。

    • [外部 URL] ボックスに、このアプリケーションの外部 URL (https://sp.contoso.com/app1/ など) を入力します。

    • [外部証明書] の一覧で、外部 URL に対応するサブジェクトを持つ証明書を選択します。

    • [バックエンド サーバー URL] ボックスに、バックエンド サーバーの URL を入力します。 この値は、外部 URL を入力すると自動的に入力されます。バックエンド サーバーの URL が異なる場合のみ、この値を変更してください (https://sp/app1/. など)。

      注意

      Web アプリケーション プロキシでは、URL のホスト名を変換できますが、パス名は変換できません。 そのため、異なるホスト名を入力できますが、同じパス名を入力する必要があります。 たとえば、外部 URL として「https://apps.contoso.com/app1/」を入力し、バックエンド サーバーの URL として「https://app-server/app1/.」を入力できます。 ただし、外部 URL として「https://apps.contoso.com/app1/」を入力し、バックエンド サーバーの URL として「https://apps.contoso.com/internal-app1/」を入力することはできません。

  7. [確認] ページで設定を確認し、[公開] をクリックします。 PowerShell コマンドをコピーして、追加で公開するアプリケーションをセットアップすることができます。

  8. [結果] ページで、アプリケーションが正常に公開されたことを確認し、[閉じる] をクリックします。

Windows PowerShell の同等のコマンド

次の Windows PowerShell コマンドレットは、前の手順と同じ機能を実行します。 各コマンドレットを単一行に入力します。ただし、ここでは、書式上の制約があるために、複数行に改行されて表示される場合があります。

Add-WebApplicationProxyApplication
    -BackendServerURL 'https://sp.contoso.com/app1/'
    -ExternalCertificateThumbprint '1a2b3c4d5e6f1a2b3c4d5e6f1a2b3c4d5e6f1a2b'
    -ExternalURL 'https://sp.contoso.com/app1/'
    -Name 'SP'
    -ExternalPreAuthentication ADFS
    -ADFSRelyingPartyName 'SP_Relying_Party'

Web ブラウザー クライアント用の統合 Windows 認証ベースのアプリケーションを公開する

Web アプリケーション プロキシを使用して、統合 Windows 認証を使用するアプリケーションを公開できます。つまり、Web アプリケーション プロキシは必要に応じて事前認証を実行し、統合 Windows 認証を使用する公開されたアプリケーションに対して SSO を実行できます。 統合 Windows 認証を使用するアプリケーションを公開するには、フェデレーション サービスに要求対応ではない証明書利用者信頼を追加する必要があります。

Web アプリケーション プロキシでシングル サインオン (SSO) を実行し、Kerberos の制約付き委任を使って資格情報の委任を実行できるようにするには、Web アプリケーション プロキシ サーバーがドメインに参加している必要があります。 「Active Directory を計画する」を参照してください。

統合 Windows 認証を使用するアプリケーションにユーザーがアクセスできるようにするには、Web アプリケーション プロキシ サーバーがユーザーの委任を公開されたアプリケーションに提供できる必要があります。 この作業は、どのアプリケーションについてもドメイン コントローラーで実行できます。 Windows Server 2012 R2 または Windows Server 2012 で実行されている場合、バックエンド サーバーでこの作業を実行できます。 詳細については、「 Kerberos 認証の新機能」を参照してください。

統合 Windows 認証を利用してアプリケーションを公開するように Web アプリケーション プロキシを構成する方法については、「統合 Windows 認証を使用するようにサイトを構成する」を参照してください。

バックエンド サーバーに対して統合 Windows 認証を使用している場合、Web アプリケーション プロキシと公開されたアプリケーションの間の認証は要求ベースではなく、代わりに Kerberos の制約付き委任を使用して、アプリケーションでエンド ユーザーを認証します。 一般的なフローは次のとおりです。

  1. クライアントが Web ブラウザーを使用して要求ベースではないアプリケーション (https://appserver.contoso.com/nonclaimapp/ など) にアクセスしようとします。

  2. Web ブラウザーが Web アプリケーション プロキシ サーバーに HTTPS 要求を送信し、このサーバーが AD FS サーバーに要求をリダイレクトします。

  3. AD FS サーバーは、ユーザーを認証し、Web アプリケーション プロキシにその要求をリダイレクトします。 この要求にはエッジ トークンが含まれています。

  4. Web アプリケーション プロキシがトークンを検証します。

  5. トークンが有効である場合、Web アプリケーション プロキシは、ユーザーの代わりにドメイン コントローラーから Kerberos チケットを取得します。

  6. Web アプリケーション プロキシは、Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) トークンの一部として、Kerberos チケットを要求に追加し、要求をバックエンド サーバーに転送します。 この要求には Kerberos チケットが含まれています。そのため、ユーザーはそれ以上の認証を使わずに、アプリケーションへのアクセスが許可されます。

この手順では、Web ブラウザー クライアントからアクセスする、Outlook Web アプリなどの統合 Windows 認証を使用するアプリケーションを公開する方法について説明します。 開始する前に、次の作業が完了していることを確認します。

  • AD FS 管理コンソールで、アプリケーションの要求対応ではない証明書利用者信頼を作成する。

  • Set-ADUser コマンドレットを -PrincipalsAllowedToDelegateToAccount パラメーターを指定して使用することによって、ドメイン コントローラーで Kerberos の制約付き委任をサポートするようにバックエンド サーバーを構成する。 バックエンド サーバーが Windows Server 2012 R2 または Windows Server 2012 で実行されている場合、この PowerShell コマンドをバックエンド サーバーで実行することもできます。

  • Web アプリケーション プロキシ サーバーがバックエンド サーバーのサービス プリンシパル名 (SPN) への委任用に構成されていることを確認する。

  • Web アプリケーション プロキシ サーバーの証明書が、公開するサンプル アプリケーションに適していることを確認する。

要求ベースではないアプリケーションを公開するには

  1. Web アプリケーション プロキシ サーバーで、リモート アクセス管理コンソールの [ナビゲーション] ペインに示されている Web アプリケーション プロキシをクリックし、[タスク] ウィンドウで [公開] をクリックします。

  2. 新しいアプリケーションの公開ウィザードの [ようこそ] ページで [次へ] をクリックします。

  3. [事前認証] ページで、[Active Directory フェデレーション サービス (AD FS)] をクリックし、[次へ] をクリックします。

  4. [サポート対象のクライアント] ページで、[Web および MSOFBA] を選択し、[次へ] をクリックします。

  5. [証明書利用者] ページの証明書利用者の一覧から、公開するアプリケーションの証明書利用者を選択し、[次へ] をクリックします。

  6. [公開設定] ページで、次の操作を行い、[次へ] をクリックします。

    • [名前] ボックスに、アプリケーションのフレンドリ名を入力します。

      この名前は、リモート アクセス管理コンソールの公開するアプリケーションの一覧でのみ使用されます。

    • [外部 URL] ボックスに、このアプリケーションの外部 URL (https://owa.contoso.com/ など) を入力します。

    • [外部証明書] の一覧で、外部 URL に対応するサブジェクトを持つ証明書を選択します。

    • [バックエンド サーバー URL] ボックスに、バックエンド サーバーの URL を入力します。 この値は、外部 URL を入力すると自動的に入力されます。バックエンド サーバーの URL が異なる場合のみ、この値を変更してください (https://owa/. など)。

      注意

      Web アプリケーション プロキシでは、URL のホスト名を変換できますが、パス名は変換できません。 そのため、異なるホスト名を入力できますが、同じパス名を入力する必要があります。 たとえば、外部 URL として「https://apps.contoso.com/app1/」を入力し、バックエンド サーバーの URL として「https://app-server/app1/.」を入力できます。 ただし、外部 URL として「https://apps.contoso.com/app1/」を入力し、バックエンド サーバーの URL として「https://apps.contoso.com/internal-app1/」を入力することはできません。

    • [バックエンド サーバー SPN] ボックスに、バックエンド サーバーのサービス プリンシパル名 (HTTP/owa.contoso.com など) を入力します。

  7. [確認] ページで設定を確認し、[公開] をクリックします。 PowerShell コマンドをコピーして、追加で公開するアプリケーションをセットアップすることができます。

  8. [結果] ページで、アプリケーションが正常に公開されたことを確認し、[閉じる] をクリックします。

Windows PowerShell の同等のコマンド

次の Windows PowerShell コマンドレットは、前の手順と同じ機能を実行します。 各コマンドレットを単一行に入力します。ただし、ここでは、書式上の制約があるために、複数行に改行されて表示される場合があります。

Add-WebApplicationProxyApplication
    -BackendServerAuthenticationSpn 'HTTP/owa.contoso.com'
    -BackendServerURL 'https://owa.contoso.com/'
    -ExternalCertificateThumbprint '1a2b3c4d5e6f1a2b3c4d5e6f1a2b3c4d5e6f1a2b'
    -ExternalURL 'https://owa.contoso.com/'
    -Name 'OWA'
    -ExternalPreAuthentication ADFS
    -ADFSRelyingPartyName 'Non-Claims_Relying_Party'

MS-OFBA を使用するアプリケーションを公開する

Web アプリケーション プロキシは、バックエンド サーバーのドキュメントやデータにアクセスする、Microsoft Word などの Microsoft Office クライアントからのアクセスをサポートします。 これらのアプリケーションと標準的なブラウザーの唯一の違いは、STS へのリダイレクトが、通常の HTTP リダイレクトではなく、特別な MS-OFBA ヘッダーによって行われる点です。このヘッダーについては、https://msdn.microsoft.com/library/dd773463(v=office.12).aspx を参照してください。 バックエンド アプリケーションは、要求ベースまたは IWA ベースです。 MS-OFBA を使用するクライアント用のアプリケーションを公開するには、フェデレーション サービスにアプリケーションの証明書利用者信頼を追加する必要があります。 アプリケーションに応じて、要求ベースの認証または統合 Windows 認証を使用できます。 そのため、アプリケーションに応じて、関連する証明書利用者信頼を追加する必要があります。

Web アプリケーション プロキシでシングル サインオン (SSO) を実行し、Kerberos の制約付き委任を使って資格情報の委任を実行できるようにするには、Web アプリケーション プロキシ サーバーがドメインに参加している必要があります。 「Active Directory を計画する」を参照してください。

アプリケーションが要求ベースの認証を使用している場合、追加の計画手順はありません。 アプリケーションで統合 Windows 認証を使用している場合は、「Web ブラウザー クライアント用の統合 Windows 認証ベース アプリケーションを公開する」を参照してください。

要求ベースの認証を使用する場合、MS-OFBA プロトコルを使用するクライアントの認証フローは次のとおりです。 このシナリオの認証では、URL または本文でアプリケーション トークンを使用できます。

  1. ユーザーが Office プログラムで作業しているときに、[最近使ったファイル] の一覧から、SharePoint サイトのファイルを開きます。

  2. Office プログラムは、ユーザーに資格情報の入力を要求するブラウザー コントロールを含むウィンドウを表示します。

    注意

    場合によっては、クライアントが既に認証されているため、このウィンドウが表示されないことがあります。

  3. Web アプリケーション プロキシは要求を AD FS サーバーにリダイレクトし、このサーバーが認証を実行します。

  4. AD FS サーバーは、Web アプリケーション プロキシにその要求をリダイレクトします。 この要求にはエッジ トークンが含まれています。

  5. ユーザーは既に AD FS サーバーに対して認証を実行しているため、AD FS サーバーはシングル サインオン (SSO) の Cookie を要求に追加します。

  6. Web アプリケーション プロキシはトークンを検証し、バックエンド サーバーに要求を転送します。

  7. バックエンド サーバーは AD FS サーバーに要求をリダイレクトしてアプリケーション セキュリティ トークンを取得します。

  8. 要求はバックエンド サーバーにリダイレクトされます。 この要求には、アプリケーション トークンと SSO の Cookie が含まれています。 ユーザーは SharePoint サイトへのアクセスを許可され、ファイルを表示するためにユーザー名またはパスワードを入力する必要はありません。

MS-OFBA を使用するアプリケーションを公開する手順は、要求ベースのアプリケーションまたは要求ベースではないアプリケーションの手順と同じです。 要求ベースのアプリケーションについては、「Web ブラウザー クライアント用の要求ベースのアプリケーションを公開する」を参照してください。要求ベースではないアプリケーションについては、「Web ブラウザー クライアント用の統合 Windows 認証ベースのアプリケーションを公開する」を参照してください。 Web アプリケーション プロキシはクライアントを自動検出し、必要に応じてユーザーを認証します。

HTTP Basic を使用するアプリケーションを公開する

HTTP Basic は、多数のプロトコルによって使用される認証プロトコルで、スマートフォンなどのリッチ クライアントを Exchange メールボックスに接続します。 HTTP Basic の詳細については、RFC 2617 を参照してください。 従来、Web アプリケーション プロキシは、リダイレクトを使用して AD FS とやり取りします。ほとんどのリッチ クライアントでは Cookie または状態管理をサポートしていません。 このようにして、Web アプリケーション プロキシでは、HTTP アプリがアプリケーションの要求対応ではない証明書利用者信頼をフェデレーション サービスに受信できるようにします。 「Active Directory を計画する」を参照してください。

HTTP Basic を使用するクライアントの認証フローを以下で説明し、次の図に示します。

Authentication diagram for HTTP Basic

  1. ユーザーは、公開された Web アプリケーションに電話クライアントでアクセスを試みます。

  2. アプリは Web アプリケーション プロキシによって発行された URL に HTTPS 要求を送信します。

  3. 要求に資格情報が含まれていない場合、Web アプリケーション プロキシは、AD FS 認証サーバーの URL を含む HTTP 401 応答をアプリに返します。

  4. ユーザーは、承認が Basic に設定され、ユーザーのユーザー名と Base 64 で暗号化されたパスワードが www-authenticate 要求ヘッダーに指定された HTTPS 要求をアプリに再度送信します。

  5. デバイスを AD FS にリダイレクトできないので、Web アプリケーション プロキシは、ユーザー名とパスワードを含む資格情報を使用して AD FS に認証要求を送信します。 トークンが、デバイスの代わりに取得されます。

  6. AD FS に送信される要求の数を最小限に抑えるために、Web アプリケーション プロキシでは、トークンが有効である限り、キャッシュされたトークンを使用して後続のクライアント要求を検証します。 Web アプリケーション プロキシがキャッシュを定期的にクリーンアップします。 パフォーマンス カウンターを使用して、キャッシュのサイズを表示できます。

  7. トークンが有効な場合、Web アプリケーション プロキシはバックエンド サーバーに要求を転送し、発行された Web アプリケーションへのアクセス権がユーザーに付与されます。

次の手順では、HTTP Basic アプリケーションを公開する方法について説明します。

HTTP Basic アプリケーションを公開するには

  1. Web アプリケーション プロキシ サーバーで、リモート アクセス管理コンソールの [ナビゲーション] ペインに示されている Web アプリケーション プロキシをクリックし、[タスク] ウィンドウで [公開] をクリックします。

  2. 新しいアプリケーションの公開ウィザードの [ようこそ] ページで [次へ] をクリックします。

  3. [事前認証] ページで、[Active Directory フェデレーション サービス (AD FS)] をクリックし、[次へ] をクリックします。

  4. [サポート対象のクライアント] ページで、[HTTP 基本] を選択し、[次へ] をクリックします。

    ワークプレースに参加させるデバイスからのみ、Exchange へのアクセスを有効にする場合は、[ワークプレースに参加しているデバイスでのみアクセスを有効にする] ボックスをオンにします。 詳細については、「任意のデバイスからの職場への参加による業務用アプリケーション間の SSO とシームレスな 2 要素認証」を参照してください。

  5. [証明書利用者] ページの証明書利用者の一覧から、公開するアプリケーションの証明書利用者を選択し、[次へ] をクリックします。 この一覧には、要求対応の証明書利用者だけが含まれている点に注意してください。

  6. [公開設定] ページで、次の操作を行い、[次へ] をクリックします。

    • [名前] ボックスに、アプリケーションのフレンドリ名を入力します。

      この名前は、リモート アクセス管理コンソールの公開するアプリケーションの一覧でのみ使用されます。

    • [外部 URL] ボックスに、このアプリケーションの外部 URL (mail.contoso.com など) を入力します。

    • [外部証明書] の一覧で、外部 URL に対応するサブジェクトを持つ証明書を選択します。

    • [バックエンド サーバー URL] ボックスに、バックエンド サーバーの URL を入力します。 この値は、外部 URL を入力すると自動的に入力されます。バックエンド サーバーの URL が異なる場合のみ、この値を変更してください (mail.contoso.com など)。

  7. [確認] ページで設定を確認し、[公開] をクリックします。 PowerShell コマンドをコピーして、追加で公開するアプリケーションをセットアップすることができます。

  8. [結果] ページで、アプリケーションが正常に公開されたことを確認し、[閉じる] をクリックします。

Windows PowerShell の同等のコマンド

次の Windows PowerShell コマンドレットは、前の手順と同じ機能を実行します。 各コマンドレットを単一行に入力します。ただし、ここでは、書式上の制約があるために、複数行に改行されて表示される場合があります。

この Windows PowerShell スクリプトを使用すると、ワークプレースに参加させるデバイスだけではなく、すべてのデバイスの事前認証が有効になります。

Add-WebApplicationProxyApplication
     -BackendServerUrl 'https://mail.contoso.com'
     -ExternalCertificateThumbprint '697F4FF0B9947BB8203A96ED05A3021830638E50'
     -ExternalUrl 'https://mail.contoso.com'
     -Name 'Exchange'
     -ExternalPreAuthentication ADFSforRichClients
     -ADFSRelyingPartyName 'EAS_Relying_Party'

次に示すのは、ワークプレースに参加させるデバイスのみです。

Add-WebApplicationProxyApplication
     -BackendServerUrl 'https://mail.contoso.com'
     -ExternalCertificateThumbprint '697F4FF0B9947BB8203A96ED05A3021830638E50'
     -EnableHTTPRedirect:$true
     -ExternalUrl 'https://mail.contoso.com'
     -Name 'Exchange'
     -ExternalPreAuthentication ADFSforRichClients
     -ADFSRelyingPartyName 'EAS_Relying_Party'

Microsoft Store アプリなど、OAuth2 を使用するアプリケーションを公開する

Microsoft Store アプリ用のアプリケーションを公開するには、フェデレーション サービスにアプリケーションの証明書利用者信頼を追加する必要があります。

Web アプリケーション プロキシでシングル サインオン (SSO) を実行し、Kerberos の制約付き委任を使って資格情報の委任を実行できるようにするには、Web アプリケーション プロキシ サーバーがドメインに参加している必要があります。 「Active Directory を計画する」を参照してください。

注意

Web アプリケーション プロキシは、OAuth 2.0 プロトコルを使用する Microsoft Store アプリについてのみ、公開をサポートします。

AD FS 管理コンソールで、OAuth エンドポイントがプロキシに対応していることを確認する必要があります。 OAuth エンドポイントがプロキシに対応しているかどうかを確認するには、AD FS 管理コンソールを開き、[サービス] を展開して、[エンドポイント] をクリックします。次に、[エンドポイント] の一覧で OAuth エンドポイントを見つけ、[プロキシ有効] 列の値が [はい] であることを確認します。

Microsoft Store アプリを使用するクライアントの認証フローは次のとおりです。

注意

Web アプリケーション プロキシは、認証のために AD FS サーバーにリダイレクトします。 Microsoft Store アプリではリダイレクトがサポートされないため、Microsoft Store アプリを使用する場合、Set-WebApplicationProxyConfiguration コマンドレットと OAuthAuthenticationURL パラメーターを使用して、AD FS サーバーの URL を設定する必要があります。

Microsoft Store アプリは Windows PowerShell を使用する場合にのみ公開できます。

  1. クライアントが、Microsoft Store アプリを使用する、公開された Web アプリケーションにアクセスしようとします。

  2. アプリは Web アプリケーション プロキシによって発行された URL に HTTPS 要求を送信します。

  3. Web アプリケーション プロキシは、AD FS 認証サーバーの URL を含む HTTP 401 応答をアプリに返します。 このプロセスは "検出" と呼ばれます。

    注意

    アプリが AD FS 認証サーバーの URL を取得し、既に OAuth トークンとエッジ トークンを含むコンボ トークンがある場合、手順 2 および 3 は、この認証フローではスキップされます。

  4. アプリは AD FS サーバーに HTTPS 要求を送信します。

  5. アプリは Web 認証ブローカーを使用してダイアログ ボックスを生成し、ユーザーは AD FS サーバーで認証するための資格情報をこのダイアログ ボックスで入力します。 Web 認証ブローカーの詳細については、「 Web 認証ブローカー」を参照してください。

  6. 認証が成功した後、AD FS サーバーは OAuth トークンとエッジ トークンを含むコンボ トークンを作成し、そのトークンをアプリに送信します。

  7. アプリは、コンボ トークンを含む HTTPS 要求を、Web アプリケーション プロキシによって発行された URL に送信します。

  8. Web アプリケーション プロキシは、コンボ トークンを 2 つの部分に分割し、エッジ トークンを検証します。

  9. エッジ トークンが有効である場合、Web アプリケーション プロキシは、OAuth トークンのみを使ってバックエンド サーバーに要求を転送します。 ユーザーは、公開された Web アプリケーションへのアクセスが許可されます。

この手順では、OAuth2 用のアプリケーションを公開する方法について説明します。 このタイプのアプリケーションは Windows PowerShell を使用することによってのみ公開できます。 開始する前に、次の作業が完了していることを確認します。

  • AD FS 管理コンソールでアプリケーションの証明書利用者信頼を作成する。

  • AD FS 管理コンソールで、OAuth エンドポイントがプロキシに対応していることを確認し、URL パスをメモする。

  • Web アプリケーション プロキシ サーバーの証明書が、公開するサンプル アプリケーションに適していることを確認する。

OAuth2 アプリを公開するには

  1. Web アプリケーション プロキシ サーバーで、リモート アクセス管理コンソールの [ナビゲーション] ペインに示されている Web アプリケーション プロキシをクリックし、[タスク] ウィンドウで [公開] をクリックします。

  2. 新しいアプリケーションの公開ウィザードの [ようこそ] ページで [次へ] をクリックします。

  3. [事前認証] ページで、[Active Directory フェデレーション サービス (AD FS)] をクリックし、[次へ] をクリックします。

  4. [サポート対象のクライアント] ページで、[OAuth2] を選択し、[次へ] をクリックします。

  5. [証明書利用者] ページの証明書利用者の一覧から、公開するアプリケーションの証明書利用者を選択し、[次へ] をクリックします。

  6. [公開設定] ページで、次の操作を行い、[次へ] をクリックします。

    • [名前] ボックスに、アプリケーションのフレンドリ名を入力します。

      この名前は、リモート アクセス管理コンソールの公開するアプリケーションの一覧でのみ使用されます。

    • [外部 URL] ボックスに、このアプリケーションの外部 URL (https://server1.contoso.com/app1/ など) を入力します。

    • [外部証明書] の一覧で、外部 URL に対応するサブジェクトを持つ証明書を選択します。

      URL に HTTPS を入力しない場合でも、ユーザーがアプリにアクセスできるようにするために、[HTTP から HTTPS へのリダイレクトを有効にする] ボックスをオンにします。

    • [バックエンド サーバー URL] ボックスに、バックエンド サーバーの URL を入力します。 この値は、外部 URL を入力すると自動的に入力されます。バックエンド サーバーの URL が異なる場合のみ、この値を変更してください (https://sp/app1/. など)。

      注意

      Web アプリケーション プロキシでは、URL のホスト名を変換できますが、パス名は変換できません。 そのため、異なるホスト名を入力できますが、同じパス名を入力する必要があります。 たとえば、外部 URL として「https://apps.contoso.com/app1/」を入力し、バックエンド サーバーの URL として「https://app-server/app1/.」を入力できます。 ただし、外部 URL として「https://apps.contoso.com/app1/」を入力し、バックエンド サーバーの URL として「https://apps.contoso.com/internal-app1/」を入力することはできません。

  7. [確認] ページで設定を確認し、[公開] をクリックします。 PowerShell コマンドをコピーして、追加で公開するアプリケーションをセットアップすることができます。

  8. [結果] ページで、アプリケーションが正常に公開されたことを確認し、[閉じる] をクリックします。

各コマンドレットを単一行に入力します。ただし、ここでは、書式上の制約があるために、複数行に改行されて表示される場合があります。

フェデレーション サーバー アドレスが fs.contoso.com で、URL パスが /adfs/oauth2/ である場合に OAuth 認証 URL を設定するには

Set-WebApplicationProxyConfiguration -OAuthAuthenticationURL 'https://fs.contoso.com/adfs/oauth2/'

アプリケーションを公開するには

Add-WebApplicationProxyApplication
    -BackendServerURL 'https://storeapp.contoso.com/'
    -ExternalCertificateThumbprint '1a2b3c4d5e6f1a2b3c4d5e6f1a2b3c4d5e6f1a2b'
    -ExternalURL 'https://storeapp.contoso.com/'
    -Name 'Microsoft Store app Server'
    -ExternalPreAuthentication ADFS
    -ADFSRelyingPartyName 'Store_app_Relying_Party'
    -UseOAuthAuthentication