Partager via

Configuring ADFS Trusts For Multiple Identity Providers with SharePoint 2010

  • Article

Hey all, on Thanksgiving eve I've finally finished something I've been wanting to do for a while, and been getting questions on for a while.  There are often scenarios where you need to have a trust from the ADFS server to which SharePoint authenticates.  It may be that you have another identity provider you need to go authenticate too, or you are federating multiple Active Directory forests, etc.  In this post I'm going to walk through how you establish a trust between two ADFS servers that are hosted in two different Active Directory forests, and get the claims to go all the way across back to SharePoint.  Please note that in this example I'm using the RTM version of AD FS 2.0.  I'm also going to assume that you already have added SharePoint as a trusted relying party in one of the ADFS servers.

To begin with, start on the ADFS server to which your SharePoint site has the trust (we'll call it RP).

  1. Open the federationmetadata.xml file from the ADFS server that users will be authenticating against (we'll call it IP) in the browser.  By default the location will be https://myIpAdfsServer/FederationMetadata/2007-06/FederationMetadata.xml.  If you get an untrusted certificate error in the browser you'll need to add the root authority certificate for the IP ADFS server's SSL to your trusted root authorities store.  NOTE:   This assumes that you have the same root authority certificate for both the SSL access to the IP ADFS web server and the IP ADFS token signing certificate. If they are not the same then you need to add the root certificate authority for BOTH to the local RP ADFS server's certificate store.   To do that:
    1. Click through to view the web site, which should show the Xml file.
    2. Click on the View Certificates icon so you can see the SSL certificate that was used.
    3. Click on the Certificate Path tab.
    4. Double-click on the top certificate in the chain - this is the root authority certificate.
    5. Click on the Details tab.
    6. Click on the Copy to File... button and save the certificate in CER format to the local disk.  You can now close out all of the certificate dialogs and browser.
    7. Open up the Certificates MMC; if you don't have a shortcut for this then just start the MMC from the Run menu, Add snap-ins, and add the Certificates snap-in for the Computer (local).
    8. Expand the Trusted Root Certification Authorities node, right-click on the Certificates node, and choose the Import menu.  Follow the wizard to import the root authority .CER file you exported above.
  2. Open up the AD FS 2.0 Management application.
  3. Expand the Trust Relationships node, then right-click on the Claim Provider Trusts node and select Add Claims Provider Trust...
  4. Click the Start button to begin the wizard.
  5. Leave the default option selected to Import data about the claims provider published online or on a local network, and in the edit box put in the address to the FederationMetadata.xml file (https://myIpAdfsServer/FederationMetadata/2007-06/FederationMetadata.xml by default) then click the Next button.  If your root authority certificate is correctly installed and the name can be resolved, then the wizard will continue to the next step.  If not, you have troubleshooting to do.
  6. Provide a Display Name and optionally Notes, then click the Next button.
  7. Review your data if needed, then click the Next button.
  8. Click the Close button to complete the wizard.  Leave the box checked to open up the rules dialog when complete.

Now for the claims provider trust, you need to create rules to pass through all of the claims that you get from the IP ADFS server.  So in the rules dialog, for each claim you want to send to SharePoint you're going to do the following:

  1. Click on Add Rule.
  2. Select the Pass Through or Filter an Incoming Claim in the Claim Rule Template drop down and click the Next button.
  3. Give it a Claim Name - probably including the name of the claim being passed through would be useful.  For the Incoming Claim Type drop down, select the claim type you want to pass through, for example E-Mail Address. I usually leave the default option for Pass through all claim values selected, but if you have different business rules then select whatever's appropriate and click the Finish button.  Note that if you choose to pass through all claim values ADFS will give you a warning dialog.

Once you've added pass through claims for each claim you need in SharePoint you can close the rules dialog.  Now, for the last part of the RP ADFS server configuration, you need to find the SharePoint relying party.  Click on the Edit Claim Rules dialog, and for each Pass Through claim rule you made in the previous step, you ALSO need to add a Pass Through claim rule for the SharePoint relying party.  That will allow the claims to flow from the IP ADFS server, to the RP ADFS server through the trusted claim provider, and out to SharePoint through the trusted relying party.  If your claims from your IP ADFS server are not showing up in SharePoint these are the two locations to start looking.

Now move to the IP ADFS server.  Do step 1a through 1h as described above to ensure that you have added the root authority certificate(s) to the IP ADFS server.

  1. Open the AD FS 2.0 Management application.
  2. Expand the Trust Relationships node, then right-click on the Relying Party Trusts node and select Add Relying Party Trust...
  3. Click the Start button to begin the wizard.
  4. Leave the default option selected to Import data about the claims provider published online or on a local network, and in the edit box put in the address to the FederationMetadata.xml file (https://myRpAdfsServer/FederationMetadata/2007-06/FederationMetadata.xml by default) then click the Next button.  If your root authority certificate is correctly installed and the name can be resolved, then the wizard will continue to the next step.  If not, you have troubleshooting to do.
  5. Provide a Display Name and optionally Notes, then click the Next button.
  6. Review your data if needed, then click the Next button.
  7. Click the Close button to complete the wizard.  Leave the box checked to open up the rules dialog when complete.

Since this is the ADFS IP, we need to create a rule to pass along all of the claims that are going to be needed by SharePoint, the same way as you do when you add SharePoint as a relying party in ADFS.  Rather than walk through it in step-by-step detail, I'll just suggest you read the ADFS end to end configuration posting I made at https://blogs.technet.com/b/speschka/archive/2010/07/30/configuring-sharepoint-2010-and-adfs-v2-end-to-end.aspx.  So in a nutshell you want to add a rule to Send LDAP Attributes as Claims.  Configure this rule the same way (meaning select the same claims and make the same mappings) as you do when you configure SharePoint as a relying party in ADFS.  That concludes the configuration you need to do on the ADFS IP.

That's it.  You should now be set up to browse to your SharePoint farm and get redirected to the IP ADFS server to authenticate, while hitting your RP ADFS server coming and going.  Again, remember that if your client machines do not have the root authority certificate for the IP ADFS server's web site SSL certificate, you will need to add this certificate to your client's local trusted root authority certificate store.  Otherwise when you go to authenticate and you are redirected to the IP ADFS server's web site, you will get a certificate warning dialog.

Once you have this set up, if you try and authenticate as a user on IP ADFS, you may get an error message in the browser coming from the IP ADFS saying that some error has occurred.  If you look in the event log on the IP ADFS server, you may see message ID #317 in the Applications and Services Logs...AD FS 2.0...Admin node:  The following errors occurred while building the certificate chain: The revocation function was unable to check revocation for the certificate.   You will likely see that message if the token signing certificate used by the RP ADFS is either self-signed or domain issued.  You can eliminate this problem if you wish by turning off certificate revocation checking for your relying party.  To do so, open a PowerShell window on the IP ADFS server and type the following commands:

add-pssnapin microsoft.adfs.powershell
SEt-ADFSRelyingPartyTrust -TargetName <YourRelyingPartyName> -EncryptionCertificateRevocationCheck None

You may need to restart the AD FS 2.0 service after making this change.

And that my friends, does it.  It's "interesting" to boil several hours of hair-pulling frustration into a 30-minute blog post.  I hope this helps someone, somewhere, and that everyone has a great Thanksgiving holiday.  One side note to this - I will add another post here shortly - a companion piece - that describes how to configure a SharePoint web app to redirect automatically to the write claims provider when AD FS has more than one (as we demonstrated creating here).

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    Steve: Your timing is impeccable.  Our team has built exactly this configuration (multiple IP to single SP Site) over the last few weeks, with a slight twist that I'll get to in a moment.  We followed your end-to-end guide for the first Identity Provider, and then spun up a second.  It's good to see we're on the same page, and for claims access authenticating with DOMAINUSERNAME, everything works like a charm… cue the twist. We need to be able to use PKI certs provided by SmartCard instead of DOMAINUSERNAME. So we have our federated claims environment up and running - 2 account forests, 1 resource forest (all Win 2008 SP2), ADFS 2, claims enabled SP2010 site. I can successfully access the site from each of the account forests, with the appropriate permissions, using DOMAINUSERNAME credentials. I can successfully access the site "across forests" as well (i.e. Use the identity provider for AccountFores1 from a workstation joined to AccountForest2), but the problem is when we try to use PKI certs from our SmartCard.   Each of the account forests are SmartCard-enabled, and the authentication from a workstation in AccountForest1 >> ResourceForest using the AccountForest1 identity provider works, and similarly for AccountForest2.   But... If I try to use my AccountForest1 SmartCard from a workstation anywhere other than an AccountForest1 workstation, it fails. Here's a scenario: An external contractor is trying to access the ResourceForest website from his company's corporate-domain joined workstation.  Puts in his SmartCard and tries to access, but it fails. is there something we need to do to SP to SmartCard-enable/PKI-enable the site (in addition to claims-aware and SmartCard-enabled domain) either in IIS or in SharePoint? SmartCard auth to Windows works if you're on domain-joined machine.  The failure is here:  Login to AccountForest1 machine (CAC or user/password) >> browse to site >> choose SAML provider from menu >> choose Account2 or Resource identity provider >> prompts for credentials >> choose PKI Cert from inserted SmartCard >> prompts you again, and on 3rd prompt, fails with 401 error from the ADFS server for that identity provider. If, in that same scenario, I provide DOMAINUSERNAME instead of PKI Cert from inserted SmartCard, everything is fine, and it serves content as expected, based on who you're logged in as. It's sending to the right site locations, but the error that appears in the security log of the ADFS server shows that when you select the PKI Cert, it's using the Pre-windows 2000 account info, and the problem is the domain it's providing... whatever domain the machine you're on is joined to. So in the example above, coming in from an AccountForest1 workstation, using a PKI Cert pointing at the Account2 identity provider, will error out with "bad username or password" for user account1<EDIPI>.  Of course it's a bad username... the domain's wrong. So the long-winded question is, can SP2010 Claims Awareness & ADFS 2 Identity Providers support SmartCard / PKI Certificates for authentication from external users and/or across forests? Or would you need to create a Federation Partnership for each external entity, and map SP roles appropriately? Thanks again for your thorough (and timely) posts.  It's great to have this resource to work from!!

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    thanks

  • Anonymous
    November 27, 2010
    Can you update the blog post w/ a picture illustrating the scenario you're describing? Is this what you're talking about: http://bit.ly/dNg4si Or this: http://bit.ly/euQosA ?

  • Anonymous
    November 30, 2010
    Question:  How would you trust a 3rd party (non-AD) Identity provider?  I can't seem to find instructions that explain that.  Your first step is "Open the federationmetadata.xml file from the ADFS server ", what if I don't have an ADFS.  What if I'm using RSA Access Manager, or CA Federation Manager, or some other provider of SAML 2.0 messages.  How would I trust them?  Thanks for any references you can provide.

  • Anonymous
    December 21, 2011
    We were able to follow this and it worked, however it wasn't working for UAG (something we had already had configured for 5+ sites).  The error we were receiving was: "Event ID 161: The User Name Claim Type Is Missing from the Security Token" We had ADFS working when we went around UAG, but as soon as we put UAG in the mix we got this error.  I had to edit the ADFS 'hub server' that was being used as the AUTH in UAG.  The part I had to edit was related to Solution #2 in this article (social.technet.microsoft.com/.../1810.aspx) and the Relying Trust Party was my connection to UAG.  I originally only had LDAP attributes as claims, so I added a Pass through or Filter an incoming claim and selected the correct lead claim on both sides and presto - it started working!   I def think others will find this useful if they use UAG as it was not easy figuring this out.

  • Anonymous
    August 31, 2012
    Is there a solution for the issue that Kevin McD mentioned in his comments? So in the example above, coming in from an AccountForest1 workstation, using a PKI Cert pointing at the Account2 identity provider, will error out with "bad username or password" for user account1<EDIPI>.  Of course it's a bad username... the domain's wrong.

  • Anonymous
    September 18, 2014
    The comment has been removed

  • Anonymous
    February 28, 2015
    In my previous posting ( http://blogs.technet.com/b/speschka/archive/2010/11/24/configuring-adfs-trusts

  • Anonymous
    March 01, 2015
    In the first post in this series ( http://blogs.technet.com/b/speschka/archive/2011/05/05/federated-saml