In order to setup a SSO sign-in with your ADFS and Emgage Cloud, you need to follow the instruction to configure the initial “Relying Party” to be used with our SharePoint web application “” 

NOTE: replace "" with your URL

  • Click the “Required: Add a trusted relying party” link in the “Overview” section of the AD FS 2.0 console


  • Click “Start” on the welcome screen
  • Select the “Enter data about the relying party manually” radio button and click “Next >”




  • Enter a value in the “Display name:” and optionally the “Notes:” fields



  • Select the “AD FS 2.0 profile” radio button




  • Click “Next >” on the “Configure Certificate” screen because it is not necessary to encrypt SAML tokens since HTTPS is a requirement for the SharePoint Web App to communicate with the ADFS STS


  • Select the “Enable support for the WS-Federation Passive protocol” checkbox and enter the URL for the relying party WS-Federation Passive protocol URL



  • Enter a relying party trust identifier and click the “Add” button




  • Select the “Permit all users to access this relying party” radio button
  • Review the configured settings and click “Next >”
  • Leave the “Open the Edit Claim Rules dialog for this relying party trust when the wizard closes” and click “Close”


Add Claims Rule

In this step, a claim rule will be created that maps email address and role attributes from Active Directory.

  • Click “Add Rule…”
  • Select the “Send LDAP Attributes as Claims” entry from the dropdown box and click“Next >”




  • Enter a “Claim rule name:”, select and “Attribute store:” and configure the attribute mapping



  • The relying party is now configured and will be used in subsequent steps when configuring a “Trusted Authentication Provider” in SharePoint



Configure ADFS Certificates

In this step we need to configure ADFS to use the “Token-decrypting” and “Token-signing”certificates that were created previously.  Once configured, the “Token-signing” certificate needs to be exported and a copy placed on the SharePoint server to be imported in a subsequent step.

  • Navigate to the “Certificates” folder in the AD FS 2.0 console
  • Enter the following commands to disable certificate rollover



  • In the right-hand pane click the “Add Token-Signing Certificate…” action



  • Select the appropriate certificate from the list of installed certificates. 



  • In the “Token-signing” section two certificates will be listed.  Highlight the new entry,“CN=signing.2008r2.local” and click “Set as Primary”



  • Click the “Add Token-Decrypting Certificate…” entry




  • Select the appropriate certificate from the list of installed certificates to function as the decrypting certificate.  You can use the token-signing, but I choose to create individual certificates for each function.


  • Highlight the “CN=decrypting.2008r2.local” entry in the “Token-decrypting” section and click the “Set as Primary” action
  • The new certificates should be set as primary in each section.  Optionally you could delete the secondary certificates which are self-signed certificates created during the ADFS installation.



Export Token Signing Certificate

The Token-signing certificate needs to be exported and a copy placed on the SharePoint server that will be used to run the PowerShell commands to configure the “Trusted Identity Provider”.  In this example, I’ll copy it to the web front end server “SP-WFE-1”.

  • Navigate to the “Certificates” folder in the AD FS 2.0 console
  • Highlight the primary token-signing certificate “CN=signing.2008r2.local” and click on the “View Certificate…” entry in the “Actions” pane



  • Click the “Details” tab
  • Click the “Copy to File…” button



  • Select the “No, do not export the private key” option and click “Next >”
  • Select the “DER encoded binary X.509 (.CER)” radio button and click “Next >”
  • Click the “Browse…” button and navigate to a location on the local file system to save a copy of the export certificate.
  • Click “Finish” to complete the action
  • Copy the file to the SharePoint web front end server to be used in a later step


Test ADFS Connectivity

Now that ADFS has been configured we can verify the health of ADFS prior to configuring a“Trusted Identity Provider”.

  1. Access the WS-Metadata Exchange Endpoint
  2. Access the Federation Metadata endpoint

In both examples an XML result should be returned which validates the endpoints are functioning correctly: