Microsoft 365 から SharePoint Server への接続を計画する

適用対象:yes-img-13 2013yes-img-162016 yes-img-192019 yes-img-seSubscription Edition yes-img-sopSharePoint in Microsoft 365

この記事は、リバース プロキシ デバイスを介して SharePoint Server への企業向けの Microsoft 365 からの受信接続を構成する計画と準備をするのに役立ちます。 これは次のハイブリッド環境に必要です。

  • 受信ハイブリッド検索 (Microsoft 365 の SharePoint Server からの検索結果を表示)

  • ハイブリッド Business Connectivity Services

この記事では、前提条件などの知っておくべき情報、および構成プロセスを開始する前に必要な情報を収集するためのワークシートを提供します。

このトピックは、以下を行う上で役立ちます。

  • 受信接続の前提条件と要件について

  • Web アプリケーション アーキテクチャを計画する

  • SSL 証明書を計画する

  • 重要な決定事項と情報を記録する

ワークシートとビルド ログ情報を収集し、記録する

ワークシート。 計画プロセス中に、情報およびファイルを収集する必要があります。 計画および展開に関する情報を追跡して参照資料を作成し、展開チームの他のメンバーと共有するには、「 SharePoint ハイブリッド ワークシート」を使用することが重要です。 構成プロセスを開始する前に、このワークシートを使用して情報を整理することの重要性については、いくら強調してもし過ぎることはありません。

ビルド ログの作成。 実装が複雑なプロジェクトのいずれにおいても、設計上の決定ごとの詳細記録、サーバー構成、手順、コマンド出力、エラーは、トラブルシューティング、サポート、認識の非常に重要な参照事項です。 展開プロセスを完全に文書化することを強くお勧めします。

注意

セキュリティ上の理由から、Microsoft 365 ドキュメント ライブラリのセキュリティで保護されたファイル共有や SharePoint などのセキュリティ強化された場所にワークシートとビルド ログを格納し、展開プロセスに関与し、この情報を知る必要がある管理者にのみアクセス許可を付与します。

URL およびホスト名の情報を収集し、記録する

このセクションでは、環境内の URL とホスト名に関する情報を記録します。 展開プロセス中にこの情報を使用します。

  • 会社のパブリック DNS ドメイン名 (adventureworks.com など) を記録します。

  • SharePoint のハイブリッドを使用するリバース プロキシ デバイスの一般向けのエンドポイントの URL を記録します。 これは外部 URL です。 このエンドポイントがまだ存在しない場合はこの URL を決定する必要があります。

  • リバース プロキシ デバイスの外部エンドポイントの IP アドレスを記録します。

  • A レコード ( ホスト レコードとしても知られる) が、リバース プロキシ デバイスのインターネット接続エンドポイントの IP アドレスに対して外部 URL をマッピングするパブリック ドメイン用の パブリック DNS の前方検索ゾーンに存在することを確認します。 この A レコードがまだない場合は、ここで作成してください。

  • A レコードが SharePoint Server ファームのホスト名を IP アドレスにマッピングする イントラネット DNS の前方検索ゾーンに存在することを確認します。 この A レコードがまだない場合は、ここで作成してください。

    重要

    展開プロセス中に Web アプリケーションにアクセスするための内部 URL を構成する場合、必ずイントラネット DNS の前方検索ゾーンにある URL にも A レコードを作成し、それをワークシートに記録してください。

   
編集アイコン 次の情報を SharePoint ハイブリッド ワークシートの表 3 に記録します。
パブリック インターネット ドメイン名」行にある一般向けの企業 DNS ドメインのドメイン名。
外部 URL」行のリバース プロキシ デバイスにある一般向けのエンドポイントの URL。
外部エンドポイントの IP アドレス」行にあるリバース プロキシ デバイスの外部エンドポイントの IP アドレス。

Web アプリケーション アーキテクチャを計画する

このセクションでは、ハイブリッド環境で使用する SharePoint Server Web アプリケーションのアーキテクチャを計画します。

受信接続には、オンプレミスの SharePoint Server ファームと Microsoft 365 の SharePoint 間のセキュリティで保護された通信チャネルが必要です。 データは、Microsoft 365 の SharePoint のサイト コレクションと、この通信チャネルを介してオンプレミスの Web アプリケーションの間で交換されます。

Microsoft 365 の SharePoint は、SharePoint ハイブリッド用に構成されたオンプレミスの SharePoint Server ファーム内の特定の Web アプリケーションに要求を中継するリバース プロキシ サーバーに要求を送信します。 これを プライマリ Web アプリケーションといいます。

ヒント

構成を計画するハイブリッド ソリューションの数に関係なく、通常は 1 つのプライマリ Web アプリケーションのみを使用します。 ハイブリッド ソリューションを追加するごとに追加のプライマリ Web アプリケーションを作成する必要はありません。

プライマリ Web アプリケーションとプライマリ Web アプリケーション内の 1 つのサイト コレクションの両方が、Microsoft 365 の SharePoint からの受信接続を受け入れるように構成する必要があります。

SharePoint 管理者は、プライマリ Web アプリケーションにデプロイされているハイブリッド ソリューションをサポートするために必要なサービスと接続オブジェクトを関連付けます。 送信接続は、機能固有の設定を使用することで、いずれの設置型の SharePoint Server Web アプリケーションからでも行えます。

SharePoint ServerWeb アプリケーション は、作成するサイト コレクションの論理ユニットとして動作する インターネット インフォメーション サービス (IIS) Web サイトで構成されます。 各 Web アプリケーションは、固有または共有のアプリケーション プールを持ち、固有のパブリック URL を持ち、代替アクセス マッピング (AAM) を使用する最大 5 つの内部 URL を使用できるように構成された、それぞれ異なる IIS Web サイトによって構成されています。 特定の Web アプリケーションは単一のコンテンツ データベースに関連付けられ、特定の認証方法を使用してデータベースに接続するように構成されています。 複数の Web アプリケーションがそれぞれ異なる認証方法を使用し、オプションで AAM も使用して、単一コンテンツ データベースへのアクセスを提供するように構成できます。

Web アプリケーションのパブリック URL は、Web アプリケーションを介してアクセスするサイトおよびコンテンツのすべてのリンクで、常にルート URL として使用されます。 パブリック URL ( https://spexternal.adventureworks.com) を持ち、AAM で内部 URL https://sharepoint が構成された Web アプリケーションを検討してください。 内部 URL (https://sharepoint を参照すると、SharePoint Server は URL が https://spexternal.adventureworks.com の Web サイトを返し、サイト内のすべてのリンクがこのパスに基づいた URL を持つようになります。

代替アクセス マッピング (AAM) は、外部 URL とは異なるパブリック URL を持つパス ベースのサイト コレクションを使用して受信接続を構成する場合 のみ必要です。 AAM を使用すると、外部 URL を組織内の Microsoft 365 サイトの SharePoint の内部 URL に関連付けることができます。 これにより、SharePoint Server は、AAM で構成された内部 URL の要求を対応するプライマリ Web アプリケーションにルーティングできます。

クレーム ベースの Web アプリケーションの詳細については、「SharePoint Server でクレーム ベースの Web アプリケーションを作成する」を参照してください。

Web アプリケーションの拡張方法の詳細については、「SharePoint でクレームベースの Web アプリケーションを拡張する」を参照してください。

サイト コレクションの詳細については、「SharePoint Server でのサイトとサイト コレクションの概要」を参照してください。

サイト コレクションの戦略を選択する

既存の Web アプリケーションを使用するか、新規作成するかを決定する前に、ハイブリッド機能のサポートに必要な Web アプリケーションおよびサイト コレクションの構成要件を理解する必要があります。 このセクションの情報を使用して、新しいWeb アプリケーションとサイト コレクションを作成する戦略、または既存 Web アプリケーションのサイト コレクションをハイブリッド環境で使用できるかどうかの決定を行ってください。

下図は、サイト コレクションの戦略を決定するための意思決定フローを示しています。

一方向受信または双方向の SharePoint ハイブリッドの認証トポロジの 3 つの可能なサイト コレクション戦略。

ハイブリッド Web アプリケーションの要件

ハイブリッド機能を使用する Web アプリケーションは、これらの要件をすべて満たす必要があります。

  • Web アプリケーションのパブリック URL は、外部 URL と同一である必要があります。

    OAuth プロトコルは SharePoint のハイブリッド ソリューションでのユーザー認証を提供します。 オンプレミスの SharePoint への Microsoft 365 通信のすべての SharePoint の ホスト 要求ヘッダーには、要求が最初に送信された URL が含まれています。 Microsoft 365 で SharePoint からの受信要求を認証するには、オンプレミスの SharePoint 認証サービスが、Microsoft 365 の SharePoint からプライマリ Web アプリケーションのパブリック URL へのすべてのトラフィックでこの URL を照合できる必要があります。 これは 外部 URL です。 SharePoint ハイブリッド環境のホスト名が付いたサイト コレクションを使用する 1 つの利点は、外部 URL と同じ URL を使用するようホスト名が付いたサイト コレクションを構成できることです。 これにより、代替アクセス マッピングを構成する必要がなくなります。

  • NTLM を使用した統合 Windows 認証を使用する Web アプリケーションを構成する必要があります。

    NTLM を使用する統合 Windows 認証は、サーバー間認証およびアプリケーション認証をサポートするシナリオで展開される Web アプリケーションの要件です。 詳細については、「SharePoint Server でサーバー間認証を計画する」を参照してください。

    SharePoint ハイブリッドのクレーム認証の種類

特定のサイト コレクションの構成要件

ハイブリッド機能に使用されるサイト コレクションは、これらの要件すべてを満たす必要があるとともに、Web アプリケーション要件を満たす既存のまたは新規作成された Web アプリケーションのいずれかに存在する必要があります。

  • ホスト名が付いたサイト コレクション

    • Web アプリケーションは、ホスト名が付いたサイト コレクションをサポートする必要があります。

      ホスト名が付いたサイト コレクションを作成するには、Web アプリケーションを有効化するように作成する必要があります。 Web アプリケーションを作成した後でこの機能を有効にすることはできません。

      ホスト名が付いたサイト コレクションの作成方法の詳細については、「SharePoint Server でのホスト名付きサイト コレクションのアーキテクチャと展開」を参照してください。

      注:

      これは Web アプリケーションの要件ですが、ホスト名が付いたサイト コレクションがある環境にのみ適用されるため、ここに挙げられています。

    • 設置型 DNS サーバーは、分割 DNS で構成する必要があります。 パブリック URL に使用したパブリック インターネット ドメインの前方参照ゾーンと、SharePoint Server の IP アドレスと外部 URL のホスト名を持つ前方参照ゾーンの A (ホスト) レコード を作成する必要があります。

      重要

      リバース プロキシ デバイスは、SharePoint Server ファームへの受信要求を中継するため、この前方検索ゾーンのホスト名を解決できる必要があります。

  • パスベースのサイト コレクション

    • パブリック URL が外部 URL と同じである場合

      設置型 DNS サーバーは、分割 DNS で構成する必要があります。 パブリック URL に使用したパブリック インターネット ドメインの前方参照ゾーンと、SharePoint Server の IP アドレスと外部 URL のホスト名を持つ前方参照ゾーン内の A レコード を作成する必要があります。

      重要

      リバース プロキシ デバイスは、SharePoint Server ファームへの受信要求を中継するため、この前方検索ゾーンのホスト名を解決できる必要があります。

      これは、SharePoint ハイブリッド用の web アプリケーションを構成する簡単な方法です。 目標は、新規 Web アプリケーションの パブリック URL フィールドとリバース プロキシの一般向けのエンドポイント (外部 URL としても知られています) の URL が一致することです。

    • パブリック URL が外部 URL と異なる場合

      Microsoft 365 で SharePoint からの受信要求を中継するように代替アクセス マッピング (AAM) を構成する必要があります。

      プライマリ Web アプリケーションを拡張し、外部 URL を パブリック URL として使用します。 続いて、ブリッジの URL として使用する拡張 Web アプリケーションと同じセキュリティ ゾーンに内部 URLを ( 内部 URL の追加 を介して) 作成します。 また、Microsoft 365 の SharePoint からの受信要求をこのブリッジング URL に中継するようにリバース プロキシ デバイスを構成します。

      代替アクセスマッピング (AAM) は、外部 URL とは異なるパブリック URL があるパス ベースのサイト コレクションを使用して受信接続を構成する場合 のみ必要であることを覚えておいてください。

注:

また、 外部 URL はリバース プロキシ デバイスのインターネット接続エンドポイントの URL であることも覚えておいてください。

   
編集アイコン ワークシートの表 2 の「 Site collection strategy」行に、サイト コレクション戦略を記録します。

既存の web アプリケーションを選択するか新規作成する

プライマリ Web アプリケーションとして使用するため、既存の Web アプリケーションを使用するか新規作成することができます。

独立してハイブリッド機能に使用する Web アプリケーションを管理するほうが良い場合、または既存の Web アプリケーションが「サイト コレクションの戦略を選択する」セクションの要件を満たしていない場合は、Web アプリケーションを新規作成することをお勧めします。

   
編集アイコン 決定内容を、表 2 の「 New or existing web application」行に記録します。

既存の web アプリケーションの使用を計画する

既存の Web アプリケーションをプライマリ Web アプリケーションとして使用する場合は、プライマリ Web アプリケーションの URL および最上位のサイト コレクションの URL を調べて、ワークシートに記録します。

   
編集アイコン ワークシートには、次の情報を記録します。
サイト コレクション戦略によって、表 5a、5b、または 5c の「 Primary web application URL」行にプライマリ Web アプリケーションの URL を記録します。
既存のホスト名が付いたサイト コレクションを使用する場合、表 5a の「 Host-named site collection URL」行に最上位サイト コレクションの URL を記録します。

Web アプリケーションの新規作成を計画する

Web アプリケーションの新規作成を決定した場合、ハイブリッド トポロジを構成する際にこれを行う方法について説明します。

SSL 証明書を計画する

SSL 証明書は、サーバーの ID を確立し、SharePoint ハイブリッド環境のさまざまなサービスおよび接続で、証明書の認証を提供します。 セキュリティで保護されたチャネルの SSL 証明書STS 証明書の 2 つの SSL 証明書が必要です。

SharePoint ハイブリッド環境での SSL 証明書の使用方法については、「SharePoint 2013 ハイブリッド トポロジ: 証明書および認証モデル」を参照してください。

注:

SSL を使用して設置型 SharePoint ファームのセキュリティを強化したい場合は、プライマリ Web アプリケーション用の SSL 証明書も必要です。 この証明書に関するハイブリッド固有の考慮事項はないので、SSL を使用して SharePoint Server を構成する場合の一般的なベストプラクティスに従ってください。

注:

「セキュリティで保護されたチャネル」は証明書のクラスではありません。この用語は、この特別な証明書を環境内で使用する他の SSL 証明書と区別する方法として使われています。

セキュリティで保護されたチャネルの SSL 証明書について

Secure Channel SSL 証明書は、リバース プロキシ デバイスと Microsoft 365 の間のセキュリティで保護された通信チャネルの認証と暗号化を提供し、サーバーとクライアント証明書の両方として機能します。 また、設置型 の SharePoint Server のサイト コレクションを発行するために使用するリバース プロキシ エンドポイントの ID を確認します。

この証明書は、ワイルドカードまたは SAN 証明書のいずれかにする必要があり、パブリック ルート証明機関によって発行される必要があります。 この証明書の "件名" フィールドには、リバース プロキシ サーバーの外部エンドポイントのホスト名、または名前空間にあるすべてのホスト名をカバーするワイルドカードの URL が含まれる必要があります。 少なくとも 2048 ビット暗号化を使用する必要があります。

重要

ワイルドカード証明書は、単一レベルの DNS 名前空間のみをセキュリティ保護することができます。 たとえば、外部 URL が https://spexternal.public.adventureworks.com の場合、ワイルドカード証明書の件名は *.adventureworks.com ではなく *.public.adventureworks.com である必要があります。

SharePoint Server に情報を要求するように Microsoft 365 の SharePoint が構成されているシナリオでは、次の操作を行うには SSL 証明書が必要です。

  • セキュリティ チャネル上でトラフィックを暗号化する。

  • 証明書の認証を使用して受信接続を認証するために、リバース プロキシのデバイスを有効にする。

  • Microsoft 365 の SharePoint が外部エンドポイントを識別して信頼できるようにします。

展開中に、リバース プロキシ デバイスと Microsoft 365 Secure Store ターゲット アプリケーションの SharePoint の両方に SSL 証明書をインストールします。 これは、ハイブリッド環境のインフラストラクチャを構成するときに構成します。

セキュア チャネル SSL 証明書を取得する

DigiCert、VeriSign、Thawte、GeoTrust などの既知の証明機関から、オンプレミスのパブリック ドメインの Secure Channel SSL ワイルドカードまたは SAN (サブジェクト代替名) 証明書を取得します。

注:

証明書は複数の名前をサポートし、2048 ビット以上である必要があります。 証明書は通常 1 年間隔で有効期限が切れます。 サービスの中断を避けるために、証明書の更新を事前に計画することが重要です。 SharePoint 管理者は、作業の停止を防ぐために十分なリードイン時間を提供する証明書の交換に関するリマインダーをスケジュールする必要があります。

STS 証明書について

設置型の SharePoint ファームの STS 証明書には、受信トークンを検証する既定の証明書が必要です。 SharePoint ハイブリッド環境では、Microsoft Entra ID は信頼されたトークン署名サービスとして機能し、署名証明書として STS 証明書を使用します。 既定の STS 証明書以外の証明書 (たとえば、パブリック証明機関の証明書) を使用する場合は、ハイブリッド構成プロセスを開始する前に、既定の証明書を置き換えます。

構成およびテストに必要なアカウントを記録する

SharePoint ハイブリッド環境のセットアップでは、オンプレミスの Active Directory と Microsoft 365 ディレクトリ (Microsoft 365 ディレクトリに表示される Microsoft Entra ID) の両方に複数のユーザー アカウントが必要です。 これらのアカウントには、異なる許可およびグループまたはロールのメンバーシップがあります。 ソフトウェアの展開や構成に使用するアカウントもあれば、セキュリティおよび認証システムが予想通りに機能することを保証するため、特定の機能をテストする必要があるアカウントもあります。

  • ロールと ID プロバイダーに関する注意事項なども記載された、必要なユーザー アカウントに関する詳細な説明は、「ハイブリッドの構成とテストに必要なアカウント」を参照してください。

  • 指示に従って、ワークシートに必要なアカウント情報を記録します。

  • この手順を完了した後は、この計画の記事に戻ります。

次の手順

この時点で、受信接続に必要なワークシートの記入が完了し、構成プロセスを開始できる状態になっているはずです。 次の手順は、「構成ロードマップの選択」です。