How to configure AD FS v 2.0 in SharePoint Server 2010

  • Article

 

Applies to: SharePoint Foundation 2010, SharePoint Server 2010

The procedures in this article describe how to configure Active Directory Federation Services version 2.0 (AD FS) in Microsoft SharePoint Server 2010.

You can use Active Directory Federation Services (AD FS) 2.0 with the Windows Server 2008 operating system to build a federated identity management solution that extends distributed identification, authentication, and authorization services to Web-based applications across organization and platform boundaries. By deploying AD FS 2.0, you can extend your organization’s existing identity management capabilities to the Internet.

In this article, AD FS v2 is our identity provider, also known as IP-STS (Security Token Service). AD FS will provide claims-based authentication. To begin, AD FS needs to be configured with information about our relying party, in this case, SharePoint Server 2010. From the Microsoft SharePoint 2010 Products perspective, AD FS needs to be configured to trust the IP-STS that is sending a claims-based mapping. Finally, a Web application and site collection are created that will use the claims-based authentication level.

Note

You must install and configure a server running Active Directory Federation Services (AD FS) 2.0 before you perform the procedures in this article. For information about configuring a server to run AD FS 2.0, see the AD FS 2.0 Deployment Guide (https://go.microsoft.com/fwlink/p/?LinkId=191723).

The following video illustrates the step-by-step process that configures Active Directory Federation Services version 2.0 (AD FS) in Microsoft SharePoint Server 2010.

Video: Configure SharePoint Server 2010 with AD FS trusted claims

In this article:

  • Configure a relying party

  • Configure the claim rule

  • Export the token signing certificate

  • Exporting multiple parent certificates

  • Import a token signing certificate by using Windows PowerShell

  • Define a unique identifier for claims mapping by using Windows PowerShell

  • Create a new authentication provider

  • Associate a Web application with a trusted identity provider

  • Create a site collection

Note

The steps listed in this article need to be completed in consecutive order.

Configure a relying party

Use the procedure in this section to configure a relying party. The relying party defines how the AD FS recognizes the relying party and issues claims to it.

To configure a relying party

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the local computer. For additional information about accounts and group memberships, see Local and Domain Default Groups

  2. Open the Active Directory Federation Services (AD FS) 2.0 Management console.

  3. In the left pane, expand Trust Relationships, and then double-click the Relying Party Trusts folder.

  4. In the right pane, click Add Relying Party Trust. This opens the Active Directory Federation Services (AD FS) 2.0 configuration wizard.

  5. On the Welcome to the Add Relying Party Trust Wizard page, click Start.

  6. Select Enter data about the relying party manually, and then click Next.

  7. Type a relying party name and click Next.

  8. Make sure Active Directory Federation Services (AD FS) 2.0 Profile is selected, and click Next.

  9. Do not use an encryption certificate. Click Next.

  10. Click to select the Enable support for the WS-Federation Passive protocol check box.

  11. In the WS-Federation Passive protocol URL field, type the name of the Web application URL, and append /_trust/ (for example, https://YourWebAppName/_trust/). Click Next.

    Note

    The name of the URL has to use Secure Socket Layer (SSL).

  12. Type the name of the relying party trust identifier (for example, urn:sharepoint:YourWebAppName), and click Add. Click Next.

  13. Select Permit all users to access this relying party. Click Next.

  14. On the Ready to Add Trust page, there is no action required, click Next.

  15. On the Finish page, click Close. This opens the Rules Editor Management console. Use this console to configure the mapping of claims from an LDAP Web application to SharePoint Server 2010.

Configure the claim rule

Use the procedure in this step to send values of a Lightweight Directory Access Protocol (LDAP) attribute as claims and specify how the attributes will map to the outgoing claim type.

To configure a claim rule

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the local computer. For additional information about accounts and group memberships, see Local and Domain Default Groups

  2. On the Issuance Transform Rules tab, click Add Rule.

  3. On the Select Rule Template page, select Send LDAP Attributes as Claims. Click Next.

  4. On the Configure Rule page, type the name of the claim rule in the Claim rule name field.

  5. From the Attribute Store drop-down list, select Active Directory.

  6. In the Mapping of LDAP attributes to outgoing claim types section, under LDAP Attribute, select E-Mail Addresses.

  7. Under Outgoing Claim Type, select E-Mail Address.

  8. Under LDAP Attribute, select Token Groups-Unqualified Names.

  9. Under Outgoing Claim Type, select Role.

  10. Click Finish, and then click OK.

Export the token signing certificate

Use the procedure in this section to export the token signing certificate of the AD FS Server with which you want to establish a trust relationship, and then copy the certificate to a location that SharePoint Server 2010 can access.

To export a token signing certificate

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the local computer. For additional information about accounts and group memberships, see Local and Domain Default Groups

  2. Open the Active Directory Federation Services (AD FS) 2.0 Management console.

  3. In the left pane, click to expand Service, and then click the Certificates folder.

  4. Under Token signing, click the primary token certificate as indicated in the Primary column.

  5. In the right pane, click View Certificate link. This displays the properties of the certificate.

  6. Click the Details tab.

  7. Click Copy to File. This starts the Certificate Export Wizard.

  8. On the Welcome to the Certificate Export Wizard page, click Next.

  9. On the Export Private Key page, click No, do not export the private key, and then click Next.

  10. On the Export File Format page, select DER encoded binary X.509 (.CER), and then click Next.

  11. On the File to Export page, type the name and location of the file you want to export, and then click Next. For example, enter C:\ADFS.cer.

  12. On the Completing the Certificate Export Wizard page, click Finish.

Exporting multiple parent certificates

To complete the configuration of the AD FS Server, copy the .CER file to the computer running AD FS.

The token signing certificate may have one or more parent certificates in its chain. If it does, every certificate in that chain needs to be added to the SharePoint Server list of trusted root authorities.

To determine if one or more parent certificates exist, use the following steps.

Note

These steps should be repeated until all certificates have been exported up to the root authority certificate.

To export multiple parent certificates

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the local computer. For additional information about accounts and group memberships, see Local and Domain Default Groups

  2. Open the Active Directory Federation Services (AD FS) 2.0 Management console.

  3. In the left pane, click to expand Service, and then click the Certificates folder.

  4. Under Token signing, click the primary token certificate as indicated in the Primary column.

  5. In the right pane, click View Certificate link. This displays the properties of the certificate.

  6. Click the Certification tab.

    This displays any other certificate(s) in the chain.

  7. Click the Details tab.

  8. Click Copy to File. This starts the Certificate Export Wizard.

  9. On the Welcome to the Certificate Export Wizard page, click Next.

  10. On the Export Private Key page, click No, do not export the private key, and then click Next.

  11. On the Export File Format page, select DER encoded binary X.509 (.CER), and then click Next.

  12. On the File to Export page, type the name and location of the file you want to export, and then click Next. For example, enter C:\ADFSParent.cer.

  13. On the Completing the Certificate Export Wizard page, click Finish.

Import a token signing certificate by using Windows PowerShell

Use this section to import the token signing certificates to the trusted root authority list that resides on the SharePoint server. This step must be repeated for every token signing certificate in the chain until the root certificate authority is reached.

To import a token signing certificate by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. On the Start menu, click All Programs.

  3. Click Microsoft SharePoint 2010 Products.

  4. Click SharePoint 2010 Management Shell.

  5. From the Windows PowerShell command prompt, import the parent certificate of the token signing certificate (that is, the root authority certificate), as shown in the following syntax:

    $root = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\adfsParent.cer")

New-SPTrustedRootAuthority -Name "Token Signing Cert Parent" -Certificate $root

  6. From the Windows PowerShell command prompt, import the token signing certificate that was copied from the AD FS server, as shown in the following syntax:

    $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\adfs.cer ")

New-SPTrustedRootAuthority -Name "Token Signing Cert" -Certificate $cert

For additional information about the New-SPTrustedRootAuthority cmdlet, see New-SPTrustedRootAuthority

Define a unique identifier for claims mapping by using Windows PowerShell

Use the procedure in this section to define a unique identifier for claims mapping. Typically, this information is in the form of an e-mail address and the administrator of the trusted STS will have to provide this information because only the owner of the STS knows which claim type will be always unique for each user.

To define a unique identifier for claims mapping by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. On the Start menu, click All Programs.

  3. Click Microsoft SharePoint 2010 Products.

  4. Click SharePoint 2010 Management Shell.

  5. From the Windows PowerShell command prompt, create an identity claim mapping, as shown in the following syntax:

    $map = New-SPClaimTypeMapping -IncomingClaimType "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming

  6. From the Windows PowerShell command prompt, create the role claim mapping as shown in the following syntax:

    $map2 = New-SPClaimTypeMapping -IncomingClaimType "https://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" -SameAsIncoming

For additional information about the New-SPClaimTypeMapping cmdlet, see New-SPClaimTypeMapping

Create a new authentication provider

Use the procedure in this section to create a new SPTrustedIdentityTokenIssuer.

To create a new authentication provider by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. On the Start menu, click All Programs.

  3. Click Microsoft SharePoint 2010 Products.

  4. Click SharePoint 2010 Management Shell.

  5. From the Windows PowerShell command prompt, create a new authentication provider, as shown in the following syntax.

    Note

    The $realm variable defines the trusted STS that identifies a specific SharePoint farm and the $cert variable is the one that was used from the Import a token signing certificate by using Windows PowerShell section. The SignInUrl parameter is to the AD FS server.

    $realm = "urn:sharepoint:YourWebAppName"

$ap = New-SPTrustedIdentityTokenIssuer -Name "SAML Provider" -Description "SharePoint secured by SAML" -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map,$map2 -SignInUrl "https://YourADFSServerName/adfs/ls" -IdentifierClaim "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"

For additional information about the New-SPTrustedIdentityTokenIssuer cmdlet, see New-SPTrustedIdentityTokenIssuer

Associate a Web application with a trusted identity provider

To configure an existing Web application to use SAML sign-in, the trusted identity provider in the claims authentication type section needs to be modified.

To configure an existing Web application to use the SAML Provider

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group.

  2. In Central Administration, on the Home page, click Application Management.

  3. On the Application Management page, in the Web Applications section, click Manage web applications.

  4. Click to select the appropriate Web application.

  5. From the ribbon, click Authentication Providers.

  6. Under Zone, click the name of the zone. For example, Default.

  7. On the Edit Authentication page in the Claims Authentication Types section, click to select the new Trusted Identity provider name check box.

If you need to create a Web application and configure it to use SAML sign-in, see Create a new SharePoint Web application and configure it to use SAML sign-in.

Create a site collection

As a final step, create a SharePoint site collection and assign an owner. Remember that when adding a site collection administrator, you must enter the name in the format of your identity claim. For example, in this article, the identity claim is an e-mail address. For more information, see Create a site collection (SharePoint Server 2010).