Coming Soon: GET:IT Endpoint Management 1-Day Conference on September 28th at 9:30 AM ET Coming Soon: GET:IT Endpoint Management 1-Day Conference on September 28th at 9:30 AM ET
SharePoint

Configure a Trust Relationship Between Two SharePoint 2013 Farms

If you have the resources available, it is a great idea to have multiple SharePoint environments. Using one environment for your production web applications, and having a different farm for your test and development web applications can really help to keep the work items that are being developed in the test farm from messing up what is already working in the prod farm.

But just because you have two separate farms doesn’t mean that you have to do everything twice. You can take advantage of publishing service applications from one farm and subscribing to them in another farm. By doing this, you can have only one instance of search, or only one instance of a user profile service, and both farms can use them.

However, before you can publish any service applications and get them presented in a different farm, there are some prerequisites that have to be done. This article shows you how to create trusts between two SharePoint 2013 farms so that the publishing and subscribing to service applications is possible.

Why Create Trusts Between SharePoint Farms?

When you’ve got multiple farms, it can be tempting to just take the fast route and create a User Profile Service for each farm. The problem is that when your users are using a site in the test farm, they will have a completely separate user profile. The sites they’ve followed won’t be in their “Sites,” and their files won’t be in the “SkyDrive Pro” section of their profile. Even worse, when they choose to follow a site in the test farm, only the profile that they see when they’re using the test farm site will show the site that they just followed.

Sponsored Content

Say Goodbye to Traditional PC Lifecycle Management

Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.

There’s something to be said for having a total separation between the farms. But if you want a more consistent experience for you users, it’s really not too hard to share the service applications between the farms.

Once shared, your documents in your SkyDrive Pro are available to you no matter which farm you’re currently logged into, and you can follow sites in either your test or your prod farm, and quickly get back to all of them no matter what farm you’re currently in.

Getting the service applications shared from your prod farm to your test farm is impossible without the farms first trusting each other. These trusts can be done through PowerShell or Central Administration, but I think it’s easier to do it with PowerShell so I’ll talk you through those steps now.

Setup SharePoint 2013 Servers for Remote PowerShell Connections

First, go to the server in the test farm either through a remote session or by remote desktop services. If you haven’t enabled your SharePoint servers to use CredSSP, you need to enable CredSSP on each SharePoint server you’re going to remotely connect to before you can successfully administer SharePoint from a remote PowerShell connection on your workstation.

On each of your SharePoint servers, run this command from an elevated PowerShell session:

Enable-CredSSP –Role Server

And then, on your workstation, run this in an elevated PowerShell session:

Enable-CredSSP –Role Client

We’re that now configured we can create the remote connections from our workstation. Use the credential for a farm administrator for creating the remote sessions.

​ $Credential = Get-Credential (DOMAIN\SPSetup)

$TEST = New-PSSession –Computername <TESTServer> -Authentication CredSSP –Credential $Credential

$PROD = New-PSSession –Computername <PRODServer> -Authentication CredSSP –Credential $Credential

Export the Certificates From Each Farm

Next, we need to export the certificates from each farm and move them into the other farm.

Each farm will have a root certificate, which is used to verify the identity of the farm itself. Additionally, the test farm, which will be the consumer of the services, will also export a Security Token Signing certificate, so that the production farm can verify that the sessions of the users are valid.

As you may suspect, the certificates that are exported don’t have to go directly to the other server. If you have a network share, you can export to and import from the network location.

​ Invoke-Command –Session $TEST –Scriptblock {
$RootCert = (Get-SPCertificateAuthority).RootCertificate
$RootCert.Export(“Cert”) | Set-Content C:\TEMP\TestFarmRoot.cer –Encoding byte
$STSCert = (Get-SPSecurityTokenServiceConfig).LocalLoginProvider.SigningCertificate
$STSCert.Export(“Cert”) | Set-Content C:\TEMP\TestFarmSts.cer –Encoding byte
Copy-Item C:\TEMP\TestFarm*.cer –Destination ‘\\<PRODServer>\C$\Temp’
}
Invoke-Command –Session $PROD –Scriptblock {
$RootCert = (Get-SPCertificateAuthority).RootCertificate
$RootCert.Export(“Cert”) | Set-Content C:\TEMP\ProdFarmRoot.cer –Encoding byte
Copy-Item C:\Cert\ProdFarm*.cer –Destination ‘\\<TESTServer>\C$\Temp’
}

Now that we have the certificates off of each farm and staged them where the other farm can easily get to them, we can create the trusts.

How to Create a Farm Trust in SharePoint 2013

This can also be done within Central Administration, but PowerShell really takes a lot of clicking out of the process.

Creating the trusts is done with using the New-SPTrustedRootAuthority cmdlet (for the farm trusts) and the New-SPTrustedServiceTokenIssuer (for the Secure Token Service trust).

We’ll need to create the trust in both farms for the Root certificates, and only in the prod farm for the Secure Token Service. This is because the users will be coming from the test farm, and that’s where their security tokens will be created and assigned. Those tokens must be trusted by the production farm for those users to be granted permission to use the service applications.

 

​ Invoke-Command –Session $TEST –Scriptblock {
$ProdRootCert = Get-PfxCertificate C:\TEMP\ProdFarmRoot.cer
New-SPTrustedRootAuthority PROD –Certificate $ProdRootCert
}

Invoke-Command –Session $PROD –Scriptblock {
$TestRootCert = Get-PfxCertificate C:\TEMP\TestFarmRoot.cer
$TestStsCert = Get-PfxCertificate C:\TEMP\TestFarmSts.cer
New-SPTrustedRootAuthority TEST -Certificate $TestRootCert
New-SPTrustedServiceTokenIssuer TEST -Certificate $TestStsCert
}

Configure a Trust Relationship SharePoint 2013 Farms

Trust Is an Important Thing

Trust is an important thing in a relationship between two SharePoint 2013 farms. Now that the trusts are in place, each server knows that when a connection is made to a server in another farm, that the server has a certificate present that proves it’s who it says it is. Additionally, the users that are in the TEST farm are issued a token that has been signed, and are now trusted by the services in the PROD farm.

The actual configuration for the publishing and subscribing to the Service Applications still has to be done. That part is not very difficult, and PowerShell will help a lot in that configuration as well.

Related Topics:

BECOME A PETRI MEMBER:

Don't have a login but want to join the conversation? Sign up for a Petri Account

Register
Comments (1)

One response to “Configure a Trust Relationship Between Two SharePoint 2013 Farms”

Leave a Reply

Live Webinar: Active Directory Security: What Needs Immediate Priority!Live on Tuesday, October 12th at 1 PM ET

Attacks on Active Directory are at an all-time high. Companies that are not taking heed are being punished, both monetarily and with loss of production.

In this webinar, you will learn:

  • How to prioritize vulnerability management
  • What attackers are leveraging to breach organizations
  • Where Active Directory security needs immediate attention
  • Overall strategy to secure your environment and keep it secured

Sponsored by: