Export (0) Print
Expand All
2 out of 3 rated this helpful - Rate this topic

Configure identity management for a hybrid topology in SharePoint Server 2013

SharePoint 2013
 

Applies to: SharePoint Server 2013, SharePoint Online

Topic Last Modified: 2014-04-14

Summary: Learn how to synchronize on-premises user accounts with Office 365, and build a server-to server trust between SharePoint Server 2013 and SharePoint Online.

This article provides guidance for Phase 3 of the SharePoint hybrid environment deployment process which integrates SharePoint Server 2013 and SharePoint Online.

Phase 3: Configure the SharePoint hybrid identity management infrastructure

Stage three of a SharePoint hybrid deployment

 

This figure represents steps to be completed

This is the third phase in the process to configure a SharePoint hybrid solution. The procedures in these articles must be completed in the following order:

  1. Configure a hybrid topology for SharePoint Server 2013

  2. Configure a reverse proxy device for SharePoint Server 2013 hybrid (if needed)

  3. Configure the hybrid identity management infrastructure (this phase)

  4. Configure a hybrid solution for SharePoint Server 2013

For an overview of the whole process, see Plan SharePoint Server 2013 hybrid.

After you complete and validate the procedures in this article, you will then proceed to Phase 4: Configure a hybrid solution for SharePoint Server 2013.

TipTip:
For the most reliable outcome, complete the procedures in the order they are shown in this article.
NoteNote:
SharePoint supports the accessibility features of common browsers to help you administer deployments and access sites. For more information, see Accessibility for SharePoint 2013.

If you haven’t done so already, make sure that you’ve read Plan SharePoint Server 2013 hybrid before you start to configure anything. This is important because the planning article helps you make important decisions and record them on the SharePoint hybrid worksheet, referred to as the worksheet in the rest of this article. This in turn informs which procedures in this article to use and which to skip over.

If you’ve read the appropriate planning article for the authentication topology your solution requires, then you should have already done the following:

  • If you’re configuring a production environment, you should have obtained an STS certificate and listed it on the worksheet.

  • Decided which identity management type you’ll configure and recorded your decision on the worksheet.

Things will go a lot easier if all of the applicable information is entered on the SharePoint hybrid worksheet before you start to configure anything. There are two versions of the worksheet: one for one-way outbound topologies and one for the one-way inbound and two-way topologies. You should have already been using the appropriate worksheet for the topology you’re configuring, during planning and when you configured the environment infrastructure.

At a minimum, you’ll have to know the things that are listed in this table to use this article:

Table: Decisions that should already be recorded on the SharePoint hybrid worksheet

Decision Location on the worksheet Applicable authentication topologies

If you’re configuring a production environment, what’s the information for your STS certificate that you obtained from a CA?

All rows in table 4a.

All

Which identity management type will you configure?

Identity management type row of table 2.

All

Which site collection strategy will you use?

Site collection strategy row of table 2.

One-way inbound and two-way

What’s the name of your public domain?

Public Internet Domain name row of table 3.

One-way inbound and two-way

What’s the URL of the public-facing endpoint on your reverse proxy device that’s configured for hybrid?

External URL row of table 3.

One-way inbound and two-way

What’s the URL of the primary web application that you’ve configured for hybrid?

Primary web application URL row of table 5a, 5b, or 5c.

One-way inbound and two-way

Make sure that these choices are entered on the worksheet before you continue.

This section describes the steps to create a common identity management framework and server-to-server trust relationship between on-premises SharePoint Server 2013 and SharePoint Online.

  1. Synchronize your on-premises users to Office 365

  2. Configure SSO or Password Sync

  3. Configure server-to-server (S2S) authentication between SharePoint Server 2013 and SharePoint Online

NoteNote:
  • The Azure Active Directory Synchronization Tool is required to sync your on-premises users to the Office 365 user directory. If you don’t want to use ADFS with SSO, you can configure the Azure Active Directory Synchronization Tool to synchronize passwords instead. For additional information about Dirsync, see Implement Password Synchronization (http://go.microsoft.com/fwlink/?LinkId=392303).

  • Single sign-on (SSO) lets users logon once and not have to log on again to other relying-party services. SSO is optional. You can choose to set up Password Sync in the Azure Directory Synchronization tool instead.

    ImportantImportant:
    You must configure either SSO or Password Sync.
  • Server-to-server (S2S) authentication is required to enable trusted communications between the on-premises SharePoint Server 2013 farm and SharePoint Online.

For more information about authentication in SharePoint hybrid, see Plan SharePoint Server 2013 hybrid.

 

Edit icon

The identity management type that you chose during planning should be recorded in the Identity management type row of Table 2 of the worksheet.

Your organization probably has an existing body of users in its on-premises directory service. To enable the users to use hybrid services, you must synchronize these users with the Office 365 user directory, which is Azure Active Directory (Azure AD) in the cloud. These accounts are maintained and managed on-premises and changes are synchronized up to the cloud.

Directory synchronization is done with the Azure Active Directory Synchronization Tool. To set up directory synchronization, see Configure directory synchronization (http://go.microsoft.com/fwlink/?LinkId=392306). For additional information about directory synchronization, see Directory Sync Scenario (http://go.microsoft.com/fwlink/?LinkId=392307).

If you have decided not to implement SSO, you can configure the Azure Active Directory Synchronization Tool to synchronize your on-premises user account passwords to SharePoint Online. For additional information about Password Sync in the Azure Active Directory Synchronization Tool, see Implement Password Synchronization (http://go.microsoft.com/fwlink/?LinkID=392303).

You can set up directory synchronization to filter which users are synchronized with Office 365. For example, you can place all the users who you want to be able to use hybrid features in a single organizational unit (OU) in Active Directory, and then configure filtering to only synchronize that OU. For additional information, see Configure filtering for directory synchronization (http://go.microsoft.com/fwlink/?LinkId=392308).

You can validate that directory synchronization is working by verifying that the People Picker tool for SharePoint Online can find federated users and groups in AD DS (users who are synchronized with Azure AD).

 

Edit icon

The identity management type that you chose during planning should be recorded in the Identity management type row of Table 2 of the worksheet.

For complete information about how to plan for directory integration, see Directory integration (http://go.microsoft.com/fwlink/?LinkId=392309).

Configuring single sign-on for SharePoint Server 2013 hybrid is optional. If you’ve chosen to implement SSO instead of Password Sync in Directory Synchronization, complete the steps in this section.

NoteNote:
In order for federated extranet users to log on remotely by using SSO, you must configure your federation identity provider (such as ADFS) to support extranet authentication.

Before you move on to the next configuration step, you should validate that SSO is working.

You can use OnRamp for Office 365 (http://go.microsoft.com/fwlink/?LinkId=392313) to validate your on-premises environment. OnRamp provides browser-based discovery tools to capture key information in your on-premises environment. This includes specific tests for hybrid environment requirements. It also provides detailed information about required configuration changes and compliance with known limits.

To validate your SSO configuration in SharePoint Online, verify that federated users can browse the SharePoint Online site collection without being prompted for credentials.

  • In your intranet: Federated users should be able to log on to an on-premises computer and browse SharePoint Online site collections without being prompted for credentials.

  • From the Internet: If you’ve configured your federation identity provider to allow extranet authentication, a federated user should be able to log on to a computer on the Internet and browse a SharePoint Online site collection. Depending on your SSO configuration, you may be prompted for credentials by the federation identity provider.

To troubleshoot SSO issues, see Remote Connectivity Analyzer (http://go.microsoft.com/fwlink/?LinkId=392314).

This browser-based tool offers several connectivity tests. This includes tests that analyze SSO and Office 365. For additional information about how to troubleshoot SSO with the Remote Connectivity Analyzer, see How to diagnose single sign-on (SSO) logon issues in Office 365 by using Remote Connectivity Analyzer (http://support.microsoft.com/kb/2650717).

You can also read Troubleshoot single sign-on implementation in Office 365 (http://support.microsoft.com/kb/2530569) if you need more SSO troubleshooting guidance.

This section will help you set up server-to-server authentication between:

  • SharePoint Server 2013

  • SharePoint Online

  • Azure Active Directory

When you set up server-to-server authentication for hybrid environments, you create a trust relationship between your on-premises SharePoint farm and your SharePoint Online tenant, which uses Azure AD as a trusted token signing service. By adding the required Windows PowerShell modules and snap-ins, this process can occur in a single Windows PowerShell window on an on-premises SharePoint web server.

Here’s a high-level view of the procedures you’ll have to complete in this section:

  1. Configure the Security Token Service (STS) in SharePoint Server 2013

    • Create a new STS certificate

    • Replace the default STS certificate on each server in your SharePoint Server 2013 farm

  2. Install online service management tools on a web server in your SharePoint Server 2013 farm

  3. Configure server-to-server authentication

    • Set variables you’ll be using in later steps

    • Upload the new on-premises STS certificate to SharePoint Online

    • Add a Service Principal Name (SPN) to Azure

    • Register the SharePoint Online application principal object ID with on-premises SharePoint Server 2013

    • Configure a common authentication realm between your on-premises SharePoint Server 2013 farm and SharePoint Online

    • Configure a Azure AD application proxy on-premises

NoteNote:
To make it easier to complete the steps in this section, you should open a single Windows PowerShell Command Prompt window on a SharePoint Server 2013 web server, and add the modules and snap-ins that will let you connect to SharePoint Server 2013, SharePoint Online and Azure AD. Authentication to these environments through Windows PowerShell requires different user accounts. See the Permissions section of Use Windows PowerShell to administer SharePoint 2013 for the appropriate account.

For information about how to determine which account to use, see Accounts needed for hybrid configuration and testing.

TipTip:
You’ll want to keep a record of your steps, the Windows PowerShell cmdlets you run, and any errors that you might encounter. You should set the Windows PowerShell window with the maximum possible buffer size, and then capture all the contents of the Windows PowerShell buffer when you have finished, and before you close the window. This will give you a history of the steps that you took, which will be helpful if you have to troubleshoot or explain the process to others. This is also useful to refresh your memory if setup happens in stages.

You have to replace the STS certificate in the on-premises SharePoint farm. The job of this certificate is to establish trust between the Security Token Service of your on-premises SharePoint site collection and the SharePoint Online tenant. This enables the STS Service and Azure AD to sign security tokens for authenticated users.

For production environments, we recommend your new STS certificate be issued by a public Certificate Authority (CA). This gives you the highest level of certificate security, and reduces the chance a self-signed certificate will have integration issues with other applications and services. You can use a self-signed certificate for test or pilot environments.

ImportantImportant:
Certificates usually expire after 1 year. So plan in advance for certificate renewals to avoid service interruptions. This certificate must be at least 2048 bit encryption.

If you obtained an STS certificate from a CA during planning, it will be listed on table 4a of the worksheet. If so, go to Replace the STS Certificate. Otherwise, if you want to create a self-signed certificate, continue to Create a self-signed certificate.

In this step, you’ll create a new self-signed SSL certificate to use as your STS certificate. You'll create a new certificate in two file formats:

  • .pfx, which contains the private key

  • .cer, which does not contain the private key

You’ll use the IIS Manager when you do this, as illustrated by the following figure.

This picture shows where to click in IIS manager to create a self-signed certificate

This figure illustrates IIS Manager

To generate a self-signed certificate as a Personal Information Exchange (.pfx) file and then export it as a .cer file, use the IIS snap-in to complete the following steps:

Create the self-signed certificate as a .pfx file
  1. On a web server in your SharePoint Server farm, click Start -> Administrative Tools -> Internet Information Services (IIS) Manager.

  2. Click on the name of your server.

  3. In the details pane, double-click Server Certificates under IIS.

  4. In the Actions pane, click Create Self-Signed Certificate.

  5. On the Specify Friendly Name page, specify a friendly name for the certificate, and then click OK.

     

    Edit icon

    Record the certificates friendly name in the STS Certificate Friendly Name row of Table 4a of the worksheet.

  6. In the details pane, right-click the new certificate, and then click Export.

  7. In Export Certificate, specify a path and name to store the .pfx file for the certificate in Export to, and a password for the certificate file in Password and Confirm password. This creates a .pfx file that contains the private key.

     

    Edit icon

    Do the following:

    • Record the location and filename of this certificate to the STS Certificate path\filename (*.pfx file) row of table 4a of the worksheet.

    • Record the password to the STS Certificate Password row of table 4a of the worksheet.

  8. Click Finish, and then click OK twice.

Export the self-signed certificate as a .cer file
  1. On the same server, click Start -> Administrative Tools -> Internet Information Services (IIS) Manager.

  2. Click on the name of your server.

  3. In the details pane, double-click Server Certificates (under IIS).

  4. Right-click the new certificate you created in the last step, and then click View.

     

    Edit icon

    The location and file name of this certificate is recorded in the STS Certificate path\filename (*.pfx file) row of Table 4a of the worksheet.

  5. On the Details tab, click Copy to File.

  6. Click Next on the wizard.

  7. On the Export Private Key page, click Next.

  8. For Export File Format page, choose Base-64 encoded X.509 (.CER). Click Next.

  9. For Export Certificate type a path and file name for the .cer file. Click Next.

     

    Edit icon

    Record the path and filename of this certificate in the STS Certificate path\filename (*.cer file) row of Table 4a of the worksheet.

  10. Click Finish, and then click OK twice.

Now we’ll replace the default STS certificate on each server in the farm. You’ll either use your new self-signed certificate, or a certificate from a public CA that’s trusted by SharePoint Online (most public root CAs are trusted). You must also add the new certificate to the Trusted Root Certificate Authority store on each farm server. For more information, see Manage Trusted Root Certificates (http://go.microsoft.com/fwlink/?LinkId=392349).

CautionCaution:
Do this procedure during a maintenance window because after replacing the STS certificate on each farm server, you need to restart IIS and the SharePoint timer service. This will interrupt the service of your SharePoint Server 2013 farm.
To replace a STS certificate by using SharePoint 2013 Management Shell
  1. Log on to a server in your SharePoint Server farm.

  2. Verify that you have the following memberships:

    • securityadmin fixed server role on the SQL Server instance.

    • db_owner fixed database role on all databases that are to be updated.

    • Administrators group on the server on which you are running the Windows PowerShell cmdlets.

    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

    NoteNote:
    If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.
  3. Start the SharePoint 2013 Management Shell.

    • For Windows Server 2008 R2:

      • On the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.

    • For Windows Server 2012:

      • On the Start screen, click SharePoint 2013 Management Shell.

        If SharePoint 2013 Management Shell is not on the Start screen:

      • Right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.

    For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.

  4. Copy the following variable declarations and paste them into a text editor like Notepad. Set input values specific to your organization.

     

    Edit icon

    The following variables are listed in these rows of Table 4a of the worksheet:

    • STS Certificate path\filename (*pfx file)

    • STS Certificate Password

    At the Windows PowerShell command prompt, paste the following commands:

    $pfxPath = "<path to replacement certificate (.pfx file)>"
    $pfxPass = "<certificate password>"
    $stsCertificate = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 $pfxPath, $pfxPass, 20
    Set-SPSecurityTokenServiceConfig -ImportSigningCertificate $stsCertificate
    certutil -addstore -enterprise -f -v root $stsCertificate
    iisreset
    net stop SPTimerV4
    net start SPTimerV4
    
    NoteNote:
    These commands will not display any output if they are successful.

    To validate this step, on each server in the farm, at the Windows PowerShell command prompt type:

    $stsCertificate |fl
    

    In the output on the screen, confirm that the certificate has the new friendly name.

     

    Edit icon

    The friendly name of this certificate is listed in the STS Certificate Friendly Name row of Table 4a of the worksheet.

    For more information about to replace the STS certificate in a SharePoint Server 2013 farm, see Configure the security token service (http://go.microsoft.com/fwlink/?LinkId=392352).

  5. Repeat steps 1 through 4 on each remaining front-end web and application server in the SharePoint Server 2013 farm.

To continue, you need to install these tools on an on-premises SharePoint Server 2013 web server:

  • The Microsoft Online Services Sign-In Assistant

  • The Azure Active Directory Module for Windows PowerShell

  • The SharePoint Online Management Shell

Then you will load the Windows PowerShell modules and snap-ins you’ll need to complete the final steps in this article in a single Windows PowerShell window.

This is most easily accomplished on a web server in your SharePoint farm because it’s easier to load the Microsoft.SharePoint.PowerShell snap-in on the web servers than on servers that don’t have SharePoint Server 2013 installed.

To install the online service management tools and configure the Windows PowerShell window:

  1. Install the online service management tools.

    1. Install the Microsoft Online Services Sign-In Assistant.

      Microsoft Online Services Sign-In Assistant for IT Professionals BETA (64 bit version) (http://go.microsoft.com/fwlink/?LinkId=391943)

      For additional, see Microsoft Online Services Sign-In Assistant for IT Professionals RTW (http://go.microsoft.com/fwlink/?LinkId=392322).

    2. Install the Azure Active Directory Module for Windows PowerShell

      Windows Azure Active Directory Module for Windows PowerShell (64 bit version) (http://go.microsoft.com/fwlink/p/?linkid=236297)

      For additional information about Azure Active Directory Module for Windows PowerShell 3.0, see Manage Windows Azure Active Directory by using Windows PowerShell (http://aka.ms/aadposh).

    3. Install the SharePoint Online Management Shell

      SharePoint Online Management Shell (64 bit version) (http://go.microsoft.com/fwlink/?LinkId=392323)

      For additional information, see Introduction to the SharePoint Online management shell (http://go.microsoft.com/fwlink/?LinkId=392324).

  2. Open a Windows PowerShell window.

  3. To ensure that you don’t fill the buffer and lose any of your command history, increase the buffer size of the Windows PowerShell window.

    1. Click on the upper left-hand corner of the Windows PowerShell window, and then click Properties.

    2. In the Windows PowerShell Properties window, click the Layout tab.

    3. Under Screen Buffer Size, set the Height field to 9999 and then click OK.

  4. This step loads the modules you’ve downloaded so you can use them in your Windows PowerShell session. Copy the following commands into your Windows PowerShell session and press Enter.

    Add-PSSnapin Microsoft.SharePoint.PowerShell
    Import-Module Microsoft.PowerShell.Utility
    Import-Module MSOnline -force
    Import-Module MSOnlineExtended -force
    Import-Module Microsoft.Online.SharePoint.PowerShell -force
    

    If you need to run any of the configuration steps again later, remember to run these commands again to load the required modules and snap-ins in Windows PowerShell.

  5. Configure remoting in Windows PowerShell.

    From the Windows PowerShell command prompt, type the following commands:

    enable-psremoting
    new-pssession
    

    For more information, see about_Remote_Requirements (http://go.microsoft.com/fwlink/?LinkId=392326).

  6. To log in to your SharePoint Online tenant, from the Windows PowerShell command prompt, type the following commands:

    $cred=Get-Credential
    Connect-MsolService -Credential $cred
    

    You’ll be prompted to log in. You need to log in using an Office 365 global administrator account.

     

    Edit icon

    The global administrator account that you specified during planning should be recorded in the Global Administrator row of Table 1 of worksheet.

    Leave the Windows PowerShell window open. You'll need it for the next steps in this process.

Now that you’ve installed the tools to enable you to remotely administer Azure AD and SharePoint Online, you’re ready to set-up server-to-server authentication.

This section describes the variables you will set in the procedure that follow. These variables contain important information used in many of the remaining configuration steps.

 

Variable

Comments

$spcn

The root domain name of your public domain. This value should not be in the form of a URL; it should be the domain name only, with no protocol.

This variable is listed in the Public Internet Domain name row of table 3 of the worksheet.

e.g. adventureworks.com

$spsite

The internal URL of your on-premises primary web application, such as http://sharepoint or https://sharepoint.adventureworks.com. This value is a full URL using the proper protocol (either http:// or https://).

This is the internal URL of the web application that you are using for hybrid functionality.

  • If you configured a one-way inbound or two-way authentication topology, this variable is listed on the Primary web application URL row of either table 5a, 5b, or 5c depending on the site collection strategy you configured.

  • If you configured a one-way outbound authentication topology only, use the internal URL of the web application on the on-premises SharePoint farm that you are using for hybrid functionality.

e.g. http://sharepoint or https://sharepoint.adventureworks.com

$site

The object of your on-premises primary web application. The command that populates this variable gets the object of the site you specified in the $spsite variable.

This variable is automatically populated.

$spoappid

The SharePoint Online application principal ID is always 00000003-0000-0ff1-ce00-000000000000. This generic value identifies SharePoint Online objects in a Office 365 tenant.

$spocontextID

The context ID (ObjectID) of your SharePoint Online tenant. This value is a unique GUID that identifies your SharePoint Online tenant.

This value is automatically detected when you run the command to set the variable.

$metadataEndpoint

The URL that is used by your Azure AD proxy to connect to your Azure AD tenancy.

You don't need to input a value for this variable.

Now that you’ve identified the variables that you need to set, use these instructions to set them. Pre-populating the most commonly used variables should help you tackle the remaining steps faster. These variables will remain populated as long as you don’t close the Windows PowerShell session. Be careful to provide accurate information wherever you see angle brackets (< >), and always remove the angle brackets before you run the command. Don’t alter the code outside of the angle brackets.

NoteNote:
If you have to do any of these configuration steps again later, you should begin by running the following Windows PowerShell commands in this step to repopulate the important variables.

Copy the following variable declarations and paste them into a text editor like Notepad. Set input values specific to your organization. From the Windows PowerShell command prompt you configured with the online service management tools, run the commands:

$spcn="*.<public_root_domain_name>.com"
$spsite=Get-Spsite <principal_web_application_URL>
$site=Get-Spsite $spsite
$spoappid="00000003-0000-0ff1-ce00-000000000000"
$spocontextID = (Get-MsolCompanyInformation).ObjectID
$metadataEndpoint = "https://accounts.accesscontrol.windows.net/" + $spocontextID + "/metadata/json/1"

After you populate these variables, you can view their values by simply entering the variable name in the Windows PowerShell window. For example, entering $metadataEndpoint will return a value similar to the following:

https://accounts.accesscontrol.windows.net/00fceb75-246c-4ac4-a0ad-7124xxxxxxxx/metadata/json/1

In this step, you will upload the new STS certificate to your SharePoint Online tenant, which enables SharePoint Server 2013 and SharePoint Online to connect to and consume each other’s service applications.

This figure illustrates the architecture involved when a STS certificate is uploaded to SharePoint Online

The commands in this step add the new on-premises STS certificate and private key to the SharePoint Online principal object of your Office 365 tenancy.

NoteNote:
These steps use the STS certificate files in both the .pfx and .cer format.

 

Edit icon

The variables that you need to provide in the following Windows PowerShell script is listed in these rows of Table 4a of the worksheet:

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

  • STS Certificate Start Date

  • STS Certificate End Date

Copy the following variable declarations and paste them into a text editor like Notepad. Set input values specific to your organization, and from the Windows PowerShell command prompt, type the following commands:

$cerPath = "<path to replacement certificate (.cer file)>"
$cer = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 -ArgumentList $pfxPath, $pfxPass
$cer.Import($cerPath)
$binCert = $cer.GetRawCertData()
$credValue = [System.Convert]::ToBase64String($binCert);
New-MsolServicePrincipalCredential -AppPrincipalId $spoappid -Type asymmetric -Usage Verify -Value $credValue -StartDate <start_date> -EndDate <end_date>
ImportantImportant:
Type values for <start_date> and <end_date> in the format 00/00/0000 (month/day/year). The <start_date> value should be the current date, and the <end_date> value should be the STS certificate expiration date, unless you are using a trial of Office 365.
If you’re using a trial Office 365 subscription, the <end_date> must be a date prior to the trial subscription's expiration date, or the command will fail. For example, if today's date is March 21, 2013, and your Office 365 trial subscription expires on April 19, 2013, the final command would be the following:
New-MsolServicePrincipalCredential -AppPrincipalId $spoappid -Type asymmetric -Usage Verify -Value $credValue -StartDate 03/21/2013 -EndDate 04/18/2013

The next step is to add a service principal name (SPN) to your Azure AD tenant. The SPN is comprised of the SharePoint Online principal object and your company’s public DNS namespace.

Just like SPNs function in Active Directory, creating this SPN registers an object in Azure AD that is used to support mutual authentication between SharePoint Server 2013 and your SharePoint Online tenant. The basic syntax is:

<service type>/<instance name>

Where <service type> is the SharePoint Online principal object (which is the same for all SharePoint Online tenants), and <instance name> is the URL of your company’s public DNS domain namespace, which is always expressed as a wildcard, (even if the Secure Channel SSL Certificate is a SAN certificate) like in this example:

00000003-0000-0ff1-ce00-000000000000/*.<public domain name>.com

Using a wildcard value for your public root domain name lets SharePoint Online validate connections with any host in that domain. This is useful if you ever need to change the host name of your external endpoint (if your topology includes one), or your SharePoint Server 2013 web application, in the future.

To add the SPN to Azure AD, from the Windows PowerShell command prompt, type the following commands:

$msp = Get-MsolServicePrincipal -AppPrincipalId $spoappid
$spns = $msp.ServicePrincipalNames
$spns.Add("$spoappid/$spcn") 
Set-MsolServicePrincipal -AppPrincipalId $spoappid -ServicePrincipalNames $spns

To validate, from the Windows PowerShell command prompt, type the following commands:

$msp = Get-MsolServicePrincipal -AppPrincipalId $spoappid
$spns = $msp.ServicePrincipalNames 
$spns

You should see a current list of SPNs for SharePoint Online in your Office 365 tenancy, and one of the SPNs listed should include your public root domain name, prefaced by the SharePoint Online application principal ID. This registration is a wildcard registration, and should look like the following example:

00000003-0000-0ff1-ce00-000000000000/*.<public domain name>.com

This should be the only SPN in the list that includes your public root domain name.

This step registers the SharePoint Online application principal object ID with the on-premises SharePoint Application Management Service, which allows SharePoint Server 2013 to authenticate to SharePoint Online using OAuth.

From the Windows PowerShell command prompt, type the following commands:

$spoappprincipalID = (Get-MsolServicePrincipal -ServicePrincipalName $spoappid).ObjectID
$sponameidentifier = "$spoappprincipalID@$spocontextID"
$appPrincipal = Register-SPAppPrincipal -site $site.rootweb -nameIdentifier $sponameidentifier -displayName "SharePoint Online"

To validate this step, from the Windows PowerShell command prompt, type the following command:

Get-SPAppPrincipal -site $site.rootweb -NameIdentifier $sponameidentifier | format-table -autosize -wrap

The expected output is a description of the registered application principal with the name SharePoint Online, which will look something like this:

This figure illustrates the registered application principal for SharePoint Online

This step sets the authentication realm of your SharePoint Server 2013 farm to the context ID of the organization’s Office 365 tenancy.

From the Windows PowerShell command prompt, type the following command:

Set-SPAuthenticationRealm -realm $spocontextID

To validate this step, from the Windows PowerShell command prompt, type the following commands:

$spocontextID
 Get-SPAuthenticationRealm

The output of each of these commands is the GUID that represents the context ID of the SharePoint Online tenancy. These GUIDs should be identical.

ImportantImportant:
If you have configured farm setup scripts that specify the farm authentication realm value, you should update the setup scripts with this new value before you run them again.
For more information about the requirements for realm values in farm setup scripts, see Plan for server-to-server authentication in SharePoint 2013. Because you have now configured this SharePoint farm to participate in the hybrid configuration, the SharePoint farm authentication realm value must always match the tenant context identifier. If you change this value, the farm will no longer participate in hybrid functionality.

In this step, you create a Azure AD proxy service in the SharePoint Server 2013 farm. This enables Azure AD as a trusted token issuer that SharePoint Server 2013 will use to sign and authenticate claims tokens from SharePoint Online.

From the Windows PowerShell command prompt, type the following commands:

New-SPAzureAccessControlServiceApplicationProxy -Name "ACS" -MetadataServiceEndpointUri $metadataEndpoint -DefaultProxyGroup
New-SPTrustedSecurityTokenIssuer -MetadataEndpoint $metadataEndpoint -IsTrustBroker:$true -Name "ACS"

To validate the New-SPAzureAccessControlServiceApplicationProxy command:

  1. Browse the SharePoint 2013 Central Administration website and click Security> General Security > Manage trust.

  2. Make sure you have an entry with a name that begins with ACS and the type Trusted Service Consumer.

To validate this step, from the Windows PowerShell command prompt, type the following command:

Get-SPTrustedSecurityTokenIssuer

The output that's expected is a description of the farm's trusted token issuer where the value of the RegisteredIssuerName property is the following:

00000001-0000-0000-c000-000000000000@<context ID>

Where <context ID> is the context ID of your SharePoint Online tenancy, which is the value that you declared in the $spocontextID variable.

After finishing the tasks in this topic and its validation steps, you should confirm a few final things:

  • Check your SSO, and Directory Synchronization setup by using validation steps in the Validate your SSO configuration.

  • Make sure the STS Service in your on-premises SharePoint Server 2013 farm is working. (For example, verify that you can browse your sites and access files and folders without errors.)

    You can manually check the STS certificate on each farm server:

    1. Log on to the server using a farm administrator account.

    2. From the Windows PowerShell command prompt, type the following command:

      Get-ChildItem cert:\LocalMachine\Sharepoint |fl

    3. Make sure you see a certificate that matches the subject and friendly name of your replacement STS certificate.

So that you have a history of the steps you’ve taken, you should capture the entire contents of the Windows PowerShell buffer into a file. This will be crucial if you need to reference your configuration history to troubleshoot, or for any other reasons. This will also help you pick up where you left off if the configuration spans multiple days or involves multiple people.

After you have completed and validated the configuration tasks in this topic, your environment is ready for Phase 4 of the hybrid configuration process, in which you configure specific solutions for your hybrid deployment. To proceed to Phase 4, see Configure a hybrid solution for SharePoint Server 2013.

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.