I have a claims-based SharePoint 2013 site that is using a custom logon page and supports multiple authentication methods. In general, things are working as expected. Users can sign-in, access content, get the appropriate role-based claims, and so on.
However, when users connect using Excel for refreshing a query, the login page appears, but it's actually trying to take them to
error.aspx. After some investigation, this appears to happen when the user is not yet signed in to the site, so they don't have a
FedAuth token - this makes sense somewhat because the point of Excel being able to show the login page is to let the user sign in, right? But I don't see where the
error.aspx redirect is coming from, and the ULS log just shows the request for
error.aspx, not the reason for the error.
I can reproduce the issue in my development environment, which allows non-SSL, so it's easy to replicate this from a telnet session:
OPTIONS http://fqdn.for.site.here/ HTTP/1.1
HTTP/1.1 403 FORBIDDEN
Content-Type: text/plain; charset=utf-8
X-MSDAVEXT_Error: 917656; Access denied. Before opening files in this location, you must first browse to the web site and select the option to login automatically.
X-MS-InvokeApp: 1; RequireReadOnly
Date: Tue, 17 Dec 2013 17:48:58 GMT
Besides looking at the ULS log, I've also looked to see if a custom HTTP module is interfering (there is one in place to replace the Access Denied page since 2013's ability to do that "properly" is broken), but bypassing doesn't seem to change anything.
Does anyone have a thought about why my first login is trying to go against
error.aspx-, or what I can do to try to track it down further?