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).
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:
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.
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.powershellSEt-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).