Those of you who know SharePoint, probably also know those annoying problems you just cannot get your head around. Well today I had one of those problems.
I was in the process of configuring ADFS for SharePoint. I’m not going to go into too much detail here because that process is well documented on its own. But following all the steps, I was left with a non-working authentication scheme.
When I opened up SharePoint, I got to the “Sign In” page. That page allows you to select the login provider you want to use. After configuring ADFS, it will list Windows and ADFS (provided you had Windows / NTLM authentication beforehand). I selected the ADFS option and then – after a refresh – got the same page again. Huh?
So I checked with Fiddler and found the following course of events:
302 POST /_login/default.aspx?ReturnUrl=/_layouts/15/Authenticate.aspx?Source=%2F&Source=/
404 GET /_trust/default.aspx?trust=ADFS&ReturnUrl=/_layouts/15/Authenticate.aspx?Source=%2F&Source=/ HTTP/1.1
302 GET /Pages/PageNotFoundError.aspx?requestUrl=https://portal.contoso.com/_trust/default.aspx HTTP/1.1
302 GET /_layouts/15/Authenticate.aspx?Source=/Pages/PageNotFoundError.aspx?requestUrl=https://portal.contoso.com/_trust/default.aspx HTTP/1.1
200 GET /_login/default.aspx?ReturnUrl=/_layouts/15/Authenticate.aspx?Source=%2FPages%2FPageNotFoundError%2Easpx%3FrequestUrl%3Dhttps%3A%2F%2Fportal%2Econtoso%2Ecom%2F%5Ftrust%2Fdefault%2Easpx&Source=/Pages/PageNotFoundError.aspx?requestUrl=https://portal.contoso.com/_trust/default.aspx HTTP/1.1
There are two important things to notice here:
- There is no call to ADFS whatsoever, all URL’s pointed towards SharePoint
- Line 2 shows a 404 error on the /_trust URL
Finding the problem
I did several things trying to find out what was going wrong. First I checked the ULS logs, which didn’t reveal anything out of the ordinary. Then the IIS logs, same thing. The logging was consistent with what was happening. Then I double checked all of my configuration, which all seemed to be fine. So what the hell was wrong then?
The 404 indicates a page not found of course. Initially I thought SharePoint was throwing this error because of a fault in the configuration or something. I had checked quickly to see if the /_trust folder was on disk, which is was. For reference, that folder should be in your virtual directory path of IIS.
What the problem was
I mentioned I had checked quickly, and that was why I initially didn’t see the issue. I had two IIS web sites running for this web application; one for port 80 and one SSL secured one on port 443. Check out the folder view of both:
Notice that the first one (port 80) has the _trust folder, but the second one (443) didn’t! So that 404 error was a pretty accurate one. But why the hell would that folder be missing? I honestly have no clue.
What I did to fix it
So how do you fix a missing virtual folder in IIS? I first tried running the configuration wizard again, which usually reprovisions some stuff, that didn’t helpt. I then tried stopping and starting the “SharePoint Web Applications” service, which basically does a reprovision of everything in IIS. I made sure everything was deleted and then recreated, but weirdly that did not fix it either. So I ended up with removing the web site complete from within Central Administration and then recreating it.
And there it was! The /_trust folder appeared in IIS and all of my problems melted like snow before the summer sun. I still don’t exactly know why this went wrong, but at least the above is quite an easy fix for when it does go wrong.