Last week I worked with a client to solve an issue they were having with a new ASP.NET 4.x application they had created using Visual Studio 2015. Their site is set up so that all of the authentication occurs through a shared, single-sign on, web site. Individual web projects are then hosted as subdomains which share the authentication cookie. It looks something like this:
admin.foo.com (root, includes login)
app1.foo.com (authenticates from admin.foo.com)
app2.foo.com (authenticates from admin.foo.com)
app3.foo.com (authenticates from admin.foo.com)
They’ve been upgrading their systems to take advantage of the latest version of .NET and Visual Studio 2015, and a couple of the existing ASP.NET apps had been upgraded to ASP.NET 4.6 without issue. However, when they added a new ASP.NET project, setting it up just as the others, it refused to recognize the authentication cookie.
The solution in our case turned out to be to set the compatibilityMode to “Framework45” in the new project’s web.config, on its machineKey setting:
<machineKey compatibilityMode="Framework45" />
It took us a couple of hours of troubleshooting to track this down. We checked that the cookie was being set, and that its domain was set correctly. We checked the machineKey, to make sure they were the same between the root project that issues the cookies and the app. We compared everything we could between the new web project and an existing one which the dev team had recently upgraded, and which was able to authenticate just fine.
What finally led us in the right direction was to check the event log, where we found errors claiming “401.2: Unauthorized: Logon failed due to server configuration”. It would have been a bit more helpful if it had told us something more specific about the server configuration, but eventually we tracked it down.
I’m not sure why the upgrade path (for ASP.NET runtime version) didn’t result in the same problem as creating a new project did. Clearly something must be different. At the end of the day, though, we had other features that needed done so having fixed the issue in this case, we didn’t try to track it down further.