[SP2013] SharePoint, ADFS and 404 on /_trust/default.aspx
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.
Introduction
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.
The symptoms
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.
September 30, 2015 at 3:52 pm |
For the resolution you could also use the Provision method for SPWebApplication in PowerShell: https://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spwebapplication.provision.aspx
Example:
#Run this on the affected server
$webApp = get-spwebapplication http://webappurl/
$webApp.Provision()
#If this needs to be ran on more than one server you could use $webApp.ProvisionGlobally() instead
September 30, 2015 at 6:24 pm |
Thanks for sharing, Andrew!
September 30, 2015 at 4:02 pm |
[…] http://blog.repsaj.nl/index.php/2014/07/sp2013-sharepoint-adfs-and-404-on-_trustdefault-aspx/ […]
March 16, 2016 at 9:16 pm |
Using SP2013 with aurhetication through ADSL and giving us a hard time. Bing’ing we came across this post. We have a timeout problem. Nasty is it works 80%, but sometimes not. Looping in this Authenticate.aspx?Source= Workaround tends to go towards revocation check on the certs used. Server are not alowed to connect to the internet.
March 17, 2016 at 7:50 am |
Hi Roeland,
“sometimes not” doesn’t sound like a certificate check issue. Certificate checking happens server side and doesn’t need an internet connection as long as you have the proper certificates (root, intermediate) installed on the server. When the date expires, all check should fail and revocation only works when the certificate list on the server itself it updated somehow. Do the users get redirected to ADFS in the first place? Debugging procedure would be to recreate the problem and check the Fiddler output on the client, along with the server logs. That should at least give an indication to what’s happening (or what’s not). Could be a timeout problem somewhere, but without any info it’s hard to guess.
May 31, 2016 at 5:59 pm |
Thank you for update. We have used a workaround and set the url for the crl of the signing cert by ADFS , like crl.globalsign.net, in hosts to 127.0.0.1. No more claim authentication related errors.Compare with what most do for crl.microsoft.com to avoid timeouts in SharePoint due to crl checks. Now we have enabled access to the internet for our SharePoint servers. Always a good idea but often not allowed. We convinced security that passing through a webproxy using a well known whitelist is okay. They agreed.
We have seen your issue, missing foilder or file, several times now. In SP2013 there simply seems not enough time/resources to create and configure all files in the VirtDirs when you extend or change an AuthProvider. You are just lucky when reprovision works. Yes we are highly charging the system with 8 pools and 15 webapps but that is really is not a lot when you talk to IIS experts. SP2013 has issues with this. Cannot find reason why, and believe me, turned these boxes upside down and check every bit.
August 23, 2016 at 2:53 am |
Our /_trust folder is not missing. However, when we navigate to our sharepoint and select the adfs login option the browser navigates to /_trust/default.aspx, but it comes back missing 404 page not found. We have checked the /_trust folder on the server and it is there and the “missing” default.aspx page is also there. Any ideas as to why we cannot navigate to the default.aspx page and redirect to our adfs login?
August 25, 2016 at 9:35 am |
Any 404 error should be logged in IIS server logs, so you might want to check those for more information. Have you checked both the folder on disk and the existance of the correct virtual directory in IIS? Also note that when your farm consists of multiple (front-end) servers, you’ll need to check all of them individually.
November 8, 2016 at 8:48 am |
We are still having this issue. We know now that even if the “/_trust/”-virtual dir and files are there it gives you a 404. Root cause is that “everyone” is missing from the security on the files. You can push this by hand. Strong indications that the changes requested by SharePoint to either IIS (process= inetinfo.exe) or the file system (System) is not completed fully.
November 8, 2016 at 11:58 am |
I would always recommend to ensure that a server that is provisioned by SharePoint in the end has a correct configuration. So although certain things can be corrected by hand, try to resolve the cause of the issue instead of the symptoms. For farms with multiple servers; try to unprovision the server completely and then reprovision it. If the problem repeats itself, see whether a change in role configuration brings any difference.
February 13, 2017 at 6:43 pm |
Hi all
On my farm _trust folder is created but it’s not inheriting Everyone Read permission from parent. Env with Provision() is doing the same. Parent folder has Everyone Read permission and it’s applied to subfolders. Any ideas why it’s happening this ?
February 20, 2017 at 6:33 pm |
That is strange. Maybe check the permissions on the folder in the SharePoint hyve? Although those should be the same on all servers of course, could be that something is different there for whatever reason. Otherwise I don’t know what could be causing that, might be worth a call to Microsoft Support?
August 26, 2020 at 5:35 pm |
Since we were adding automatisation into sharepoint with a script that sets our custom STS trust, we added a section in powershell that set inheritance to the newly created virtual directory /_trust/ and it fixed everything. Thanks for the clue!