Wednesday, 29 April 2015

Publish and consume SharePoint Service applications

SharePoint 2013 some service applications can be shared across the server farms. We can publish the following service applications in a SP 2013 farm,

· Business Data Connectivity

· Machine Translation

· Managed Metadata

· User Profile

· Search

· Secure Store

The farm that contains the service application and publishes the service application so that other farms can consume the service application is known as the Publishing farm. The farm that connects to a remote location to use a service application that the remote location is hosting is known as the Consuming farm.
Following steps are required and must be performed in the order listed to publish and consume the service applications,

1. Exchange trust certificates between the farms.

2. Publish the service application on the publishing farm.

3. Set the permission to the appropriate service applications.

4. Connect to the remote service application on the consuming farm.

5. Add the shared service application to a web application group on the consuming farm.

6. Configure server-to-server authentication between the publishing and consuming farm.

Exchange trust certificates between farms

Administrator of the Consuming farm must provide two trust certificates to the administrator of the Publishing farm,

1. Root certificate (Consuming farm à Publishing farm)

2. Security token service certificate(STS) (Consuming farm à Publishing farm)

Administrator of the Publishing farm must provide a root certificate to the administrator of the consuming farm.

3. Root certificate (Publishing farm à Consuming farm)

By exchanging certificates, each farm acknowledges that other farm can be trusted.

1.1 To export the root certificate from the consuming farm

Start à All Programs à Microsoft SharePoint 2013 Products à SharePoint 2013 Management Shell

$rootCert = (Get-SPCertificateAuthority).RootCertificate

$rootCert.Export("Cert") | Set-Content <C:\ConsumingFarmRoot.cer> -Encoding byte

<C:\ConsumingFarmRoot.cer> is the path of the root certificate.

1.2 To export the STS certificate from the consuming farm

Start à All Programs à Microsoft SharePoint 2013 Products à SharePoint 2013 Management Shell

$stsCert = (Get-SPSecurityTokenServiceConfig).LocalLoginProvider.SigningCertificate

$stsCert.Export("Cert") | Set-Content <C:\ConsumingFarmSTS.cer> -Encoding byte

<C:\ConsumingFarmSTS.cer> is the path of the STS certificate

1.3 To export the root certificate from the publishing farm

Start à All Programs à Microsoft SharePoint 2013 Products à SharePoint 2013 Management Shell

$rootCert = (Get-SPCertificateAuthority).RootCertificate

$rootCert.Export("Cert") | Set-Content <C:\PublishingFarmRoot.cer> -Encoding byte

<C:\PublishingFarmRoot.cer> is the path of the root certificate.

1.4 Copy the certificates

Copy the root certificate and the STS certificate from the server in the consuming farm to the server in the publishing farm.
Copy the root certificate from the server in the publishing farm to a server in the consuming farm.

1.5 Establishing trust on the consuming farm

To import the root certificate and create a trusted root authority on the consuming farm,

Start à All Programs à Microsoft SharePoint 2013 Products à SharePoint 2013 Management Shell

$trustCert = Get-PfxCertificate <C:\PublishingFarmRoot.cer>

$trustCert = Get-PfxCertificate .\HOT_Q_F06_PublishingFarmRoot.cer

New-SPTrustedRootAuthority Publishing Farm_HOT_Q_F06 -Certificate $trustCert

<C:\PublishingFarmRoot.cer> is the path of the root certificate that you copied to the consuming farm from the publishing farm.
<PublishingFarm> is a unique name that identifies the publishing farm. Each trusted root authority must have a unique name. Ex: WFEFarm1

1.5 Establishing trust on the publishing farm

To import the root certificate and create a trusted root authority on the publishing farm,

Start à All Programs à Microsoft SharePoint 2013 Products à SharePoint 2013 Management Shell

$trustCert = Get-PfxCertificate <C:\ConsumingFarmRoot.cer>

$trustCert = Get-PfxCertificate .\HOT_Q_F08_ConsumingFarmRoot.cer

New-SPTrustedRootAuthority ConsumingFarm_HOT_Q_F08 -Certificate $trustCert

<C:\ConsumingFarmRoot.cer> is the name and location of the root certificate that you copied to the publishing farm from the consuming farm.
<ConsumingFarm> is a unique name that identifies the consuming farm. Each trusted root authority must have a unique name.

To import the STS certificate and create a trusted service token issuer on the publishing farm,

$stsCert = Get-PfxCertificate <c:\ConsumingFarmSTS.cer>

$stsCert = Get-PfxCertificate .\HOT_Q_F08_ConsumingFarmSTS.cer

New-SPTrustedServiceTokenIssuer ConsumingFarm_HOT_Q_F08 -Certificate $stsCert

<C:\ConsumingFarmSTS.cer> is the path of the STS certificate that you copied to the publishing farm from the consuming farm.
<ConsumingFarm> is a unique name that identifies the consuming farm. Each trusted service token issuer must have a unique name.

1.6 Managing trust certificates by using Central Administration (Optional)

We can manage trusts on a farm only after the relevant certificates have already been exported and copied to the farm. Following steps must be performed on Publishing and consuming farm,

Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group.
Central Administration à Security à General Security à Manage trust à New
On the Establish Trust Relationship page,

a. Supply a name that describes the purpose of the trust relationship.

b. Browse to and select the Root Authority Certificate for the trust relationship. This must be the Root Authority Certificate that was exported from the other farm by using PowerShell.

c. Only on Publishing Farm: Select the check box for ‘Provide Trust Relationship’. Type in a descriptive name for the token issuer and browse to and select the STS certificate that was copied from the consuming farm. Click Ok.

Publish service application

On the farm on which the service application is located, an administrator must explicitly publish the service application. Service applications that are not explicitly published are available to the local farm only.

To publish a service application by using Central Administration,

Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group.
Central Administration à Application Management à Manage service applications.
Choose the service application want to publish. On the Ribbon, Click Publish.
In the Publish Service Application dialog box:

a. Select the Connection Type that we want from the drop-down list.

http

b. If we want the service application to be available to remote farms, select the check box for Publish this Service Application to other farms.

checked

c. We have already established trust between the farms. So we can check and see trust establishment by clicking the link Click here to add a trust relationship with another farm.

d. Copy the Published URL into Notepad or another text editor. We must provide this URL to remote farms to connect the remote farms to the published service application. The URL will be similar to the following:

urn:schemas-microsoft-com:sharepoint:service:0d755965a89a43bfa93ad5d4b2e3f616#authority=urn:uuid:fa85d318d294438a83116e8c0b24ade6&authority=https://defnsvxxx:32844/Topology/topology.svc

To publish a service application by using PowerShell(optional),

Start à All Programs à Microsoft SharePoint 2013 Products à SharePoint 2013 Management Shell

Publish-SPServiceApplication -Identity <ServiceApplicationGUID>

<ServiceApplicationGUID> GUID of the service application

To get the GUID of the service application Run the following command,

Get-SPServiceApplication

To view the published service application load balancer URL, type the following command and record the output. Any connecting remote farms will need the information that is generated by this command.

Get-SPTopologyServiceApplication

Set Permission to Published service application

We must give the consuming farm permission to the Application Discovery and Load Balancing Service Application on the publishing farm. After doing this, give the consuming farm permission to the published service applications that it will be consuming.

We must establish a relationship between the publishing farm and the consuming farm by giving the consuming farm permission to the Application Discovery and Load Balancing Service Application first and other published service applications on the publishing farm.

Set the permission to the Application Discovery and Load Balancing Service Application
Set the permission to other published service applications.

On a server in the consuming farm to get the Consuming farm ID,

Start à All Programs à Microsoft SharePoint 2013 Products à SharePoint 2013 Management Shell

Get-SPFarm | Select Id

9da7ccab-2c24-4d50-abd4-9ce95784ce91

Returns GUID value of the consuming farm

To set permission to the Application Discovery and Load Balancing Service Application on the publishing farm by using PowerShell,
Run on the following commands on server in the publishing farm for giving the consuming farm permission to the Application Discovery and Load Balancing Service Application,

$security=Get-SPTopologyServiceApplication | Get-SPServiceApplicationSecurity

$claimprovider=(Get-SPClaimProvider System).ClaimProvider

$principal=New-SPClaimsPrincipal -ClaimType "http://schemas.microsoft.com/sharepoint/2009/08/claims/farmid" -ClaimProvider $claimprovider -ClaimValue 9da7ccab-2c24-4d50-abd4-9ce95784ce91

Grant-SPObjectSecurity -Identity $security -Principal $principal -Rights "Full Control"

Get-SPTopologyServiceApplication | Set-SPServiceApplicationSecurity -ObjectSecurity $security

Consumingfarmid is the GUID value of the consuming farm

To set permission to other published Service Applications on the publishing farm by using PowerShell,
Run on the following commands on server in the publishing farm for giving the consuming farm permission to the Application Discovery and Load Balancing Service Application,

Get-SPServiceApplication –id fa85d318-d294-438a-8311-6e8c0b24ade6

$security=Get-SPServiceApplication fa85d318-d294-438a-8311-6e8c0b24ade6 | Get-SPServiceApplicationSecurity

$claimprovider=(Get-SPClaimProvider System).ClaimProvider

$principal=New-SPClaimsPrincipal -ClaimType "http://schemas.microsoft.com/sharepoint/2009/08/claims/farmid" -ClaimProvider $claimprovider -ClaimValue 9da7ccab-2c24-4d50-abd4-9ce95784ce91

Grant-SPObjectSecurity -Identity $security -Principal $principal -Rights "Full Control"

Set-SPServiceApplicationSecurity fa85d318-d294-438a-8311-6e8c0b24ade6 -ObjectSecurity $security

<ServiceApplicationName> is the name of the service application for which you want to find the ID. If the service application name contains spaces, enclose the value in double-quotation marks.
<Consumingfarmid> is the GUID value of the consuming farm
<GUID> is the ID of the published service application.

To set permission to the Application Discovery and Load Balancing Service Application and any other published service application for a consuming farm by using Central Administration (optional)

1. On publishing farmà SharePoint Central Administration website à verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group.

2. Navigate Application Management à Manage service applications à Application Discovery and Load Balancing Service Application.

3. On the ribbon, click Permissions

On a server in the consuming farm to get the Consuming farm ID,

Start à All Programs à Microsoft SharePoint 2013 Products à SharePoint 2013 Management Shell

Get-SPFarm | Select Id

Returns GUID value of the consuming farm

4. In the Connection Permissions dialog box,

a. Manually paste the ID of the consuming farm from the PowerShell section à Click Add

b. Select the consuming farm ID, and then select the Full Control check box. à Click OK

5. Repeat steps 2 through 4 for any published service applications for which you want to enable access from the consuming farm and assign the necessary permission.

Connect to service applications on Remote farms

After the publishing farm has published the service application, an administrator of the consuming farm can connect to that service application from the consuming farm if the address of the specific service application is known.
To connect to a service application on a remote farm by using Central Administration

1. Verify that you are a member of the Farm Administrators SharePoint group

2. On a server in the Consuming farm, SharePoint Central Administration à Application Management à Manage service applications.

3. On ribbon, click Connect

4. On the Connect drop-down menu, click the kind of service application to which you want to connect.

5. On the Connect to a Remote Service Application page, type the appropriate URL in the Farm or Service Application address text box, and then click OK

urn:schemas-microsoft-com:sharepoint:service:0d755965a89a43bfa93ad5d4b2e3f616#authority=urn:uuid:fa85d318d294438a83116e8c0b24ade6&authority=https://defnsvxxxx:32844/Topology/topology.svc

6. On the Connect to a Remote Service Application page, type the appropriate URL in the Farm or Service Application address text box, and then click OK

7. The new Connect to a Remote Service Application dialog box displays the service applications that match the URL that you typed in Step 5. Click the row that contains the name of the service application, and then select the check box to add the service application connection to the farm’s default list of service application connections (that is, the default proxy group). Click OK.

8. We are prompted to change the connection name. Type a new name into the Connection Name text box or leave the default name, and then click OK

9. After the new connection is created, we must click OK to complete the procedure.

10. Associate the new service application connection with a local Web application.

To connect to a service application on a remote farm by using PowerShell(optional)

Start à All Programs à Microsoft SharePoint 2013 Products à SharePoint 2013 Management Shell

To get the PublishingFarmTopologyURL,

Receive-SPServiceApplicationConnectionInfo -FarmUrl <PublishingFarmTopologyURL>

<PublishingFarmTopologyURL> is the information that is retrieved by running the Get-SPTopologyServiceApplication cmdlet on the publishing farm below,

New-SP*ServiceApplicationProxy -Name " <ServiceApplicationProxyName>" -Url "<PublishingFarmTopologyURL>"

<ServiceApplicationProxyName> is a unique name for a service application connection on the consuming farm.
<PublishingFarmTopologyURL> is the service application topology URL that was also used in the previous command.

Example: Following command creates a new Managed Metadata service application proxy named "MetadataServiceProxy1" that connects to the service application located at the stated URL.

Example:

New-SPMetadataServiceApplicationProxy -Name "MetadataServiceProxy1" -Uri "

urn:schemas-microsoft-com:sharepoint:service:9c1870b7ee97445888d9e846519cfa27#authority=urn:uuid:02a493b92a5547828e21386e28056cba&authority=https://ua_powershell:32844/Topology/topology.svc "

Add or remove service application connections from a web application

An administrator must associate the new service application connection with a local Web application on the consuming farm. Only Web applications that are configured to use this association can use the remote service application.

To edit a service connection group by using Central Administration,

Central Administration à Application Management à Service Applications à Configure service application associations
On the Service Application Associations page, select Web Applications from the View drop-down menu.
In the list of Web applications, in the Application Proxy Group column, click the name of the service application connection group that we want to change
To add a service connection to the group, select the check box that is next to the service application that you want to add to the connection group.
click OK

To add a service application connection to a service application connection group by using PowerShell (optional)

$serviceAppProxy = Get-SPServiceApplicationProxy | where { $_.Name -eq "Name of the service" }

$proxygroup = Get-SPServiceApplicationProxyGroup | where { $_.FriendlyName -eq "[default]" }

Add-SPServiceApplicationProxyGroupMember -Identity $proxygroup -Member $serviceAppProxy

Configure permissions for Default Content Access Account

Configure server-to-server authentication between publishing and consuming farms

To enable the webapplication or application service to request the resource from another farm on behalf of the user we must configure server–to– server authentication between Publishing and consuming farms.

To configure server-to-server authentication between publishing and consuming farms,

Choose a realm name that will be common to both farms. here realm name is “8db904b3-e2c7-4a9d-9541-0bc8cf08f4e1”

http://xxxx//_layouts/15/metadata/json/1

{"issuer":"00000003-0000-0ff1-ce00-000000000000@8db904b3-e2c7-4a9d-9541-0bc8cf08f4e1","keys":[{"keyValue":{"type":"x509certificate","value":"MIIERjCCAi6gAwIBAgIQIdHVI+cIIrxOnWodfIrxqzANBgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MRMwEQYDVQQLEwpTaGFyZVBvaW50MSIwIAYDVQQDExlTaGFyZVBvaW50IFJvb3QgQXV0aG9yaXR5MCAXDTEzMDcwODEyMDY1NFoYDzk5OTkwMTAxMDAwMDAwWjBiMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MRMwEQYDVQQLEwpTaGFyZVBvaW50MSowKAYDVQQDEyFTaGFyZVBvaW50IFNlY3VyaXR5IFRva2VuIFNlcnZpY2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCqiHE6hF5261XDqIPsWtDgSaU9lQOyRUH0TbYndF5Vn6dhhY1iv1U2wNEIMAA4IBDwAwggEKAoIBAQCqiHE6hF5261XDqIPsWtDgSaU9lQOyRUH0TbYndF5Vn6dhhY1iv1U2wNEIM4kE9bX1GuAC4EUEiIoMLFKt9VKgILcQFnyJId4dlGwhGqzUqj2865AAMfT06lixgyQPvZuHBTWOM3BI5FOdzWEXRvTC44N5Qpkpq3K1UusfMk1rSjCXFY1l15dp72Rm3fc1\/2dNJES+Nxo78TIXqr2r1op1I4jJtwbswjiQu7fCg66P3TPMSTFdCQs5Iac2bFan3LJcI6y0RQ7n92mR2tfo0Uj\/7EtSQDi92HaI+Ucf98Az2hOW85Fs1X8eU35Q38TRm3FcrCA5+NucQm7h5QXDF9hxAgMBAAEwDQYJKoZIhvcNAQEFBQADggIBAB\/zFC02H5xEXRPFinh7KtXXqJShFl836+COYnLFrDvcGnu22GC8w4kjeUpyfXzc4J4KZDolkGgNFklqFkj1vYMTForbClV\/XueBiCj2G5az9vtaSCfl3rlyjz\/XQ+sjFQcsu9tDJDMLc0hiebW+ZWxdjbt5PBaBgJEwgckp8hwVxxVy9xzK1QRZfGk8hvzLOPmBfeH0ENAaC1tdri2gojwn8ubcWZv\/QV9eld27sJJFRjQgINHotA0FrV2Ad1Hh8Qi3HDdvW3Da5xaD2MsqjjXFg\/mLT4iC+2GmX\/u1TLvkU1BuZVpSzMYxHMk7Xw6OFPmufgNh14SNIVLEj5S9HtWdQIGgWymO6heWaaZ\/SLyqA5sMO1NklUXfXKMyd2mzQpKgxbbrbAD80P7Hj6LArt+vr6T7WGFAd35Ku09efFo5vak6Ey6eRFU+RFbkWTot01W7vwWdvexlv7lxzMD0y8EYzHmkQWISh1a4xOYvlVuaD502jath2Y0Juj8vl7BxmuqpASczM6sE5cgG3zGogddNeN2Ts3WZYWrD4koXp4\/jSaeAyqz91NzgoE2f\/mFLGXcQB1CgQNowdpSOJ32t85UFJmSO6vgJ3\/xHS0Ug0hybh2CRYXeZ\/fm1955iBzFEb3wBMxF3NTFnxRBNk2tNyZ9TU4sWq29rKqBEXXU8H5pU"},"usage":"Signing"}],"name":"00000003-0000-0ff1-ce00-000000000000","serviceName":"00000003-0000-0ff1-ce00-000000000000"}

name identifier for the STS

Realm value

X509 Certificate Value

To configure the Name ID for the SharePoint Security Token Service (STS) on the publishing farm to include the common realm name, type the following commands at the PowerShell command prompt on a server in the publishing farm

$sts=Get-SPSecurityTokenServiceConfig

$Realm=Get-SpAuthenticationRealm

$nameId = "00000003-0000-0ff1-ce00-000000000000@$Realm"

Write-Host "Setting STS NameId to $nameId"

$sts.NameIdentifier = $nameId

$sts.Update()

To configure the Name ID for the SharePoint STS on the consuming farm to include the common realm name, type the following commands at the PowerShell command prompt on a server in the consuming farm:

$sts=Get-SPSecurityTokenServiceConfig

$Realm=Get-SpAuthenticationRealm

$nameId = "00000003-0000-0ff1-ce00-000000000000@$Realm"

Write-Host "Setting STS NameId to $nameId"

$sts.NameIdentifier = $nameId

$sts.Update()

To configure the publishing farm for server-to-server authentication with the consuming farm,

New-SPTrustedSecurityTokenIssuer -MetadataEndpoint "https://<ConsumeHostName>/_layouts/15/metadata/json/1" -Name "<ConsumeFriendlyName>"

<ConsumeHostName> is the name and port of the web application of the consuming farm.
<ConsumeFriendlyName> is a friendly name for the consuming farm.

To configure the consuming farm for server-to-server authentication with the publishing farm,

New-SPTrustedSecurityTokenIssuer -MetadataEndpoint "https://<PublishHostName>/_layouts/15/metadata/json/1" -Name "<PublishFriendlyName>"

<PublishHostName> is the name and port of any SSL-enabled web application of the publishing farm.
<PublishFriendlyName> is a friendly name for the publishing farm.

This creates the server-to-server authentication trust with the publishing farm.

Ref: https://technet.microsoft.com/en-us/library/ff621100.aspx

Tuesday, 21 April 2015

Setting Up an oAuth Trust Between Farms in SharePoint 2013

One of the things you’re likely to hear a lot about in SharePoint 2013, and I may end up writing a lot about, is oAuth. In SharePoint 2013 oAuth is used to establish a trust between two applications for purposes of establishing the identity of a principal (user or application). In SharePoint you will use oAuth trusts between SharePoint and things like Exchange and Lync, with ACS or individual application developers who are using the new cloud app model, or even between two different SharePoint farms for things like the remote SharePoint index feature in Search.
What oAuth does NOT do is become an authentication provider for people; you still will use your New-SPTrustedIdentityTokenIssuer to create those trusts to your identity providers. For oAuth trusts we have a new cmdlet that is very similar in name, and it’s called the New-SPTrustedSecurityTokenIssuer. When we establish this kind of trust with a security token issuer we call it an S2S trust, which means “server to server”. Remember this acronym because you will start seeing it a lot in SharePoint 2013. In this post I’m going to talk through some of the particulars required to create this trust.
First it’s worth pointing out that many features that require an S2S trust will establish this trust themselves. They may do that via feature activation, or feature teams may provide you a PowerShell script or cmdlet to run that creates the trust as part of turning on their feature. There will be times when you need to do it yourself though, and that’s what this post is about.
One of the things you’ll need to resolve first is whether you are going to be using SSL or not. The reality is, that in most cases in SharePoint 2013, you should probably use SSL. The reason I say that is because there are so many scenarios that use oAuth in SharePoint 2013, and when you do you are passing around a cookie with an access token. That access token is like a key that unlocks the door to data. The access token is signed by a certificate so it can’t be spoofed by someone that creates their own access token, but you don’t want it flying around in clear text because in theory someone could grab that cookie and replay it for the duration of the cookie lifetime. SSL protects you from that cookie replay attack, the same way that you would use SSL with a forms based auth site for the same reason. That being said, there are still reasons why you may want to run your sites over HTTP – you’re in a test environment, you’re building out a dev environment, you’re running entirely on an internal network and don’t feel it’s a risk, etc. I’m not here to judge – I’m just here to explain.

STEP 1: Configure the STS
There are a couple of settings in the configuration of SharePoint’s security token service (STS) that you may want to tweak if you are not using SSL. You can get all of the STS configuration settings with this cmdlet: Get-SPSecurityTokenServiceConfig. There are two ways to establish a trust – one is with a certificate and one is using a new oAuth metadata endpoint that all SharePoint farms have. Using the metadata endpoint is the easiest way to go, but if that endpoint is not SSL secured then you need to set the AllowMetadataOverHttp property of the SharePoint STS to true. If you are not going to be running your web apps over SSL, then you will need to set the AllowOAuthOverHttp property to true as well. Here’s a little PowerShell that demonstrates how to set these properties:
$c = Get-SPSecurityTokenServiceConfig
$c.AllowMetadataOverHttp = $true
$c.AllowOAuthOverHttp= $true
$c.Update()

STEP 2: Create the Trust

Once the STS is configured as required, we can look at how to establish the trust from one farm to another. As I mentioned above, all SharePoint farms have a metadata endpoint now that is used to supply information and the access token signing certificate. That metadata endpoint is at /_layouts/15/metadata/json/1. If you actually try to navigate to that in a browser you will be prompted to save it, which you can do to examine it. What you will find if you open it up in notepad is that it is just a JSON payload. It includes the name identifier for the STS (which it calls “issuer”), along with a serialized version of the token signing certificate (which it describes as the “value” for the key “x509certificate”). If you look a little further at the data, you’ll see that the issuer is actually servicename + “@” + realm values. It also matches the NameIdentifier property on the STS; this information is important, for reasons I will explain in a bit.
In this example let’s say that FARM_B needs to trust calls from FARM_A, because FARM_A is going to use FARM_B as a remote SharePoint index. Also, let’s say that FARM_A has a web application at http://FARM_A.   To create the trust we would run the New-SPTrustedSecurityTokenIssuer cmdlet on a server in FARM_B like this (I’ll explain why I’m using the “$i = “ stuff later in the post):
$i = New-SPTrustedSecurityTokenIssuer -Name FARM_A -Description “FARM_A description” -IsTrustBroker:$false -MetadataEndPoint “http://FARM_A/_layouts/15/metadata/json/1″
Now, let’s say that you are setting up a trust with a services only farm. You don’t want to create a web application, site collection and SSL certificate just so you can create a trust from it. So, we have a second method that you can use to establish the trust using the New-SPTrustedSecurityTokenIssuer cmdlet. In the second form you can just provide the token signing certificate and the name identifier. You get the token signing certificate just like you did in SharePoint 2010 – go to a server in the farm, run the MMC, add the Certificates snap-in for the Local Computer, look in the SharePoint…Certificates node, and the first certificate in the list is the one you want – just save it to the local drive without the private key as a .cer file. You need the certificate and the NameIdentifier attribute of the STS that I was describing above in order to establish the trust. The cmdlet in that case looks like this (it assumes you have copied the STS certificate to a file called C:\sts.cer on a server in FARM_B):
$i = New-SPTrustedSecurityTokenIssuer -name FARM_A -Certificate “C:\sts.cer” -RegisteredIssuerName “00000003-0000-0ff1-ce00-000000000000@72da1552-085a-49de-9ecb-73ba7eca8fef ” -Description “FARM_A description” -IsTrustBroker:$false

STEP 3: Trust the Token Signing Certificate

Just like you do with a SPTrustedIdentityTokenIssuer, you need add the trust used to sign oAuth tokens to the list of trusted root authorities in SharePoint. Again, you have two options for doing this: if you create your trust via the metadata endpoint, you can establish the trust like this:
New-SPTrustedRootAuthority -Name FARM_A -MetadataEndPoint http://FARM_A/_layouts/15/metadata/json/1/rootcertificate
Otherwise, you can create add it to the trusted root authority list just like you did in SharePoint 2010:
$root = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“C:\sts.cer”)
New-SPTrustedRootAuthority -Name “Token Signing Root CA Certificate” -Certificate $root
From a trust perspective, you’re done at this point – you’re trust is established and you can now create new application principals based on it. How you’ll use it is based on the application itself; in the case of a remote SharePoint index I’ll go ahead and finish out the scenario now for completeness.

STEP 4: Creating an App Principal (example only for remote SharePoint index):

There are two steps in this process – getting an app principal and granting it rights. Remember from our scenario that FARM_B needs to trust calls from FARM_A because it is going to get queries for the remote SharePoint index. So for my app principal I need to get a reference to the web app in FARM_B that FARM_A is going to use. Once I have that reference then I can grant rights for FARM_A to use it.
To get a reference to an app principal you use the cmdlet like this:
$p = Get-SPAppPrincipal -Site http://FARM_B -NameIdentifier $i.NameId
IMPORTANT: There is one important thing to note here, that I think will be especially common especially during the SharePoint 2013 beta. You may get strange errors in PowerShell when you try and get the SPAppPrincipal. What I’ve found is that if your available memory on your server drops below 5% then all WCF calls will fail. Since this PowerShell cmdlet calls into a service application endpoint, which is hosted as a WCF, the Get-SPAppPrincipal cmdlet fails when you are low on memory. You can check in the Windows Event Viewer in the Application Log to see whether this is the cause of your problem. This has happened to me multiple times so far so chances are others will see it as well.
Note that as I described earlier in the post, I finally get to use my $i variable to grab the NameIdentifier of the STS in FARM_A. Now that I have a reference to the app principal for the FARM_B web app, I can grant it rights like so:
Set-SPAppPrincipalPermission -Site http://FARM_B -AppPrincipal $p -Scope SiteSubscription -Right FullControl
There you have it – those are your options and methodologies for creating an oAuth trust between two SharePoint farms. I’ll continue to dig into oAuth and the various uses and issues to be aware of over time on this blog.
UPDATE: There are other steps you need to do to get complete set of results back from all content sources when using Remote SharePoint Index; for more details see http://blogs.technet.com/b/speschka/archive/2013/01/24/getting-a-full-result-set-from-a-remote-sharepoint-index-in-sharepoint-2013.aspx.

Ref:

https://samlman.wordpress.com/2015/03/01/setting-up-an-oauth-trust-between-farms-in-sharepoint-2013/

Configure trust for search between two SharePoint Server 2013 farms

SharePoint 2013

2 out of 2 rated this helpful - Rate this topic

Applies to: SharePoint Server 2013
Topic Last Modified: 2014-07-16
Summary:Configure a SharePoint Server 2013 content farm that receives search queries to trust the SharePoint Server 2013 farm that sends the queries.
To configure an on-premises SharePoint Server 2013 content farm to return results from its search index to a separate on-premises SharePoint Server 2013 farm, you must perform the following two main procedures:

In the farm that will receive the search queries, configure trust of the farm that will send the queries by doing the following:
- Configure a server-to-server trust relationship by using the Open Authorization 2.0 (OAuth 2.0) web authorization protocol.
- Enable the farm that receives the queries to return search results from all of its web applications that host content.

In the farm that will send the search queries, create a result source that does each of the following:

Specifies Remote SharePoint as the protocol.
Specifies the address of any root site collection in the SharePoint farm that will receive the search queries.

For more information, see Configure result sources for search in SharePoint Server 2013.

Note:
After you create the result source, you expose the search results that it provides by using it in a Web Part or a query-rule action. In this way, users of the farm that is sending search queries can see results from the farm that is receiving the queries. For more information, see Understanding result sources for search in SharePoint Server 2013.

This article describes how to perform the first procedure in the list above: how to configure the farm that receives search queries to trust the farm that sends the queries.
For brevity in this article, the following terms are used:

SendingFarm	An on-premises SharePoint Server 2013 farm that has a search service that sends search queries to ReceivingFarm.
ReceivingFarm	An on-premises SharePoint Server 2013 content farm that has a search index that receives search queries from SendingFarm. In this article, it is assumed that ReceivingFarm has at least one web application that hosts content.

In order for SendingFarm to be able to get search results from the search index in ReceivingFarm, the farms must have the following characteristics:

Each farm is a SharePoint Server 2013 on-premises deployment.
User profiles in the two farms are synchronized. For more information, see Server-to-server authentication and user profiles in SharePoint Server 2013.

Note:
Because SharePoint 2013 runs as websites in Internet Information Services (IIS), administrators and users depend on the accessibility features that browsers provide. SharePoint 2013 supports the accessibility features of supported browsers. For more information, see the following resources: Plan browser support Accessibility for SharePoint 2013 Accessibility features in SharePoint 2013 Keyboard shortcuts Touch

Note:

Because SharePoint 2013 runs as websites in Internet Information Services (IIS), administrators and users depend on the accessibility features that browsers provide. SharePoint 2013 supports the accessibility features of supported browsers. For more information, see the following resources:

To configure ReceivingFarm to trust SendingFarm

Verify that the account that performs this procedure is a member of the following groups:
- Farm Administrators group in ReceivingFarm.
- Administrators group on the server on which you are running Windows PowerShell cmdlets.
  An administrator of that server can use the Add-SPShellAdmin cmdlet to grant someone permission to use SharePoint 2013 cmdlets. When you run the Add-SPShellAdmin cmdlet, you must have membership in the securityadmin fixed server role on the SQL Server instances, and you must have membership in the db_owner fixed database role on all databases that are to be updated. For more information, see Add-SPShellAdmin. Contact your system administrator or SQL Server administrator to request these memberships if you do not have them.
On a server in ReceivingFarm, start the SharePoint 2013 Management Shell.
- For Windows Server 2008 R2:
  In the SharePoint 2013 environment, on the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
- For Windows Server 2012:
  - In the SharePoint 2013 environment, on the Start page, click SharePoint 2013 Management Shell.
  - If SharePoint 2013 Management Shell is not on the Start page, 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.

On a server in ReceivingFarm, run the following commands at a Windows PowerShell command prompt. The commands use the OAuth 2.0 web authorization protocol to configure a server-to-server trust, so that ReceivingFarm will trust SendingFarm.

        
# Create a trusted security token issuer
$i = New-SPTrustedSecurityTokenIssuer -Name "SendingFarm" -IsTrustBroker:$false -MetadataEndpoint "https://<SendingFarm_web_application>/_layouts/15/metadata/json/1"
# Configure trust of the token-signing certificate'
# by adding the trust used to sign oAuth tokens'
# to the list of trusted root authorities'
# in ReceivingFarm
New-SPTrustedRootAuthority -Name "SendingFarm" -MetadataEndPoint https://<SendingFarm_web_application>/_layouts/15/metadata/json/1/rootcertificate

Where:
https://<SendingFarm_web_application> is any SSL-enabled web application in SendingFarm

Important:
Web applications that include server-to-server authentication endpoints for incoming server-to-server requests, or that make outgoing server-to-server requests, should be configured to use Secure Sockets Layer (SSL). For information about how to configure a web application to use SSL, see Create claims-based web applications in SharePoint 2013. For information about how to configure HTTP support for server-to-server requests, see Configure an STS for HTTP in Configure server-to-server authentication in SharePoint 2013.

Important:

Web applications that include server-to-server authentication endpoints for incoming server-to-server requests, or that make outgoing server-to-server requests, should be configured to use Secure Sockets Layer (SSL). For information about how to configure a web application to use SSL, see Create claims-based web applications in SharePoint 2013. For information about how to configure HTTP support for server-to-server requests, see Configure an STS for HTTP in Configure server-to-server authentication in SharePoint 2013.

On a server in ReceivingFarm, at a Windows PowerShell command prompt, run the following command:

        
# Use $realm to store the string'
# that comes after the "@" character'
# in the value of $i.NameId
$realm = $i.NameId.Split("@")

On a server in ReceivingFarm, at a Windows PowerShell command prompt, run the following commands to enable all web applications in ReceivingFarm to return search results to SendingFarm:

        
    

                
            

$s1 = Get-SPSite -Identity https://<ReceivingFarm_web_application>
$sc1 = Get-SPServiceContext -Site $s1
# Set up an authentication realm for'
# a web application that hosts content in ReceivingFarm 
Set-SPAuthenticationRealm -ServiceContext $sc1 -Realm $realm[1]
# Get a reference to the application principal'
# for that web application in Farm B
$p = Get-SPAppPrincipal -Site https://<ReceivingFarm_web_application> -NameIdentifier $i.NameId
# Grant rights to the application principal'
# that SendingFarm will use'
# when it sends queries to ReceivingFarm
Set-SPAppPrincipalPermission -Site https://<ReceivingFarm_web_application> -AppPrincipal $p -Scope SiteCollection -Right FullControl

Where:
https://<ReceivingFarm_web_application> is an SSL-enabled web application in ReceivingFarm.

Repeat the previous step (step 5) for each web application in ReceivingFarm that hosts content that you want to search.
ref: https://technet.microsoft.com/en-us/library/dn133749.aspx