4

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?

Solomons_Ecclesiastes
  • 141
  • 1
  • 3

2 Answers2

0

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.

HopelessN00b
  • 53,385
  • 32
  • 133
  • 208
  • Thx--I'm pretty sure IIS is not running under a domain service account, but I'll double check to see whether it is so I can look into whether an SPN is registered. I also found an article that suggested we may be able to add individual domain users to one of the IIS config files to work around the authentication issue. You wouldn't happen to be aware of where one might set this? – Solomons_Ecclesiastes Mar 03 '14 at 22:50
  • @Solomons_Ecclesiastes Not sure what that's about, no. When I've had to "workaround" this type of problem in the past, I've done so by manually setting the authentication type on the server and the clients. – HopelessN00b Mar 04 '14 at 12:08
0

Ultimate resolution to this issue was found in IE settings. When we checked the option to check for newer versions of stored pages at every visit, this caused the issue to disappear. When re-enabling it, the issue reappeared.

Solomons_Ecclesiastes
  • 141
  • 1
  • 3