As you can imagine, I have seen more than a few error messages over the last few weeks as I have made a journey of ADSFS discovery. Now that we've gotten ADFS in place and working in our environment I thought you might find it helpful if I shared some of the issues I have seen to this point. I've also included a few tips that helped me figure out a lot of the problems I was having.
Before we begin: want to read the full series from start to finish?
"An error occurred"
It's nice to know that SharePoint isn't the only application that gives us such descriptive error messages J
If you look at the error message itself there isn't a lot of useful information so I had to look elsewhere. In this case I found my answer in the Event Viewer under Application and Services Logs > AD FS > Admin. The error message pointed at the relying party trust being unspecified or unsupported.
The error message points specifically at urn:portal:sp2013, which is the relying party trust identifier that being called when we attempted to access our SharePoint site at https://portal.s7gear.com. With this being the case we'll go to the AD FS server and open the AD FS Manager console to access the existing relying party trusts.
In the left-hand navigation menu expand "Trust Relationships" and then select "Relying Party Trusts", as shown in the following screenshot. In the relying party trust window you will see our three relying party trusts, the default and then the two we have created in previous blog posts.
Right click the "Portal" relying party trust and select "Properties" to view and edit its properties.
On the Identifiers tab of the Properties dialog you will see a list of the existing relying party trust identifiers. If you compare the identifier in the screenshot below with the identifier in the error message you will see that the identifiers do not match and must be corrected. Once the identifier here is changed to match the expected identifier, the user should see the sign in page.
Server Error in '/' Application
This was another error one that appeared to be fairly common.
I had a difficult time nailing this one down because there were no apparent errors in the event viewer on the AD FS or SharePoint servers, although there were a lot of TLS related errors that were possibly related. While going through the ULS logs I saw an application error when I tried to authenticate to the site.
I know it's hard to read, essentially the error is saying that the SAML assertion (remember assertion is another word for claim) is either not signed or the signature's KeyIdentifier cannot be converted to a security token.
In plain English - the claim wasn't recognized because of a problem with the certificate. So, two things to look at here that may lead you to an answer.
- Look at your certificates in the AD FS Manager console. Make sure you document the certificate thumbprint and serial number so you can compare them to the certificates used by your trusted identity provider. Also make sure that the certificate doesn't show any errors on the Certification Path (for your lab you can just make sure all of your certificates are in the trusted root).
- On the SharePoint server, open the SharePoint Management Console (I know, Powershell) as an Administrator and run the get-SPTrustedIdentityTokenIssuer command and compare the thumbprint of the certificate in your AD FS store and the thumbprint of the certificate configured as the SigningCertificate of your trusted identity provider.
Redirected to the sign in page
This one almost broke me, I couldn't find anything meaningful via my favorite search engines, nothing in the event logs on the SharePoint and AD FS servers (the one time you REALLY want to find that error message ya know), and nothing obvious in the ULS logs. I finally stumbled across something in a blog post by Steve Peschka who I have relied on heavily (although he doesn't know it) throughout the learning process.
Anyway, in one of Steve's blog posts he mentions that if the claim being passed to AD FS is empty then a token will never be returned. This made me think about how I could identify the values I was having passed as claims. First thing that came to mind was the User Profile Service in my SharePoint farm and Active Directory. So off we go to poke around in there.
Looking at my administrators account in the Manage User Profiles page I can immediately see a problem, no email address which at the time was how the Input Type Claim was configured.
Without an email address value being passed to the STS I am not going to be able to authenticate and access my SharePoint farm. This is a problem. I know the email address is populating from somewhere, but where?
Well, let's look at my Active Directory account first and make sure that there is an email address there to start with. Sure enough, upon opening my account from the ADUC (Active Directory Users and Computers) snap-in and it showed an email address in the appropriate field.
Where can I look next? How about at what is actually being synchronized by the UPS? I'll look for my answer by opening the FIM Synchronization Service Manager at C:\Program Files\Microsoft Office Servers\15.0\Synchronization Service\UIShell. This tool will allow me to look at my user profile synchronization service and see what attributes are being pulled into SharePoint from Active Directory.
Because this is a new farm you only see a few synchronizations in the FIM client and only one full synchronization. In the FIM client I'll select the very first DS_FullImport that was done and under the Synchronization Statistics box I'll click the link for "Adds" (as you can see there were 430 users imported in my environments first full synchronization).
Clicking the "Adds" link opens the "Object Details" dialog box which lists all the objects that were synchronized by the user profile service. If I find my Administrators account, and click it once - highlighting it, I can click the "Properties" button in the lower left hand corner of the Object details box and it will open another dialog box that shows what Microsoft calls the "Connector Space Object Properties". This dialog shows you the attributes of the selected object and their value.
As you can see in the above screenshot there are two attributes that carry the firstname.lastname@example.org email address as a value. I had set up a mapped claim type to the Email claim type but AD FS doesn't do a good job of mapping that particular type for some reason (at least from what I have seen).
In our case it'll be much easier for me to configure my trusted identity provider to accept the UPN as my Identifier claim rather than trying to use email. Once I go back and rebuild, yes you'll have to remove and recreate, the trusted identity provider with the UPN as the identifier claim type I can successfully log into my SharePoint site.
"401 Unauthorized" is another fairly common error and one that can drive you a little buggy. When this happens, you can't get to a sign in page, you attempt to browse a URL in your SharePoint farm and Internet Explorer spins for a minute and then throws the following error.
Given that we didn't see a sign in page, we didn't get prompted for credentials, and we didn't get any kind of obvious SharePoint related error, the first thing I asked myself was why aren't we talking to AD FS? The error is definitely happening before we get to the authentication part of the process. My first step is to go and look at the web application and check its configuration.
When I looked at the web application I found the problem immediately - I had forgotten to enable ANY authentication on the site much less told it to use the SAML for SharePoint trusted identity provider.
Once I checked the boxes for Trusted identity provider and SAML for SharePoint I was able to log into SharePoint.
Access Denied even though you THINK you have the correct permissions
Here is another fun one that drove me up the now padded wall in my office. You've set up AD FS, configured claims and SharePoint, you've added your SAML for SharePoint account as a site collection administrator, all the bases are covered, you KNOW it's going to work so you type the address to your SharePoint site in the address bar and gleefully hit the Enter key.
You get the sign in page things are looking good! You select the SAML for SharePoint provider from the drop down on the sign in page.
Prompted for authentication, even better!!!!
NOTE: pay attention to the 1) sign in URL and 2) username format. Remember that you must have a DNS entry to resolve the sign in URL and despite the fact that we are passing the UPN value (my email address) as the identifier claim I am still going to log into SharePoint using the familiar domain\username format.
Now I know I added my administrators account and I have permissions to the site, why am I getting an access denied? Much pulling of hair ensued until it occurred to me that the identifier claim being passed was the userPrincipalName (UPN) value which is an email address. That means that when I enter an account to be resolved by the people picker so I can give that person access to SharePoint the account has to be an email address.
Back to Central Administration where I am going to re-add my administrators account using its email address in the people-picker. As you can see in the following screenshot searching for email@example.com resolves as a SAML for SharePoint account (although bear in mind that when you are using claims authentication the people-picker resolves EVERYTHING, make sure the email address is correct!)
Clicking OK adds my account as a site collection administrator and I can now access my SharePoint site without an errors.
Page can't be displayed
This error was very common and based on the sequence of events leading up to the error message it does not appear that SharePoint is even talking to the identity provider. If you watch the address bar where you would normally see the URL of the federation service come up (in my case sts.s7gear.com) the site does nothing until it goes directly to the page cannot be displayed message.
For this particular error I started by going through the ULS logs for the appropriate time period, looking for certificate or authentication related errors. You might see something like an error related to mismatched security token types, a missing server authentication certificate, verify web applications are correctly configured (pay special attention to certificates and bindings).
One of the things you have probably noticed throughout the discussion of these error messages is how many of those errors are related to certificates in some way. Much like getting workflow manager to work correctly the key to getting AD FS to successfully authenticate users is making sure all of your certificates are correct.
Hopefully these tips will help you out and point you in the right direction with any issues you are experiencing in your AD FS 3.0 implementation. Next time we'll set up the S7Gear domain to accept logins from my S7Lab domain, should be fun.
As always if you have any questions please leave them in the comments section and THANKS for reading!