Export (0) Print
Expand All

Plan a two-way hybrid topology

SharePoint 2013
 

Applies to: SharePoint Server 2013, SharePoint Online

Topic Last Modified: 2014-09-13

Summary: Plan and prepare to deploy a two-way SharePoint Server 2013 hybrid environment.

Applies only to two-way configurations

This article is designed to help you plan and prepare to deploy a two way SharePoint Server 2013 hybrid environment. We give you the information that you need to know, such as prerequisites and a worksheet to collect necessary information before you begin the configuration process.

Before using this topic, you should read Overview of hybrid SharePoint 2013 for technical decision makers.

This topic will help you do the following:

  • Understand the prerequisites and requirements of a two-way hybrid topology

  • Plan your web application architecture

  • Plan SSL certificates

  • Plan your identity management strategy

  • Record key decisions and information

WarningWarning:
To configure a hybrid SharePoint environment, you need a combination of expert skills and significant hands-on experience with several products, including SharePoint Server 2013, SharePoint Online, and related products and technologies. If this skill and expertise is not available in-house, we recommend that you engage Microsoft Consulting Services to provide technical guidance and support during the design and deployment of your hybrid environment.

A two-way topology enables bidirectional hybrid service integration between your on-premises SharePoint Server 2013 farm environment and your Office 365 tenant. For example, search can be configured to allow federated users to see both local and remote search results in either SharePoint Server 2013 or SharePoint Online Search portals.

A two-way topology can be configured to let your users access on-premises SharePoint search results from the Internet, as long as they have access to the intranet through a virtual private network or DirectAccess.

NoteNote:
If you are still unsure what environment is right for your needs, see the poster What hybrid topology should I use?.

A two-way SharePoint Server 2013 hybrid solution requires the following four phases to deploy:

These are the four stages of deploying a SharePoint hybrid environment
  • Phase 1: Configure a hybrid topology

  • Phase 2: Configure a reverse proxy for a SharePoint hybrid environment

  • Phase 3: Configure the hybrid identity management infrastructure

  • Phase 4: Configure a hybrid solution, such as Search, Business Connectivity Services, or Duet Enterprise Online

For a glossary of terms specific to hybrid SharePoint Server 2013 environments, see Glossary for hybrid SharePoint 2013.

This section lists the prerequisites that you need before you’ll be ready to deploy a SharePoint hybrid two-way environment. The prerequisites are listed here according to the deployment phase to which they apply.

  • An operational, on-premises ADFS domain in a forest that is running at the Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, or Windows Server 2012 R2 forest functional level

  • An Internet domain (such as https://adventureworks.com) and the permission to create or edit DNS records for that domain

  • An Office 365 for enterprises subscription provisioned with SharePoint Online with one of the following subscription plans: E3 or E4

  • An operational on-premises SharePoint Server 2013 Enterprise Edition farm

NoteNote:
For more information about the supported plans, see the Plans & pricing page on the Office 365 site.
For more information about the SharePoint Online features supported for different Office 365 plans, see SharePoint Online feature availability across Office 365 plans.

  • For a two-way (bidirectional) hybrid topology, you have to configure a supported on-premises reverse proxy device to provide a secure, Internet-facing endpoint for the connection.

For complete information on the supported reverse proxy devices and their prerequisites, see Configure a reverse proxy device for SharePoint Server 2013 hybrid.

  • An on-premises server for Active Directory Federation Services (AD FS) 2.0 (minimum version). This is required only if you deploy SSO with ADFS.

  • An on-premises server for the Azure Active Directory Sync tool (DirSync).

  • An SSL certificate to use as the Secure Channel SSL certificate (either a wildcard or SAN certificate issued by a public root authority).

  • An SSL certificate to replace the default Security Token Service (STS) certificate (either self-signed or issued by a public or enterprise certification authority).

Worksheet. During the planning process, you have to collect information and files. It is important to use the hybrid deployment worksheet to track planning and deployment information for reference and to share with other members of your deployment team. We can’t stress enough the importance of using this worksheet to organize your information before you begin the configuration process.

Create a build log. As in any complex implementation project, a detailed record of every design decision, server configuration, procedure, command output, and error is a very important reference for troubleshooting, support, and awareness. We highly recommend that you thoroughly document your deployment process.

WarningWarning:
For security reasons, store the worksheet and the build log in a security-enhanced place, such as a secured file share or SharePoint document library, and grant permissions only to administrators who are involved in the deployment process and must know this information.

In this section, you record information about URLs and host names in your environment. You will use this information during the deployment process.

  • Record your company’s public DNS domain name (such as adventureworks.com).

  • Record the URL of the public-facing endpoint of the reverse proxy device that you’ll use for SharePoint hybrid. This is the External URL. If this endpoint doesn’t exist yet, you’ll have to decide what this URL will be.

  • Record the IP address of the external endpoint of the reverse proxy device.

  • Ensure that an A record (also known as a host record) exists in the public DNS forward lookup zone for your public domain that maps the External URL to the IP address of the Internet-facing endpoint on the reverse proxy device. If you don’t yet have this A record, create it now.

  • Ensure that an A record exists in the intranet DNS forward lookup zone that maps the host name of your SharePoint Server 2013 farm to its IP address. If you don’t yet have this A record, create it now.

    ImportantImportant:
    If you configure internal URLs to access a web application during the deployment process, make sure that you also create A records for those URLs in the intranet DNS forward lookup zone, and record them on the worksheet.

 

Edit icon

Record the following information in Table 3 of the SharePoint Hybrid worksheet:

  • The domain name of the public-facing corporate DNS domain in the Public Internet Domain name row.

  • The URL of the public-facing endpoint of the reverse proxy device in the External URL row.

  • The IP address of the external endpoint of the reverse proxy device in the IP Address of the external endpoint row.

For more information about the relationship between URLs and host names in a hybrid environment, watch the video Understanding URLs and host names. Length: 6 minutes.

This section helps you plan the architecture of the SharePoint Server 2013 web applications that you will use in your hybrid environment.

Two-way and one-way inbound SharePoint hybrid topologies require a secure communication channel between the on-premises SharePoint Server 2013 farm and SharePoint Online. Data is exchanged between a site collection in SharePoint Online and an on-premises web application over this communication channel.

In a two-way hybrid topology, SharePoint Online sends requests to a reverse proxy server that relays the requests to a specific web application in the on-premises SharePoint Server 2013 farm that is configured for SharePoint hybrid. We refer to this as the primary web application.

TipTip:
Regardless of how many hybrid solutions that you plan to configure, you typically will use only one primary web application. You don’t have to create extra primary web applications for each additional hybrid solution.

In a one-way inbound or two-way hybrid SharePoint Server 2013 topology, both the primary web application and a single site collection within the primary web application must be configured to accept inbound connections from SharePoint Online.

The SharePoint administrator associates the services and connection objects that are needed to support the hybrid solutions that are being deployed with the primary web application. Outbound connections can be made from any on-premises SharePoint Server 2013 web application by using the feature-specific configurations.

A SharePoint Server 2013 web application is composed of an Internet Information Services (IIS) website that acts as a logical unit for the site collections that you create. Each web application is represented by a different IIS website that has a unique or shared application pool, that has a unique public URL, and that can also be configured to use up to five internal URLs using Alternate Access Mapping (AAM). A given web application is associated with a single content database and is configured to use a specific authentication method to connect to the database. Multiple web applications can be configured with different authentication methods, and optionally AAMs, to provide access to a single content database.

A web application’s public URL is always used as the root URL in all links to sites and content accessed through the web application. Consider a web application with the public URL https://spexternal.adventureworks.com that has an internal URL https://sharepoint configured in AAM. When you browse to the internal URL https://sharepoint, SharePoint Server 2013 returns the website that has the URL https://spexternal.adventureworks.com, and all links within the site will have URLs based on that path.

Alternate access mapping (AAM) is needed only when you are configuring a two-way or a one-way inbound hybrid topology using a path-based site collection with a public URL that is different than the external URL. AAM lets you associate the external URL with the internal URL of a SharePoint site inside your organization. This enables SharePoint Server 2013 to route requests for internal URLs configured in AAM to the corresponding primary web application.

For more information about claims-based web applications, see Create claims-based web applications in SharePoint 2013.

For more information about how to extend a web application, see Extend claims-based web applications in SharePoint 2013.

For more information about site collections, see Overview of sites and site collections in SharePoint 2013.

Before you decide to use an existing web application or create a new one, you need to understand the configuration requirements that the web application and site collection must meet to support hybrid functionality. Use the information in this section to determine your strategy for creating a new web application and site collection or to determine whether a site collection in an existing web application can be used in your hybrid environment.

The following figure shows the decision flow for determining your site collection strategy.

The three possible site collection strategies for a one-way inbound or two-way SharePoint hybrid authentication topology.

Requirements for hybrid web applications

Web applications used for hybrid functionality must meet all these requirements:

  • The public URL of the web application must be identical to the External URL.

    The OAuth protocol provides user authorization in SharePoint hybrid solutions. The Host request header in all SharePoint Online communications to SharePoint on-premises contains the URL to which the request was originally sent. To authenticate inbound requests from SharePoint Online, the on-premises SharePoint Authentication service must be able to match this URL in all traffic from SharePoint Online to the public URL of the primary web application. This is the External URL. One advantage of using a host-named site collection for SharePoint hybrid environments is that you can configure a host-named site collection to use the same URL as the External URL. This eliminates the need to configure Alternate Access Mapping.

  • The web application must be configured to use Integrated Windows authentication using NTLM.

    Integrated Windows authentication using NTLM is required for web applications that are deployed in scenarios that support server-to-server authentication and app authentication. For more information, see Plan for server-to-server authentication in SharePoint 2013.

    Claim authentication types for SharePoint hybrid

Requirements for specific site collection configurations

Site collections used for hybrid functionality must meet all these requirements, and must also either exist in or be created in a web application that meets the web application requirements:

  • Host-named site collections

    • The web application must support host-named site collections.

      To create a host-named site collection, the web application must be created to enable them. You cannot enable this functionality after the web application has been created.

      For more information about how to create a host-named site collection, see Host-named site collection architecture and deployment (SharePoint 2013).

      NoteNote:
      Although this is a web application requirement, it is listed here because it applies only to environments that have host-named site collections.
    • Your on-premises DNS server must be configured with split DNS. You have to create a forward lookup zone for the Public Internet domain that you used for your public URL and an A (host) record in the forward lookup zone that has the IP address of the SharePoint Server 2013 server and the host name of your External URL.

      ImportantImportant:
      The reverse proxy device must be able to resolve host names in this forward lookup zone to relay inbound requests to the SharePoint Server 2013 farm.
  • Path-based site collections

    • If the public URL is identical to the External URL:

      Your on-premises DNS server must be configured with split DNS. You have to create a forward lookup zone for the Public Internet domain that you used for your public URL and an A record in the forward lookup zone that has the IP address of the SharePoint Server 2013 server and the host name of your External URL.

      ImportantImportant:
      The reverse proxy device must be able to resolve host names in this forward lookup zone to relay inbound requests to the SharePoint Server 2013 farm.

      This is an easy way to configure a web application for a SharePoint hybrid. The goal is to match the Public URL field of the new web application to the URL of the public-facing endpoint on the reverse proxy, which is also known as the External URL.

    • If the public URL is different from the External URL:

      You have to configure an alternate access mapping (AAM) to relay inbound requests from SharePoint Online.

      Extend the primary web application and use the External URL as the Public URL. Then create an Internal URL (via Add Internal URLs) in the same security zone as the extended web application to use as a bridging URL. You will also configure the reverse proxy device to relay inbound requests from SharePoint Online to this bridging URL.

      Remember, alternate access mapping (AAM) is needed only when you are configuring a two-way or a one-way inbound authentication topology using a path-based site collection with a public URL that is different than the external URL.

NoteNote:
Remember that the External URL is the URL of the Internet-facing endpoint of the reverse proxy device.

 

Edit icon

Record your decision in Site collection strategy row of Table 2 of the worksheet.

You can either use an existing web application or create one to use as the primary web application.

If you prefer to manage the web application used for hybrid functionality independently or if your existing web application does not meet the requirements that are listed in the Choose a site collection strategy section, you should create a new web application.

 

Edit icon

Record your decision in the New or existing web application row of Table 2 of the worksheet.

If you decide to use an existing web application as the primary web application, gather the URL of the primary web application and the URL of the top-level site collection and list it on the worksheet.

 

Edit icon

Record the following information in the worksheet:

  • Depending on your site collection strategy, record the URL of the primary web application in the Primary web application URL row of Table 5a, 5b, or 5c.

  • If you are using an existing host-named site collection, record the URL of the top-level site collection in the Host-named site collection URL row of table 5a.

After you record this information, go to the section Plan SSL Certificates .

If you decide to create a new web application, we will direct you on how to do this when you are configuring the hybrid topology.

SSL certificates establish server identity and provide certificate authentication for several different services and connections in a SharePoint hybrid environment. When you configure a two-way hybrid environment, you must have two SSL certificates: a Secure Channel SSL certificateand an STS certificate.

For more information on SSL certificates that are used in SharePoint hybrid environments, see SharePoint 2013 Hybrid Topology: Certificate and Authentication Model.

NoteNote:
If you choose to help secure your on-premises SharePoint farm with SSL, you will also need an SSL certificate for the primary web application. There are no hybrid-specific considerations for this certificate. Therefore, you can follow the general best practices for configuring SharePoint Server 2013 with SSL.
NoteNote:
“Secure Channel” is not a class of certificate. We use the term as a way to differentiate this particular certificate from other SSL certificates that are used in the environment.

A Secure Channel SSL certificate provides authentication and encryption for the secure communication channel between the reverse proxy device and Office 365, acting as both a server and a client certificate. It also verifies the identity of the reverse proxy endpoint that’s used to publish the on-premises SharePoint Server 2013 site collection.

This certificate must be either a wildcard or a SAN certificate and be issued by a public root certification authority. The subject field of this certificate must contain the host name of the external endpoint of the reverse proxy server or a wildcard URL that covers all host names in the namespace. It must use at least 2048-bit encryption.

ImportantImportant:
Wildcard certificates can secure only a single level of a DNS namespace. For example, if your external URL is https://spexternal.public.adventureworks.com, the subject of your wildcard certificate must be *.public.adventureworks.com, not *.adventureworks.com.

In scenarios where SharePoint Online is configured to request information from SharePoint Server 2013, an SSL certificate is required to do the following:

  • Encrypt traffic over the security channel.

  • Enable the reverse proxy device to authenticate inbound connections using Certificate Authentication.

  • Allow SharePoint Online to identify and trust the external endpoint.

During deployment, you’ll install the SSL certificate both on the reverse proxy device and in a SharePoint Online Secure Store target application. You will configure this when you configure the hybrid environment infrastructure.

Get a Secure Channel SSL wildcard or SAN (Subject Alternative Name) certificate for your on-premises public domain from a well-known certification authority, such as DigiCert, VeriSign, Thawte, or GeoTrust.

NoteNote:
  • This certificate must support multiple names and must be at least 2048 bits.

  • The Subject or Subject Name field of the certificate must contain a wildcard entry of the domain name in the External URL. For example, if your external URL is https://spexternal.public.adventureworks.com, the subject of your wildcard certificate should be *.public.adventureworks.com.

  • Certificates typically expire at one-year intervals. So it’s important to plan in advance for certificate renewals to avoid service interruptions. SharePoint Administrators should schedule a reminder for certificate replacement that gives you enough lead-in time to prevent a work stoppage.

 

Edit icon

Record the following in Table 4b of the worksheet:

  • The name of this certificate and the location where you stored it in the Secure Channel SSL Certificate location and file name row.

  • The friendly name of this certificate in the Secure Channel SSL Certificate Friendly Name row.

  • Specify the type of certificate (wildcard or SAN) in the Type of certificate row.

  • The expiration date of the certificate in the Expiration date row.

  • If this certificate has a .pfx file name extension, record the certificate’s password in the Secure Channel SSL Certificate Password row. Remember to help secure the worksheet with password protection if you update it with password information.

The STS certificate of the on-premises SharePoint farm requires a default certificate to validate incoming tokens. In a SharePoint hybrid environment, Azure Active Directory acts as a trusted token signing service and uses the STS certificate as the signing certificate. Azure Active Directory cannot use the default STS certificate from SharePoint Server as a signing certificate because it cannot verify the trust chain.

Therefore, you must replace the default STS certificate on each server in the on-premises SharePoint farm with one of the following:

  • A certificate issued by a public certification authority (CA) that’s trusted by Azure Active Directory

  • A self-signed certificate

The default STS certificate is replaced later when you configure the identify management infrastructure.

ImportantImportant:
  • This certificate must be at least 2048 bits.

  • You’ll have to replace the STS certificate on each web and application server in the SharePoint Server 2013 farm.

  • Certificates typically expire at one-year intervals. So it’s important to plan in advance for certificate renewals to avoid service interruptions.

If you choose to use a self-signed certificate, you’ll create it during the deployment configuration. The steps for creating a new self-signed certificate for SharePoint are included in the Configure identity management for a hybrid topology in SharePoint Server 2013 topic.

Create your STS certificate before you begin the configuration process.

 

Edit icon

Record the following on the worksheet in in Table 4a:

  • STS Certificate Friendly Name

  • STS Certificate path\file name (*.pfx file)

  • STS Certificate Password

  • STS Certificate path\file name (*.cer file)

  • Subject Name

  • STS Certificate Start Date

  • STS Certificate End Date

You can choose between two identity management strategies: Password Sync in the Azure Active Directory Sync tool (DirSync) and single sign-on (SSO).

The Azure Active Directory Sync tool (DirSync) is required to sync your on-premises users to the Office 365 user directory. If you don’t want to implement SSO, you can configure the Password Sync feature in DirSync to synchronize passwords, instead. Be aware that Password Sync isn’t a single sign-on solution. Users are prompted for their credentials again when they access SharePoint Online. For additional information about Password Sync in the Azure Active Directory Sync tool, see Implement Password Synchronization (http://go.microsoft.com/fwlink/?LinkId=392303).

Single sign-on (SSO) using Active Directory Federation Services (AD FS) 2.0 lets users who have an Active Directory domain account use their domain usernames and passwords to access sites on-premises and in Office 365 without being prompted for credentials when they access a SharePoint Online resource. After a user is authenticated, Active Directory Federation Services (AD FS) 2.0 provides an authentication token when a federated user accesses a relying-party trust service such as the corporate Office 365 tenant.

ImportantImportant:
ADFS 2.0 and later versions are supported by Office 365.
ImportantImportant:
Your choice of a reverse proxy device may affect this decision. If you implement Web Application Proxy in Windows Server 2012 R2 as your reverse proxy device, you’ll also need to deploy Active Directory Federation Services (AD FS) 2.0 in Windows Server 2012 R2. For more information, see Configure Web Application Proxy for a hybrid environment.
You must configure either SSO or Password Sync.

If you’re not completely sure whether to use Password Sync or SSO, review the following diagram.

Process to configure identity management for SharePoint hybrid

 

Password Sync with DirSync SSO with AD FS

Passwords

DirSync synchronizes user accounts and password hashes to Azure Active Directory (password hashes can’t be reversed to produce a plaintext password).

SSO with AD FS intercepts authentication requests and provides the user’s credentials from Active Directory.

Prompts

No token exchanges are involved, although users can log on to Office 365 with their Active Directory credentials. Users may be prompted when they access services and resources in Office 365.

Prompts for credentials can be decreased by clicking the ‘Keep me signed in’ check box when users log on.

Tokens issued to clients by AD FS can be shared with services such as Azure Active Directory to allow single sign-on from almost anywhere. Users do not have to enter their credentials again when they use services and resources in a relying-party trust service.

Security

Although passwords are synchronized more often than other user data, the user may remain logged on in a session with an old password. There may be some lag between password change and sync.

Passwords are stored in Active Directory.

 

Edit icon

Record in Table 2 of the worksheet the Identity Management Type:

  • DirSync with Password Sync

or

  • SSO using ADFS

A SharePoint hybrid environment setup requires several user accounts in both your on-premises Active Directory and the Office 365 directory (Azure Active Directory that is surfaced in the Office 365 directory). These accounts have different permissions and group or role memberships. Some of the accounts are used to deploy and configure software, and some are needed to test specific functionality to help guarantee that security and authentication systems are working as expected.

  • Go to Accounts needed for hybrid configuration and testing for a complete explanation of the required user accounts that includes notes about roles and identity providers.

  • Record the required account information in the worksheet as instructed.

  • Return to this planning article after you complete this step.

At this point, you should have completed filling out the required worksheet for your two-way hybrid topology and be ready to start the configuration process. Your next step is to follow the instructions in Configure a two-way hybrid topology.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft