IT tutorials
Applications Server

Microsoft Sharepoint 2013 : Federated Authentication (part 4) - Active Directory Federated Services - Configuring a Relying Party in ADFS

12/23/2014 8:24:16 PM
- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019

Configuring a Relying Party in ADFS

We have now installed and configured ADFS, and we are ready to create a Relying Party. We established in the beginning of this article that a Relying Party is a system or application that permits authenticated user access, but relies on an Issuing Authority (via Secure Token Service) to perform the actual authentication. In this case, SharePoint is our Relying Party, ADFS is our STS, and Active Directory is our Issuing Authority.

  1. Open the ADFS 2.0 Management Console and click the link to create trusted relying party.
  2. A wizard starts and shows a welcome message; after reading the dialog, click the Start button.
  3. ADFS next asks for our data source, from which we can import configuration from a network resource or file, or configure manually (Figure 21).


    Figure 21. Configure Relying Party data source

  4. For our SharePoint Relying Party, choose the manual option and click the Next button.
  5. Enter a display name for the Relying Party and description (optional) on the next dialog.
  6. ADFS supports legacy 1.0, 1.1, and the new 2.0 profile formats. We need the 2.0 format, which supports SAML via STS (Figure 22).


    Figure 22. Profile Type

  7. The next dialog gives you the option to encrypt SAML tokens with selected certificate, which we would normally do, but since SharePoint requires an SSL address to communicate with the ADFS STS, this is unnecessary, so click the Next button.
  8. ADFS requires us to configure a URL for WS-Federation at the Relying Party (Figure 23)—this is the URL with which ADFS will return SAML tokens. At this point, we can also configure Web SSO for SAML Single-Sign-On, but this is outside scope of these instructions.


    Figure 23. Configure URL

  9. In the dialog shown in Figure 23, check the Passive option, and provide an SSL-based URL for your SharePoint site. SharePoint 2013 includes a special URL end point for acceptance of SAML tokens: https://domain-name/_trust/.

     Note  Before configuring SharePoint as a Relying Party, remember to set up SSL for the site—ADFS requires a secure connection to pass back SAML tokens.

  10. In the next dialog (Figure 24), add an additional identifier for the realm—the realm is the identifier that SharePoint will pass to ADFS to identify itself as the Relying Party. Typically, the realm is in the format urn:domain:server


    Figure 24. Configure realm as an identifier

  11. Click the Next button, and then check the Radio button to permit all users to access the Relying Party, followed by the Next button.
  12. Click the Next button on the summary dialog to finish creation of Relying Party configuration.
  13. The last dialog (Figure 25) should show a successful message and include a check box to add claims rules, which we shall do next, after clicking the Close button.


    Figure 825. Successful configuration of the Relying Party

  14. A dialog should appear to add claims rules.
  15. Click the Add Rule button.
  16. In the dialog that appears (Figure 26), select the option to send LDAP attributes as claims. Our Issuing Authority—Active Directory—provides user profile attributes via LDAP.


    Figure 26. Add claim rule

  17. Give the rule name.
  18. Select Active Directory as the attribute store.
  19. Map E-Mail-Addresses to the E-Mail Address claim.
  20. Map Token Groups (unqualified names) to the Role claim.
  21. Map the User-Principal-Name to the UPN claim.

    Note  Ensure that you populate the e-mail address in Active Directory user properties for the user.

  22. Click the Finish button on the dialog (Figure 27).


    Figure 27. Map LDAP attributes to claims

  23. Click the Add Rule button.
  24. Select the option Pass Through or Filter an Incoming Claim.
  25. Click the Next button.
  26. Enter the name “Primary SID” and select the type as Primary SID.
  27. Click the OK button on the rules dialog.

We have now successfully configured SharePoint 2013 as our Relying Party in ADFS. You may have configured your SharePoint 2013 web application for HTTPS requests; if not, you must enable SSL for your application, since ADFS expects all relying parties to communicate on secure transport channels. Flip back to the section “Configuring SSL for SharePoint” to find out how to enable SSL for your SharePoint web application.

The final part of our configuration for ADFS Authentication Federation involves configuration of SharePoint 2013 with a trusted provider to use ADFS. First, we need to export the signing certificate from ADFS and add it to SharePoint as a trusted certificate.

  1. Open the ADFS Management Console.
  2. Expand the Service node and click Certificates (Figure 28).


    Figure 28. Certificates in ADFS

  3. Right-click the Token-signing certificate and click View Certificate in the pop-up menu.
  4. You should see a dialog showing the certificate, like that in Figure 29.


    Figure 29. Token-signing certificate

  5. Click the Details tab, then click the Copy to file button.
  6. Click the Next button.
  7. Select the option to not export the private key, then click the Next button.
  8. Choose the export format (I chose the default DER format) and then click the Next button.
  9. Give the certificate a file name and browse to a location on disk.
  10. Click the Next button, then the Finish button to export the certificate to the file.
  11. Open the Microsoft Management Console (MMC.exe) on the SharePoint server.
  12. Add the Certificates snap-in for the computer account and local machine.
  13. Import the certificate into the Trusted Root Certificate Authorities node.
  14. Import the certificate into the SharePoint node.

After exporting the token-signing certificate, we shall now import the certificate into SharePoint, using a PowerShell script:

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\ADFS.cer ")
New-SPTrustedRootAuthority -Name "ADFS Token Signing Cert" -Certificate $cert

Note  The above script requires the full path to the certificate file.

The final set of steps consists of running some PowerShell scripts to create a new Trusted Provider entry and allow SharePoint to federate with ADFS for authentication. First, we map the ADFS claims to those in SharePoint.

$map = New-SPClaimTypeMapping -IncomingClaimType "

" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming
$map2 = New-SPClaimTypeMapping -IncomingClaimType "

" -IncomingClaimTypeDisplayName "Role" -SameAsIncoming

Finally, the following script creates the trusted provider. Do not forget to include the same realm as that of the Relying Party configuration in ADFS.

$realm = "urn:robdev:sp2013"
$signin = " https://sts.robdev.local/adfs/ls "
$ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS SAML Provider" -Description "SharePoint
secured by ADFS SAML" -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map,$map2 -
SignInUrl $signin -IdentifierClaim " "

The above commands include the claims mappings; realm; name and description of the provider; and HTTPS of the ADFS server, which is typically of the format https://domain/adfs/ls. Notice that SharePoint trusted providers require a designated claim to identify users, in this case the e-mail address claim.

Now that we have configured the trusted provider in SharePoint, it is time to enable it on one of our applications, as follows:

  1. Open Central Administration.
  2. Click the Manage web applications link.
  3. Click the web application to add the trusted provider.
  4. Scroll down to the Claims Authentication Types section, and you should see the new provider (Figure 30).


    Figure 30. Claims authentication types with trusted provider

  5. Check the check box to enable Trusted Identity Provider.
  6. Check the check box for the SAML identity provider we just installed.
  7. Click the Save button at the bottom of the dialog.
  8. Open the web application in a new browser window.
  9. If everything works properly, you see a page like that in Figure 31.


    Figure 31. Sign in page with Windows Authentication and trusted ADFS provider

  10. Select the ADFS SAML provider.
- Microsoft Sharepoint 2013 : Federated Authentication (part 3) - Active Directory Federated Services - Installing ADFS
- Microsoft Sharepoint 2013 : Federated Authentication (part 2) - Active Directory Federated Services - Preparing for ADFS Installation
- Microsoft Sharepoint 2013 : Federated Authentication (part 1) - Active Directory Federated Services - Install Certificate Authority
- Microsoft Sharepoint 2013 Authentication (part 3) - Configuring a Claims Web Application - Configuring SSL for SharePoint
- Microsoft Sharepoint 2013 Authentication (part 2) - Configuring a Claims Web Application - Creating a New CBA Application, Configuring an Existing CBA Web Application
- Microsoft Sharepoint 2013 Authentication (part 1) - Legacy Approach—Classic Mode Authentication
- Microsoft Sharepoint 2013 : Claims-Based and Federated Authentication - Digital Identity
- Exchange Server 2013 Management and Maintenance Practices (part 7) - Weekly Maintenance, Monthly Maintenance, Quarterly Maintenance
- Exchange Server 2013 Management and Maintenance Practices (part 6) - Prioritizing and Scheduling Maintenance Best Practices
- Exchange Server 2013 Management and Maintenance Practices (part 5) - Message Tracking
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
Technology FAQ
- Is possible to just to use a wireless router to extend wireless access to wireless access points?
- Ruby - Insert Struct to MySql
- how to find my Symantec pcAnywhere serial number
- About direct X / Open GL issue
- How to determine eclipse version?
- What SAN cert Exchange 2010 for UM, OA?
- How do I populate a SQL Express table from Excel file?
- code for express check out with Paypal.
- Problem with Templated User Control
- ShellExecute SW_HIDE
programming4us programming4us