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 http://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).