次の方法で共有

AD FS のクレームベース認証を Outlook Web App および EAC で使用する

  • [アーティクル]

適用対象: Exchange Server 2013 SP1

概要:

Exchange 2013 Service Pack 1 (SP1) のオンプレミス展開では、Active Directory フェデレーション サービス (AD FS) をインストールして構成すると、AD FS クレームベース認証を使用して Outlook Web App と EAC に接続できるようになります。 また Exchange 2013 SP1 を使用して AD FS とクレームベース認証を統合することができます。 クレームベース認証を、次のような従来の認証方式を置き換えるものとして使用できます。

  • Windows 認証
  • フォーム認証
  • ダイジェスト認証
  • 基本認証
  • Active Directory クライアント証明書の認証

認証は、ユーザーの識別情報を確認するプロセスです。 認証は、ユーザーが主張しているとおりの人物であることを確認します。 クレームベース ID は、認証のためのもう 1 つの方式です。 要求ベースの認証では、認証を一元化することでアカウントの管理を容易にするために、アプリケーション (この場合は Outlook Web App と EA) からの認証の管理が削除されます。 Outlook Web App および EAC は、ユーザーの認証、ユーザー アカウントおよびパスワードの保管、ユーザー ID の詳細の検索、他の ID システムとの統合に関与しません。 認証を一元化すると、将来、認証の方式をアップグレードする作業が容易になります。

注:

OWA for Devices は、AD FS クレームベース認証をサポートしていません。

使用できる AD FS のバージョンはいくつかあります。次の表にまとめたとおりです。

Windows Server のバージョン インストール AD FS のバージョン
Windows Server 2008 R2 Windows のアドオン コンポーネントである AD FS 2.0 を ダウンロードしてインストールします。 AD FS 2.0
Windows Server 2012 組み込み AD FS サーバーの役割をインストールします。 AD FS 2.1
Windows Server 2012 R2 組み込み AD FS サーバーの役割をインストールします。 AD FS 3.0

これから実行する作業は、AD FS 役割サービスを組み込んだ Windows Server 2012 R2 に基づくものです。

必要な手順の概要:

ステップ 1: AD FS の証明書要件の確認

ステップ 2: Active Directory フェデレーション サービス (AD FS) のインストールと構成

ステップ 3: Outlook Web App と EAC に対する証明書利用者信頼とカスタム要求規則を作成する

ステップ 4: Web アプリケーション プロキシの役割サービスをインストールする (省略可能)

ステップ 5: Web アプリケーション プロキシの役割サービスを構成する (省略可能)

ステップ 6: Web アプリケーション プロキシを使用して Outlook Web App と EAC を発行する (省略可能)

ステップ 7: AD FS 認証を使用するように Exchange 2013 を構成する

ステップ 8: OWA と ECP の仮想ディレクトリ上で AD FS 認証を有効にする

ステップ 9: インターネット インフォメーション サービス (IIS) を再起動またはリサイクルする

ステップ 10: Outlook Web App と EAC の AD FS 要求をテストする

Additional information you might want to know

始める前に把握しておくべき情報

  • 少なくとも、Windows Server 2012 R2 サーバーを個別にインストールする必要があります。1 つは、Active Directory Domain Services (AD DS)、Exchange 2013 サーバー、Web アプリケーション プロキシ サーバー、およびActive Directory フェデレーション サービス (AD FS) (AD FS) サーバー。 すべての更新プログラムがインストールされていることを確認します。

  • 組織内の適切な数の Windows Server 2012 R2 サーバーに AD DS をインストールします。 サーバー マネージャー>Dashboard で通知を使用して、このサーバーをドメイン コントローラーに昇格することもできます。

  • 組織に適切な数のクライアント アクセス サーバーおよびメールボックス サーバーをインストールします。 組織内のすべての Exchange 2013 サーバーにすべての更新 (SP1 を含む) をインストールしたことを確認します。 SP1 をダウンロードするには、「Updates for Exchange 2013」を参照してください。

  • Web アプリケーション プロキシをサーバーに展開するために、ローカル管理者のアクセス許可が必要です。 Web アプリケーション プロキシを展開する前に、Windows Server 2012 R2 を実行しているサーバーに AD FS を展開しておく必要があります。

  • Windows Server 2012 R2 上に AD FS の役割をインストールして構成し、証明書利用者信頼と要求規則を作成します。 これを実行するには、Domain Admins、Enterprise Admins、またはローカルの Administrators グループのメンバーであるユーザー アカウントでログオンする必要があります。

  • 「機能のアクセス許可」を参照して、Exchange 2013 に必要なアクセス許可を判別します。

  • Outlook Web App を管理するためのアクセス許可を割り当てられている必要があります。 必要なアクセス許可については、「クライアントおよびモバイル デバイスのアクセス許可」トピックの「Outlook Web App のアクセス許可」を参照してください。

  • EAC を管理するためのアクセス許可を割り当てられている必要があります。 必要なアクセス許可を確認するには、Exchange とシェルのインフラストラクチャのアクセス許可 に関するトピックの「Exchange 管理センターの接続」エントリを参照してください。

  • シェルだけを使用していくつかの手順を実行できる場合があります。 社内 Exchange 組織でシェルを開く方法について学習するには、「Open the Shell」を参照してください。

  • このトピックの手順で使用可能なキーボード ショートカットについては、「Exchange 管理センターのキーボード ショートカット」を参照してください。

ヒント

問題がある場合は、 Exchange のフォーラムで質問してください。 Exchange Serverのフォーラムにアクセスしてください。

Step 1 - Review the certificate requirements for AD FS

証明書は、Exchange 2013 SP1 サーバー、Outlook Web App などの Web クライアント、EAC、Windows Server 2012 R2 サーバー (Active Directory フェデレーション サービス (AD FS) サーバーや Web アプリケーション プロキシ サーバーを含む) との間の通信をセキュリティで保護する面で重要な役割を果たします。 証明書の要件は、AD FS サーバー、AD FS プロキシ サーバー、または Web アプリケーション プロキシ サーバーのうちどれを設定しているかに応じて異なります。 AD FS サービスで使用される証明書 (SSL 証明書とトークン署名証明書を含む) は、すべての Exchange サーバー、AD FS サーバー、および Web アプリケーション プロキシ サーバー上の信頼されたルート証明機関ストアにインポートする必要があります。 インポートされた証明書の拇印は、Set-OrganizationConfig コマンドレットを使用するときに Exchange 2013 SP1 サーバーでも使用されます。

どのような AD FS 設計でも、インターネットおよび AD FS サーバー上のユーザー間の通信をセキュリティで保護するためにさまざまな証明書を使用する必要があります。 AD FS サーバー、Active Directory ドメイン コントローラー、および Exchange 2013 サーバーで通信と認証を実行するには、事前に各フェデレーション サーバーがサービス通信証明書または Secure Socket Layer (SSL) 証明書と、トークン署名証明書を保有している必要があります。 セキュリティと予算の要件に応じて、どの証明書をパブリック CA またはエンタープライズ CA から取得するかを注意深く検討してください。 エンタープライズ ルート CA または下位 CA をインストールして構成する場合は、Active Directory 証明書サービス (AD CS) を使用できます。 AD CS の詳細については、「Active Directory 証明書サービスの概要」を参照してください。

AD FS は証明書が CA から発行されたものであることを必要としませんが、SSL 証明書 (既定でサービス通信証明書としても使用される SSL 証明書) は AD FS クライアントから信頼されている必要があります。 自己署名証明書は使用しないことをお勧めします。 フェデレーション サーバーは、Web クライアントおよびフェデレーション サーバー プロキシとの SSL 通信について SSL 証明書を使用して Web サービス トラフィックをセキュリティで保護します。 SSL 証明書はクライアント コンピューターによって信頼されている必要があるため、信頼された CA によって署名された証明書を使用することをお勧めします。 選択するすべての証明書は、対応する秘密キーを持っている必要があります。 CA (エンタープライズまたはパブリック) から証明書を受け取ったら、必ずすべての証明書をすべてのサーバーの信頼されたルート証明機関ストアにインポートしてください。 [証明書] MMC スナップインを使用して証明書をストアにインポートしたり、Active Directory 証明書サービスを使用して証明書を配布したりできます。 重要な点として、インポートした証明書の有効期限が切れている場合は、別の有効な証明書を手動でインポートする必要があります。

重要

自己署名したトークン署名証明書を AD FS から使用する場合は、この証明書をすべての Exchange 2013 サーバー上の信頼されたルート証明機関ストアにインポートする必要があります。 自己署名したトークン署名証明書を使用せずに Web アプリケーション プロキシを展開した場合は、Web アプリケーション プロキシ構成およびすべての AD FS 証明書利用者信頼に含まれる公開キーを更新する必要があります。

Exchange 2013 SP1、AD FS、および Web アプリケーション プロキシを設定するときには、証明書について以下の推奨事項に従ってください。

  • メールボックス サーバー: メールボックス サーバーで使用される証明書は、Exchange 2013 のインストール時に作成される自己署名証明書です。 Exchange 2013 メールボックス サーバーに接続するすべてのクライアントは Exchange 2013 クライアント アクセス サーバーを経由するため、管理する必要のある証明書はクライアント アクセス サーバー上にあるものだけです。

  • クライアント アクセス サーバー: サービス通信に使用される SSL 証明書が必要です。 既存の SSL 証明書に、証明書利用者信頼エンドポイントを設定するために使用する FQDN が既に組み込まれている場合は、追加の証明書は不要です。

  • AD FS: AD FS では、次の 2 種類の証明書が必要です。

    • サービス通信に使用する SSL 証明書

      • サブジェクト名: adfs.contoso.com (AD FS 展開名)
      • サブジェクトの別名 (SAN):なし

    • トークン署名証明書

      • サブジェクト名: tokensigning.contoso.com
      • サブジェクトの別名 (SAN):なし

    注:

    AD FS 上のトークン署名証明書を置き換える場合は、新しいトークン署名証明書を使用するように既存のすべての証明書利用者信頼を更新する必要があります。

  • Web アプリケーション プロキシ

    • サービス通信に使用する SSL 証明書

      • サブジェクト名: owa.contoso.com
      • サブジェクトの別名 (SAN):なし

      注:

      Web アプリケーション プロキシの外部 URL が内部 URL と同じである場合は、Exchange の SSL 証明書をここで再利用できます。

      • AD FS プロキシ SSL 証明書

        • サブジェクト名: adfs.contoso.com (AD FS 展開名)
        • サブジェクトの別名 (SAN):なし

      • トークン署名証明書: これは、以下のステップの中で AD FS から自動的に上書きコピーされます。 この証明書を使用する場合は、それが組織内の Exchange 2013 サーバーによって信頼されている必要があります。

証明書の詳細については、「 AD FS の要件」 の「証明書の要件」セクションを参照してください。

注:

AD FS 用の SSL 証明書がある場合でも、Outlook Web App および EAC には SSL 暗号証明書が必要です。 SSL 証明書は、OWA および ECP の仮想ディレクトリで使用されます。

Step 2 - Install and configure Active Directory Federation Services (AD FS)

Windows Server 2012 R2 の AD FS は、簡素化され、セキュリティで保護された ID フェデレーションと Web シングル サインオン (SSO) 機能を提供します。 AD FS には、ブラウザー ベースの Web SSO、多要素認証、およびクレームベース認証を可能にするフェデレーション サービスが含まれています。 AD FS では、クレームベース認証およびアクセス承認のメカニズムを使用してアプリケーションのセキュリティが維持されるため、システムおよびアプリケーションへのアクセスが簡素化されます。

AD FS を Windows Server 2012 R2 上にインストールするには、以下の手順を実行します。

  1. [スタート] 画面で [サーバー マネージャー] を開くか、デスクトップのタスクバーで [サーバー マネージャー] を開きます。 [管理] メニューの [役割と機能の追加] をクリックします。

  2. [始める前に] ページで、 [次へ] をクリックします。

  3. [インストールの種類の選択] ページで、 [役割ベースまたは機能ベースのインストール] をクリックしてから、 [次へ] をクリックします。

  4. [対象サーバーの選択] ページで、 [サーバー プールからサーバーを選択] をクリックし、ローカル コンピューターが選択されていることを確認してから、 [次へ] をクリックします。

  5. [サーバーの役割の選択] ページで、 [Active Directory フェデレーション サービス] をクリックしてから、 [次へ] をクリックします。

  6. [機能の選択] ページで、 [次へ] をクリックします。 必要な前提条件または機能が既に自動的に選択されています。 それ以外の機能を選択する必要はありません。

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

  8. [インストール オプションの確認] ページで、 [必要に応じて対象サーバーを自動的に再起動する] を選択してから、 [インストール] をクリックします。

    注:

    インストール処理の実行中、ウィザードは閉じないでください。

必要な AD FS サーバーをインストールし、必要な証明書を生成した後、AD FS を構成し、AD FS が正しく動作していることをテストする必要があります。 このチェックリストを使用して、AD FS の設定と構成に役立つ場合もあります。 チェックリスト: フェデレーション サーバーの設定です。

Active Directory フェデレーション サービスを構成するには、以下の手順を実行します。

  1. [インストールの進行状況] ページで、 [Active Directory フェデレーション サービス] の下にあるウィンドウから、 [このサーバーにフェデレーション サービスを構成します] をクリックします。 Active Directory フェデレーション サービス構成ウィザードが開きます。

  2. 「ようこそ」 ページで、 [フェデレーション サーバー ファームに最初のフェデレーション サーバーを作成します] をクリックしてから、 [次へ] をクリックします。

  3. [AD DS に接続] ページで、このコンピューターの参加先になる正しい Active Directory ドメインに対してドメイン管理者権限を持つアカウントを指定し、 [次へ] をクリックします。 異なるユーザーを選択する必要がある場合は、 [変更] をクリックします。

  4. [サービスのプロパティの指定] ページで以下の操作を実行してから、 [次へ] をクリックします。

    • 前のステップで AD CS またはパブリック CA から入手した SSL 証明書をインポートします。 この証明書は、必須のサービス認証証明書です。 SSL 証明書のある場所を参照します。 SSL 証明書の作成およびインポートの詳細については、「サーバー証明書」を参照してください。

    • フェデレーション サービスの名前を入力します (たとえば、「 adfs.contoso.com」と入力します)。

    • フェデレーション サービスの表示名を指定するには、組織の名前 ( Contoso、Ltd など) を入力します。

  5. [サービス アカウントの指定] ページで、 [既存のドメイン ユーザー アカウントまたはグループの管理されたサービス アカウントを使用してください] を選択してから、ドメイン コントローラーを作成したときに作成した GMSA アカウント (FsGmsa) を指定します。 アカウントのパスワードを組み込んでから、 [次へ] をクリックします。

    注:

    グローバルに管理されたサービス アカウント (GMSA) は、ドメイン コントローラーを構成するときに作成する必要のあるアカウントです。 GMSA アカウントは、AD FS のインストールおよび構成中に必要です。 このアカウントをまだ作成していない場合は、次の Windows PowerShell コマンドを実行してください。 contoso.com ドメインおよび AD FS サーバー用のアカウントが作成されます。

  6. 次のコマンドを実行します。

    Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)

  7. 次の使用例は、adfs.contoso.com という名前のフェデレーション サービスの FsGmsa という名前の新しい GMSA アカウントを作成します。 フェデレーション サービス名は、クライアントに表示される値です。

    New-ADServiceAccount FsGmsa -DNSHostName adfs.contoso.com -ServicePrincipalNames http/adfs.contoso.com

  8. [構成データベースの指定] ページで、 [Windows Internal Database を使用してサーバーにデータベースを作成します] を選択してから、 [次へ] をクリックします。

  9. [オプションの確認] ページで、選択した構成の内容を確認します。 オプションとして、 [スクリプトの表示] ボタンを使用すると、追加の AD FS のインストールを自動化できます。 [次へ] をクリックします。

  10. [前提条件の確認] ページで、すべての前提条件の確認が正常に完了したことを確認してから、 [構成] をクリックします。

  11. [インストールの進行状況] ページで、すべてが正常にインストールされたことを確認してから、 [閉じる] をクリックします。

  12. [結果] ページで、結果を確認し、構成が正常に完了したことをチェックしてから、 [フェデレーション サービス展開を完了するために必要な次の手順] をクリックします。

次のWindows PowerShellコマンドは、前の手順と同じことを行います。

Import-Module ADFS

Install-AdfsFarm -CertificateThumbprint 0E0C205D252002D535F6D32026B6AB074FB840E7 -FederationServiceDisplayName "Contoso Corporation" -FederationServiceName adfs.contoso.com -GroupServiceAccountIdentifier "contoso\FSgmsa`$"

詳細と構文については、「Install-AdfsFarm」を参照してください。

インストールを確認するには:AD FS サーバーで Web ブラウザーを開き、フェデレーション メタデータの URL (例: https://adfs.contoso.com/federationmetadata/2007-06/federationmetadata.xml) を参照します。

ステップ 3: Outlook Web App と EAC に対する証明書利用者信頼とカスタム要求規則を作成する

Web アプリケーション プロキシを介して発行するすべてのアプリケーションとサービスの場合、AD FS サーバーで証明書利用者信頼を構成する必要があります。 独立した名前空間を使用する複数の Active Directory サイトで展開する場合は、Outlook Web App と EAC の証明書利用者信頼を各名前空間に追加する必要があります。

EAC は、ECP 仮想ディレクトリを使用します。 EAC の設定を表示または構成するには、Get-EcpVirtualDirectory および Set-EcpVirtualDirectory コマンドレットを使用することができます。 EAC にアクセスするには、Web ブラウザーを使用して http://server1.contoso.com/ecp にアクセスします。

注:

以下に示す URL の例に含まれている末尾のスラッシュ / は、意図的なものです。 AD FS 証明書利用者信頼と Exchange Audience URI の両方が必ず 同一であることが重要です。 これは、AD FS 証明書利用者信頼と Exchange Audicence URI の両方の URL の末尾にスラッシュが あるかまたは ないかのどちらかでなければならないことを意味します。 このセクションの例では、"owa" または "ecp" で終わる URL のすべての末尾に / が含まれています ( /owa/ または /ecp/)。

Outlook Web App に対して Windows Server 2012 R2 で AD FS 管理スナップインを使用して証明書利用者信頼を作成するには、以下のようにします。

  1. [サーバー マネージャー] で、 [ツール] をクリックして、 [AD FS 管理] を選択します。

  2. [AD FS スナップイン] の AD FS\信頼関係 の下で、 [証明書利用者信頼] を右クリックしてから、 [証明書利用者信頼の追加] をクリックして [証明書利用者信頼の追加] ウィザードを開きます。

  3. [ようこそ] ページで、 [開始] をクリックします。

  4. [データ ソースの選択] ページで、 [証明書利用者に関するデータを手動で入力します] をクリックしてから、 [次へ] を入力します。

  5. [表示名の指定] ページの [表示名] ボックスに「Outlook Web App」と入力し、[メモ] の下に、この証明書利用者信頼の説明 ([これは信頼https://mail.contoso.com/owa/] など) を入力し、[次へ] をクリックします。

  6. [プロファイルの選択] ページで、 [AD FS プロファイル] をクリックしてから、 [次へ] をクリックします。

  7. [証明書の構成] ページで、 [次へ] をクリックします。

  8. [URL の構成] ページで、 [WS-Federation パッシブ プロトコルのサポートを有効にします] をクリックし、 [証明書利用者の WS-Federation パッシブ プロトコル URL] の下に type https://mail.contoso.com/owa/ と入力してから、 [次へ] をクリックします。

  9. [ID の構成] ページで、この証明書利用者の 1 つ以上の ID を指定し、 [追加] をクリックしてそれらの ID を一覧に追加してから、 [次へ] をクリックします。

  10. [多要素認証を今すぐ構成しますか?] ページで、 [この証明書利用者信頼に対して多要素認証の設定を構成します] を選択します。

  11. [多要素認証の構成] ページで、 [この証明書利用者信頼に対して多要素認証の設定を今は構成しません] を選択してから、 [次へ] をクリックします。

  12. [発行承認規則の選択] ページで、 [すべてのユーザーがこの証明書利用者にアクセスすることを許可します] を選択してから、 [次へ] をクリックします。

  13. [信頼の追加の準備完了] ページで、設定を確認してから、 [次へ] をクリックして証明書利用者信頼の情報を保存します。

  14. [完了] ページで、 [ウィザードを閉じるときにこの証明書利用者の [要求規則の編集] ダイアログを開きます] が選択されていないことを確認してから、 [閉じる] をクリックします。

EAC の証明書利用者信頼を作成するには、次の手順をもう一度実行し、2 つ目の証明書利用者信頼を作成する必要がありますが、表示名のOutlook Web Appを入力するのではなく、「EAC」と入力します。 説明については、「 これは Exchange 管理センターの信頼であり、 証明書利用者WS-Federationパッシブ プロトコル URL 」 https://mail.contoso.com/ecpと入力します。

クレームベースの ID モデルでは、Active Directory フェデレーション サービス (AD FS) のフェデレーション サービスとしての機能は、要求のセットを含むトークンを発行することです。 要求規則は、AD FS がどのクレームを発行するかの決定に影響を与えます。 要求規則およびすべてのサーバー構成データは、AD FS 構成データベースに格納されます。

次の 2 つの要求規則を作成する必要があります。

  • Active Directory ユーザー SID
  • Active Directory UPN

必要な要求規則を追加するには、以下の手順を実行します。

  1. [サーバー マネージャー] で、 [ツール] をクリックしてから、 [AD FS 管理] をクリックします。

  2. コンソール ツリーの AD FS\信頼関係 の下で、 [要求プロバイダー信頼] または [証明書利用者信頼] のどちらかをクリックしてから、Outlook Web App の証明書利用者信頼をクリックします。

  3. [証明書利用者信頼] ウィンドウで、Outlook Web App 信頼を右クリックしてから、 [要求規則の編集] をクリックします。

  4. [要求規則の編集] ウィンドウの [発行変換規則] タブで、 [規則の追加] をクリックして、変換要求規則の追加ウィザードを開始します。

  5. [ルール テンプレートの選択] ページの [要求規則テンプレート] の下にあるリストで [カスタム規則を使用した要求の送信] を選択してから、 [次へ] をクリックします。

  6. [規則の構成] ページの [規則の種類の選択] ステップで、 [要求規則名] の下に要求規則の名前を入力します。 要求規則にわかりやすい名前 ( ActiveDirectoryUserSID など) を使用します。 [カスタム規則] の下に、この規則について次のような要求規則言語の構文を入力します。

    c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"), query = ";objectSID;{0}", param = c.Value);

  7. [規則の構成] ページで、 [完了] をクリックします。

  8. [要求規則の編集] ウィンドウの [発行変換規則] タブで、 [規則の追加] をクリックして、変換要求規則の追加ウィザードを開始します。

  9. [ルール テンプレートの選択] ページの [要求規則テンプレート] の下にあるリストで [カスタム規則を使用した要求の送信] を選択してから、 [次へ] をクリックします。

  10. [規則の構成] ページの [規則の種類の選択] ステップで、 [要求規則名] の下に要求規則の名前を入力します。 要求規則のわかりやすい名前 ( ActiveDirectoryUPN など) を使用します。 [カスタム規則] の下に、この規則について次のような要求規則言語の構文を入力します。

    c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"), query = ";userPrincipalName;{0}", param = c.Value);

  11. [終了] をクリックします。

  12. [要求規則の編集] ウィンドウで、 [適用] をクリックしてから、 [OK] をクリックします。

  13. EAC の証明書利用者信頼の場合は、この手順のステップ 3-12 を繰り返します。

または、Windows PowerShell を使用して、証明書利用者信頼と要求規則を作成できます。

  1. IssuanceAuthorizationRules.txt および IssuanceTransformRules.txt の 2 つの .txt ファイルを作成します。

  2. それらの内容を 2 つの変数にインポートします。

  3. 次の 2 つのコマンドレットを実行して、証明書利用者信頼を作成します。 これらを実行すると、この例では要求規則の構成も行われます。

IssuanceAuthorizationRules.txt の内容:

@RuleTemplate = "AllowAllAuthzRule" => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

IssuanceTransformRules.txt の内容:

@RuleName = "ActiveDirectoryUserSID" c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"), query = ";objectSID;{0}", param = c.Value);

@RuleName = "ActiveDirectoryUPN" c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"), query = ";userPrincipalName;{0}", param = c.Value);

以下のコマンドを実行します。

[string]$IssuanceAuthorizationRules=Get-Content -Path C:\IssuanceAuthorizationRules.txt

[string]$IssuanceTransformRules=Get-Content -Path c:\IssuanceTransformRules.txt

Add-ADFSRelyingPartyTrust -Name "Outlook Web App" -Enabled $true -Notes "This is a trust for https://mail.contoso.com/owa/" -WSFedEndpoint https://mail.contoso.com/owa/ -Identifier https://mail.contoso.com/owa/ -IssuanceTransformRules $IssuanceTransformRules -IssuanceAuthorizationRules $IssuanceAuthorizationRules

Add-ADFSRelyingPartyTrust -Name "Exchange admin center (EAC)" -Enabled $true -Notes "This is a trust for https://mail.contoso.com/ecp/" -WSFedEndpoint https://mail.contoso.com/ecp/ -Identifier https://mail.contoso.com/ecp/ -IssuanceTransformRules $IssuanceTransformRules -IssuanceAuthorizationRules $IssuanceAuthorizationRules

ステップ 4: Web アプリケーション プロキシの役割サービスをインストールする (省略可能)

注:

手順 4、手順 5、および手順 6 は、ユーザーが Web アプリケーション プロキシを使用して Exchange OWA と ECP を発行し、Web アプリケーション プロキシ AD FS 認証を実行するユーザーを対象とします。 ただし、Web アプリケーション プロキシを使用して Exchange を発行する必要がないため、Web アプリケーション プロキシを使用せず、Exchange で AD FS 認証自体を実行する場合は、手順 7 に進むことができます。

Web アプリケーション プロキシは、Windows Server 2012 R2 の新しいリモート アクセス役割サービスです。 Web アプリケーション プロキシは、企業ネットワークの内側にある Web アプリケーションに企業ネットワークの外側から多くのデバイスでユーザーがアクセスできるようにするためのリバース プロキシの機能を Web アプリケーションに提供します。 Web アプリケーション プロキシは、Active Directory フェデレーション サービス (AD FS) を使用して Web アプリケーションへのアクセスを事前に認証し、さらに AD FS プロキシとしても機能します。 Web アプリケーション プロキシは必須ではありませんが、AD FS を外部クライアントからアクセス可能にする場合に推奨されます。 ただし、Outlook Web App のオフライン アクセスは、Web アプリケーション プロキシを介した AD FS 認証の使用時にはサポートされません。 Web アプリケーション プロキシとの統合に関する詳細は、「Web アプリケーション プロキシを使用してアプリケーションを公開することを計画する」を参照してください。

警告

AD FS がインストールされているのと同じサーバー上に Web アプリケーション プロキシをインストールすることはできません。

Web アプリケーション プロキシを展開するには、Web アプリケーション プロキシ サーバーとして機能させる予定のサーバー上に、リモート アクセス サーバーの役割を Web アプリケーション プロキシの役割サービスと一緒にインストールする必要があります。 Web アプリケーション プロキシの役割サービスをインストールするには、以下の手順を実行します。

  1. Web アプリケーション プロキシ サーバーの [サーバー マネージャー] で、 [管理] をクリックしてから、 [役割と機能の追加] をクリックします。

  2. 役割と機能の追加ウィザードで [次へ] を 3 回クリックして、 [サーバーの役割] ページに進みます。

  3. [サーバーの役割] ページの一覧から [リモート アクセス] を選択し、 [次へ] をクリックします。

  4. [機能] ページで [次へ] をクリックします。

  5. [リモート アクセス] ページで情報を確認してから、 [次へ] をクリックします。

  6. [役割サービス] ページで [Web アプリケーション プロキシ] を選択します。 次に、 [役割と機能の追加ウィザード] ウィンドウで [機能の追加] をクリックして、 [次へ] をクリックします。

  7. [確認] ウィンドウで [インストール] をクリックします。 また、 [必要に応じて対象サーバーを自動的に再起動する] を選択することもできます。

  8. [インストールの進行状況] ダイアログ ボックスで、インストールが成功したことを確認し、 [閉じる] をクリックします。

次の Windows PowerShell コマンドレットは、上記の手順と同じ操作を実行します。

Install-WindowsFeature Web-Application-Proxy -IncludeManagementTools

ステップ 5: Web アプリケーション プロキシの役割サービスを構成する (省略可能)

Web アプリケーション プロキシは、AD FS サーバーに接続するように構成する必要があります。 Web アプリケーション プロキシ サーバーとして展開するすべてのサーバーに対して、この手順を繰り返します。

Web アプリケーションの役割サービスを構成するには、以下の手順を実行します。

  1. Web アプリケーション プロキシ サーバーの [サーバー マネージャー] で、 [ツール] をクリックし、 [リモート アクセス管理] をクリックします。

  2. [構成] ウィンドウで [Web アプリケーション プロキシ] をクリックします。

  3. [リモート アクセス管理] コンソールの中央のウィンドウで、 [Web アプリケーション プロキシの構成ウィザードを実行する] をクリックします。

  4. Web アプリケーション プロキシの構成ウィザードの [ようこそ] ダイアログ ボックスで、 [次へ] をクリックします。

  5. [フェデレーション サーバー] ページで、次の操作を行ってから、 [次へ] をクリックします。

    • [ フェデレーション サービス名 ] ボックスに、AD FS サーバーの完全修飾ドメイン名 (FQDN) を入力 します (たとえば、adfs.contoso.com)。

    • [ユーザー名] および [パスワード] ボックスに、AD FS サーバーのローカル管理者アカウントの資格情報を入力します。

  6. [AD FS プロキシ証明書] ダイアログ ボックスで、Web アプリケーション プロキシ サーバーに現在インストールされている証明書の一覧から、Web アプリケーション プロキシが AD FS プロキシ機能のために使用する証明書を選択して、 [次へ] を入力します。 ここで選択する証明書は、サブジェクトがフェデレーション サービス名 ( たとえば、adfs.contoso.com) である必要があります。

  7. [確認] ダイアログ ボックスで、設定の内容を確認します。 必要であれば、Windows PowerShell コマンドレットをコピーして、追加のインストールを自動化することができます。 [構成] をクリックします。

  8. [結果] ダイアログ ボックスで、構成が成功したことを確認してから、 [閉じる] をクリックします。

次の Windows PowerShell コマンドレットは、上記の手順と同じ操作を実行します。

Install-WebApplicationProxy -CertificateThumprint 1a2b3c4d5e6f1a2b3c4d5e6f1a2b3c4d5e6f1a2b -FederationServiceName adfs.contoso.com

ステップ 6: Web アプリケーション プロキシを使用して Outlook Web App と EAC を発行する (省略可能)

手順 3 では、Outlook Web Appと EAC のパーティ信頼を中継する要求を作成し、これらの両方のアプリケーションを発行する必要があります。 ただし、これを行う前に、証明書利用者の信頼が作成されたことを確認し、Outlook Web Appと EAC に適した証明書が Web アプリケーション プロキシ サーバーにあることを確認します。 Web アプリケーション プロキシによって発行する必要があるすべての AD FS エンドポイントについては、AD FS 管理コンソールで、エンドポイントを [プロキシが有効] に設定する必要があります。

Web アプリケーション プロキシを使用して Outlook Web App 発行するには、以下の手順を実行してください。 EAC についても、以下の手順を繰り返します。 ただし、EAC を発行するときには、名前、外部 URL、外部証明書、およびバックエンド URL を変更する必要があります。

Web アプリケーション プロキシを使用して Outlook Web App および EAC を発行するには、以下の手順を実行します。

  1. Web アプリケーション プロキシ サーバーの [リモート アクセス管理] コンソールで、 [ナビゲーション] ウィンドウの [Web アプリケーション プロキシ] をクリックしてから、 [タスク] ウィンドウの [発行] をクリックします。

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

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

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

  5. [発行の設定] ページで、次の操作を行ってから、 [次へ] をクリックします。

    1. [名前] ボックスに、このアプリケーションのフレンドリ名を入力します。 この名前は、[リモート アクセス管理コンソール] の発行されたアプリケーションの一覧でのみ使用されます。 OWA や EAC という名前を使用できます。

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

    3. [外部証明書] リストで、サブジェクト名が外部 URL のホスト名と一致する証明書を選択します。

    4. [ バックエンド サーバーの URL ] ボックスに、バックエンド サーバーの URL を入力します。 この値は外部 URL を入力すると自動的に入力されるため、バックエンド サーバーの URL が異なる場合にのみ変更する必要があることに注意してください (たとえば、 https://mail.contoso.com/owa/ Outlook Web Appと https://mail.contoso.com/ecp/ EAC の場合)。

    注:

    Web Application Proxy can translate host names in URLs but cannot translate paths. Therefore, you can enter different host names, but you must enter the same path. たとえば、 の https://external.contoso.com/app1/ 外部 URL と のバックエンド サーバー URL を https://mail.contoso.com/app1/入力できます。 ただし、 の https://external.contoso.com/app1/ 外部 URL と のバックエンド サーバー URL を https://mail.contoso.com/internal-app1/入力することはできません。

  6. [確認] ページで設定内容を確認し、 [発行] をクリックします。 Windows PowerShell コマンドをコピーしておけば、発行された追加のアプリケーションをセットアップできます。

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

次の Windows PowerShell コマンドレットは、Outlook Web App に対する上記の手順と同じ作業を実行します。

Add-WebApplicationProxyApplication -BackendServerUrl 'https://mail.contoso.com/owa/' -ExternalCertificateThumbprint 'E9D5F6CDEA243E6E62090B96EC6DE873AF821983' -ExternalUrl 'https://external.contoso.com/owa/' -Name 'OWA' -ExternalPreAuthentication ADFS -ADFSRelyingPartyName 'Outlook Web App'

次の Windows PowerShell コマンドレットは、EAC に対する上記の手順と同じ作業を実行します。

Add-WebApplicationProxyApplication -BackendServerUrl 'https://mail.contoso.com/ecp/' -ExternalCertificateThumbprint 'E9D5F6CDEA243E6E62090B96EC6DE873AF821983' -ExternalUrl 'https://external.contoso.com/ecp/' -Name 'EAC' -ExternalPreAuthentication ADFS -ADFSRelyingPartyName 'Exchange admin center'

これらの手順を完了すると、Web アプリケーション プロキシは Outlook Web App クライアントと EAC クライアントの AD FS 認証を実行し、これらに代わって Exchange への接続をプロキシ処理します。 AD FS 認証用に Exchange 自体を構成する必要はないため、ステップ 10 に進んで構成をテストします。

ステップ 7: AD FS 認証を使用するように Exchange 2013 を構成する

Exchange 2013 でOutlook Web Appと EAC を使用して要求ベースの認証に使用するように AD FS を構成する場合は、Exchange 組織の AD FS を有効にする必要があります。 Set-OrganizationConfig コマンドレットを使用して組織に対して AD FS の設定を構成する必要があります。

  • AD FS の発行者を https://adfs.contoso.com/adfs/ls/ に設定します。

  • AD FS の URI を https://mail.contoso.com/owa/ および https://mail.contoso.com/ecp/ に設定します。

  • AD FS サーバーでWindows PowerShellを使用し、「 」と入力して、AD FS トークン署名証明書の拇印をGet-ADFSCertificate -CertificateType "Token-signing"見つけます。 次に、見つかったトークン署名証明書の拇印を割り当てます。 AD FS トークン署名証明書の有効期限が切れている場合は、 Set-OrganizationConfig コマンドレットを使用して新しい AD FS トークン署名証明書から拇印を更新する必要があります。

Exchange 管理シェルで次のコマンドを実行します。

$uris = @("https://mail.contoso.com/owa/","https://mail.contoso.com/ecp/")
Set-OrganizationConfig -AdfsIssuer "https://adfs.contoso.com/adfs/ls/" -AdfsAudienceUris $uris -AdfsSignCertificateThumbprint "88970C64278A15D642934DC2961D9CCA5E28DA6B"

注:

これらのシナリオでは 、-AdfsEncryptCertificateThumbprint パラメーターはサポートされていません。

詳細と構文については、「Set-OrganizationConfig」および「Get-ADFSCertificate」を参照してください。

ステップ 8: OWA と ECP の仮想ディレクトリ上で AD FS 認証を有効にする

OWA および ECP の仮想ディレクトリについては、唯一の認証方式として AD FS 認証を有効にし、他のすべての形式の認証は無効にしてください。

警告

OWA 仮想ディレクトリを構成する前に、ECP 仮想ディレクトリを構成する必要があります。

Exchange 管理シェルを使用して、ECP 仮想ディレクトリを構成します。 [シェル] ウィンドウで、次のコマンドを実行します。

Get-EcpVirtualDirectory | Set-EcpVirtualDirectory -AdfsAuthentication $true -BasicAuthentication $false -DigestAuthentication $false -FormsAuthentication $false -WindowsAuthentication $false

Exchange 管理シェルを使用して、OWA 仮想ディレクトリを構成します。 [シェル] ウィンドウで、次のコマンドを実行します。

Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -AdfsAuthentication $true -BasicAuthentication $false -DigestAuthentication $false -FormsAuthentication $false -WindowsAuthentication $false -OAuthAuthentication $false

注:

上記の Exchange 管理シェル コマンドは、組織内のすべてのクライアント アクセス サーバーに OWA および ECP 仮想ディレクトリを構成します。 これらの設定をすべてのクライアント アクセス サーバーに適用しない場合は、 -Identity パラメーターを使用し、クライアント アクセス サーバーを指定します。 よくある状況は、組織内でインターネットに直接接続しているクライアント アクセス サーバーに対してのみこれらの設定を適用する場合です。

詳細と構文については、「Get-OwaVirtualDirectory」と「Set-OwaVirtualDirectory」、または「Get-EcpVirtualDirectory」と「Set-EcpVirtualDirectory」を参照してください。

ステップ 9: インターネット インフォメーション サービス (IIS) を再起動またはリサイクルする

Exchange 仮想ディレクトリに変更を加えることを含め、必要なすべてのステップを完了した後、インターネット インフォメーション サービスを再起動する必要があります。 これを行うには、以下のいずれかの方法を使用します。

  • Windows PowerShell を使用:

    Restart-Service W3SVC,WAS -force

  • コマンド ラインを使用する: [ スタート] をクリックし、[ 実行] をクリックし、「」と入力 IISReset /noforceして、[OK] をクリック します。

  • インターネット インフォメーション サーバー (IIS) マネージャーの使用: サーバー マネージャー>IIS で、[ツール] をクリックし、[インターネット インフォメーション サービス (IIS) マネージャー] をクリックします。 [インターネット インフォメーション サービス (IIS) マネージャー] ウィンドウで、[サーバーの管理] の下にあるアクション ウィンドウから [再起動] をクリックします。

ステップ 10: Outlook Web App と EAC の AD FS 要求をテストする

Outlook Web App の AD FS 要求をテストするには、次の手順を実行します。

  • Web ブラウザーで、Outlook Web App にサインインします (例: https://mail.contoso.com/owa)。

  • ブラウザー ウィンドウで証明書エラーが表示されても、そのまま Outlook Web App の Web サイトに進みます。 ADFS のサインイン ページまたは資格情報の入力を要求する ADFS のプロンプトにリダイレクトされます。

  • ユーザー名 (domain\user) とパスワードを入力し、[ サインイン] をクリックします。

Outlook Web App がウィンドウにロードされます。

EAC に対して AD FS 要求をテストするには、以下の手順を実行します。

  1. Web ブラウザーで、https://mail.contoso.com/ecp にアクセスします。

  2. ブラウザー ウィンドウで証明書エラーが表示されても、そのまま ECP の Web サイトに進みます。 ADFS のサインイン ページまたは資格情報の入力を要求する ADFS のプロンプトにリダイレクトされます。

  3. ユーザー名 (domain\user) とパスワードを入力し、[ サインイン] をクリックします。

  4. EAC がウィンドウにロードされるはずです。

把握しておくとよい補足情報

多要素認証

Exchange 2013 SP1 の社内展開の場合、要求を使用して Active Directory フェデレーション サービス (AD FS) 2.0 を展開して構成すると、Exchange 2013 SP1 内の Outlook Web App および EAC が証明書ベース認証、認証トークンまたはセキュリティー トークン、および指紋認証などの多要素認証方式をサポートできるようになります。 2 要素認証は、しばしば他の形式の認証と混同されます。 多要素認証では、3 つの認証要素のうち 2 つを使用する必要があります。 その要素は次のとおりです。

  • ユーザーだけが知っているもの (たとえば、パスワード、PIN、またはパターン)

  • ユーザーだけが持っているもの (たとえば、ATM カード、セキュリティ トークン、スマート カード、または携帯電話)

  • ユーザーだけがもつ状態 (たとえば、指紋などのバイオメトリクス特性)

Windows Server 2012 R2 での多要素認証の詳細については、「機密性の高いアプリケーションの追加の多要素認証に伴うリスクを管理します。」および「チュートリアル ガイド: 機密性の高いアプリケーションの追加の多要素認証に伴うリスクを管理します。」を参照してください。

Windows Server 2012 R2 AD FS 役割サービスでは、フェデレーション サービスがセキュリティ トークン サービスとして機能し、要求で使用されるセキュリティ トークンを提供するため、多要素認証をサポートできます。 フェデレーション サービスは、提示された資格情報に基づいてトークンを発行します。 アカウント ストアがユーザーの資格情報を検証した後、信頼ポリシーの規則に従ってそのユーザーに対する要求が生成され、それがセキュリティ トークンに追加されてクライアントに発行されます。 要求の詳細については、「要求とは」を参照してください。

他のバージョンの Exchange との共存

It's possible to use AD FS authentication for Outlook Web App and EAC when you have more than one version of Exchange deployed in your organization. This scenario is only supported for Exchange 2010 and Exchange 2013 deployments, and only if all clients are connecting through the Exchange 2013 servers and those Exchange 2013 servers have been configured for AD FS authentication.

Exchange 2010 サーバー上にメールボックスを持つユーザーは、AD FS 認証用に構成された Exchange 2013 サーバーを介してメールボックスにアクセスできます。 Exchange 2013 サーバーへの最初のクライアント接続では、AD FS 認証が使用されます。 ただし、Exchange 2010 サーバーへのプロキシ接続では Kerberos が使用されます。 AD FS を直接認証するよう Exchange Server 2010 を構成する方法はサポートされていません。