I have an application published via IIS 8.5 on Windows Server 2012 that can leverage Windows-integrated credentials for SSO. Users can successfully sign in to the application and navigate to the vast majority of aspx pages. However, when users attempt to sign in to a particular aspx page, they receive a Windows authentication prompt where they must populate their domain credentials 10 literal times before it allows them to access the page.
From an IIS perspective, for the app's virtual directory, we have ONLY Windows authentication specified. I can work around the problem if I turn on Anonymous Authentication (users are not prompted with the Windows Authentication prompt when they attempt to navigate to the aspx page), but this obviously breaks the end users' ability to sign in using Windows-Integrated credentials–which is unacceptable to them. As such, I suspected this was some sort of an issue with NTFS/share permissions to one of the ASPX pages or the app's DLLs. However, I've checked all of the relevant flat file permissions ad nauseum to no avail.
I have done the following:
-I have checked the permissions for the aspx page users are attempting to access, and from an AD perspective, everything seems okay. Users appear to have the correct permissions.
-The issue does not occur when signed directly in to the app server.
-Domain admins also experience the issue when signing in to the app via a client workstation.
-Run a Fiddler and Wireshark trace, and as expected, I'm encountering a 401 error.
-Issue does not occur for users who integrate into the app using non-Windows credentials.
I'm about out of ideas in terms of things I can check–does anyone else have any thoughts?
Best Answer
So, the description of the error reads:
HTTP Error 401.2 - Unauthorized: Access is denied due to server configuration.
Basically, your clients are expecting one type of authentication, and the server is not configured to provide it, so the authentication fails during the initial client-server communication where they try to negotiate an authentication method.
In my experience, this is usually a Kerberos-related problem, if for no other reason than the default settings seem to include Kerberos authentication in a non-functional state... so that's where I'd look first. Specifically, make sure that if IIS is running under a domain service account, you have an SPN (Service Principal Name) registered, which your description leads me to believe you don't.
Of course, it could also be a delegation issue, for which there are a couple KBs, or even a non-Kerberos authentication issue.
Fun times, huh? And just in case none of that does it for you, here's a goodie I hang onto that dates back to the days of 2003, but still applies for basic authentication troubleshooting. If nothing else, it should help you narrow down the issue, or perhaps workaround it by forcing a simpler authentication method on everyone.