ADFS for Sharepoint: Configure ADFS as Claims Provider in Sharepoint 2013

Hi,

This post is the third part of the serie of posts about ADFS, in the next few lines, will be covered the following things:

  1. Start the Security Token Service (STS)
  2. Import the Token-Signing Certificate
  3. Define a unique identifier for claims mapping
  4. Create the new authentication provider
  1. Start the Security Token Service (STS)

Depending on how you created your SharePoint 2013 farm, you may have to start the Security Token Service. This service is required in order for claims to work properly, and should be running in all SharePoint Servers in the farm.

To start the STS:

  • Open the IIS Manager Console
  • Expand the Application pools section beneath the server name.
  • In the Application pools pane, select SecurityTokenServiceApplicationPool
  • In the Actions pane, select the Start link

20

  1. Import the Token-Signing Certificate

To import the Token-Signing certificate do the following:

  • Start a SharePoint 2013 Management Shell as an Administrator
  • (Optional) If you have a root site in the certificate chain, you must import the parent certificate first before importing the singning certificate:

    $parentcert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“<path to the parent certificate>”)

    New-SPTrustedRootAuthority -Name “Token Signing Cert Parent” -Certificate $parentcert

  • Import the signing certificate provided to you by the ADFS administrator

$signcert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“<path to the signing certificate>”)

New-SPTrustedRootAuthority -Name “Token Signing Cert” -Certificate $signcert

21

  • You can also check that the certificate has been correctly imported from central administration; within the Security section select the Manage Trust link and you will see the Trusted Root Authorities in which your farm trusts.

22

  1. Define a unique identifier for claims mapping

Next you have to define mappings for the e-mail and role claims, as follows:

  • For the identity claim mapping (e-mail address), enter the following:

    $identityClaimMapping = New-SPClaimTypeMapping -IncomingClaimType “http://schemas. xmlsoap.org/ws/2005/05/identity/claims/emailaddress” -IncomingClaimTypeDisplayName “EmailAddress” –SameAsIncoming

  • For the Role claim mapping, enter the following

    $roleClaimMapping = New-SPClaimTypeMapping -IncomingClaimType “http://schemas. microsoft.com/ws/2008/06/identity/claims/role” -IncomingClaimTypeDisplayName “Role” –SameAsIncoming

  1. Create the new authentication provider

Once the claims mappings are complete, we can build the authentication provider

  • First we need to define the rusted STS for a SharePoint farm ($realm), specifying a name for your web application. This value must match the value you used as a Relying Party Identifier in your ADFS Server.

    $realm = “urn:sharepoint:portalDemos”

    23

  • Next, you define a variable ($signInURL) with value the URL of the logon page for ADFS

    $signInURL = https://smsp.demos.local/adfs/ls

  • Finally, you create the new provider with the following cmdlet, using your own values for the –Name and –Description values.

    $ap = New-SPTrustedIdentityTokenIssuer -Name ADFS -Description “Active Directory Federation Services” -realm $realm -ImportTrustCertificate $signcert -ClaimsMappings $identityClaimMapping, $roleClaimMapping -SignInUrl $signInURL -IdentifierClaim $identityClaimMapping.InputClaimType

  • To validate the script ran successfully the “Get-SPTrustedTokenIssuer” cmdlet can be executed to verify the results.  There are 5 key pieces of information to validate:
    • ProviderUri  (SharePoint will send authentication requests to this Uri)
    • ProviderRealms  (SharePoint will send the URN to ADFS which in turn will use the realm value to match it up with the appropriate relying party entry)
    • ClaimTypeInfomation  (This verifies the two claim mappings that we created during the script execution and should match up with what is configured in the ADFS relying party entry)
    • Signing Certificate  (Verify the “Token-Signing” certificate is listed here)
    • Name  (The name entry will be listed in the Web Application as an option under the “Trusted Authentication Providers”)

24

Advertisement

ADFS for Sharepoint: Preparing ADFS for Sharepoint 2013

Hi,

This post is a continuation of the previous post about ADFS, in this post the following topics will be covered:

  1. Configure ADFS for a Relying Party
  2. Configure a claim rule
  3. Export the Token-Signing Certificate
  4. Test ADFS Connectivity

Let’s begin!

  1. Configure ADFS for a Relying Party: This step adds a Relying Party Trust from the ADFS server for the Sharepoint web application, using the WS-Federation passive protocol.
  • Open the AD FS Management Console
  • Expand the Trust Relationships node
  • Click on the Relying Party Trust node
  • Click on the Add Relying Party Trust link from the right pane to start the Add Relying Party Trust wizard.

1

  • Click Start on the Welcome screen

2

  • Select the Enter data about the relying party manually radio button and click next

3

  • Enter a Display name, something that describes the SharePoint web application is recommended.

4

  • Select the AD FS 2.0 profile

5

  • On the next screen click Next, it is not necessary to select a certificate in this step.

6

7

  • Configure the Relying party trust identifiers with these values:
    • https://<your_webApp>/
    • urn:sharepoint:portal (this value is descriptive, you can use any value but remember this value is the one you will use in the creation of the claims authentication provider in SharePoint).

8

  • Select the Permit all users to access this relying party option and click next.

9

  • Select Next in the Ready to Add Trust screen

10

  • Leave the Open the Edit Claim Rules dialog for this relying party trust when the wizard closes and click Close

11

  1. Configure a claim rule
  • Open the AD FS Management Console
  • Expand the Trust Relationships node
  • Click on the Relying Party Trust node
  • Click on the Edit Claim Rules link from the right pane to start the Add Relying Party Trust wizard.

12

  • Click Add Rule
  • Select Send LDAP Attributes as Claims and click Next

13

  • Enter a Claim rule name, the Attribute Store and configure the attribute mapping like the following screen

14

  • Click Finish and the Relying Party will be configured for using with SharePoint.
  1. Export the Token-Signing Certificate

The final step you have to complete from the ADFS Server is to export the Token-Signing Certificate. This certificate will be used to create a the SPTrustedIdentityTokenIssuer in SharePoint.

  • Open IIS 7 manager on the Federation Server.
  • Select the servername in the console and double-click the certificates feature. You should see the certificates you configured earlier for ADFS.
  • Double-click the Token-Signing certificate and select the details tab.
  • Select copy to file and use these options in the following wizard:
    • No do not export the private key
    • DER encoded binary X.509 (.CER)
    • save the file as c:TokenSign.cer

15

  1. Test ADFS Connectivity

Finally, it is a good practice to verify that all your configuration is working. You can do it so in two steps:

16

ADFS for Sharepoint: Creating Certificates for ADFS 2.0

Hi again,

This time I will try to divide the post in a serie of post about ADFS 2.0 for SharePoint. In the first post I will talk about creating certificates for ADFS 2.0, so le’ts begin:

For setting up ADFS we need three distinct certificates: Service Communications, Token-Signing and Token-Decrypting.

  1. Service Communications Certificate
  • Used for the logon page provided by ADFS
  • This should be a public certificate since you´ll be using it for employees accessing the logon page externally.
  1. Token-Signing Certificate
  • Used for encrypting the tokens that will be provided for SharePoint.
  • Can be a public certificate or a certificate issued by your internal CA
  • Should be a 2048-bits certificate.
  1. Token-Decrypting Certificate

Depending on the type of scenario you are deploying (production or testing) you can chose to use Self-Signing Certificates, Certificates from your CA or public Certificates.

Creating Self-Signing Certificates is a pretty straightforward process and can be done within IIS. For a test scenario you can create a Self-Signing Certificate and use it for the three types of certificate.

In this post we will review how to use Certificates from our own Certification Authority following these steps:

  • Create ADFS Certificate Template

From the server where the Certificate Authority is installed, go to Server Manager/Roles/Active Directory Certificate Services

  • Request Certificates
    • Service Communications
    • Token-Singning Certificate

Token-Decrypting Certificate