3

We have a .NET MVC 3 application deployed in IIS 7 on our Windows 2008 server (let's call it PROD). The application has Anonymous and Windows Authentication enabled - all others are disabled. The authentication providers specified in applicationHost.config are Negotiate and NTLM, in this order.

Lately we've started experiencing problems with authentication in this app. Users (who are in a different domain than the server) connecting with IE with "Enable Integrated Windows Authentication" option checked get "Not Authorized. HTTP Error 401. The requested resource requires user authentication." message even though they're supplying valid credentials. When accessing application from Firefox the problem does not occur. Also when using IE with "Enable Integrated Windows Authentication" unchecked everything works fine.

From what I've read about similar issues over the Internet, I've figured out that we have some problems with Kerberos not being configured properly. It turns out that NTLM authentication works just fine. I've checked the SPNs and they seem to be configured correctly (there is the default configuration as our app is being accessed by the server's netBios name).

The funny thing is we have another server (let's call it DEV) that hosts exactly the same app and is in exactly the same domain and has the same authentication and authentication providers configuration and application pools are run under the same accounts and authentication there works just fine. The only difference is that PROD has had .NET 4 installed recently but I don't think this might be an issue. Also PROD hosts this application in IIS in a following virtual directory: Sites/XYZ/XYZ so that you access the site by url http://server:8666/XYZ. Application on DEV is hosted in IIS directly in Sites/XYZ and is accessed by url http://server2:8666.

Could you please advise me what else can I check? I tried turning on Kerberos logging but found no logs in the event viewer after trying to access the application. I have no other ideas where to look and what to check.

user155019
  • 31
  • 1
  • 1
  • 2

1 Answers1

3

First, I would confirm that this is occurring from a client where IE shows that the site is in the Trusted Sites zone, and the Trusted Sites zone is configured for "Automatic logon with current username and password."

Next, I would suspect the http authorization header size may exceed the IIS limits. Integrated Kerberos authorization is quite susceptible to this issue due to the IIS limits are actually quite low, and it does not require that many group memberships to bloat the token over the limit.

Each and every request includes the user's Kerberos token in the http authorization header. Because the token is encoded, it is frequently much larger than the actual memory used.

You can increase the values using the following document:

Http.sys registry settings for Windows
http://support.microsoft.com/kb/820129

I would use the following values:

MaxRequestBytes - set to 1048576
MaxFieldLength - set to 65534

Another useful utility DelegConfig. You can drop this in as an application on any web site, and connect to get a nice useful report on how your Kerberos authentication is configured. This would need to be tested as the victim account (or a suitably configured test account taht is exhibiting the symptom in the victim's domain).

http://blogs.iis.net/brian-murphy-booth/archive/2007/03/09/delegconfig-delegation-configuration-reporting-tool.aspx

You may also need to review:

How to use SPNs when you configure Web applications that are hosted on Internet Information Services
http://support.microsoft.com/kb/929650

Specifically:

"In Active Directory, verify that the Account is sensitive and cannot be delegated check box is cleared for users who access the application."

"Verify that all computers that are part of the Kerberos process have consistent name resolution and are connected by Kerberos trust. For example, verify that the computers that are involved in the Kerberos process are in the same forest or are part of a cross-forest Kerberos trust."

"Verify that the token size does not exceed the value that is set for the MaxTokenSize property." (MaxTokenSize should be set to 65535).

Internet Explorer 6 cannot use the Kerberos authentication protocol to connect to a Web site that uses a non-standard port
http://support.microsoft.com/kb/908209

There are also some excellent tips in the following article.

https://blogs.msdn.com/b/friis/archive/2009/12/31/things-to-check-when-kerberos-authentication-fails-using-iis-ie.aspx

In particular, checking that the client is connect to the expected SPN, using NetMon or KerbSpy.

Greg Askew
  • 35,880
  • 5
  • 54
  • 82
  • the second thing - with the size of the request -it also cannot be the case because authentication works fine for the application o nthe other server. if the request was too big, it would be for both of the sites. – user155019 Jan 18 '13 at 13:24
  • Based on that statement, I would bet $100 that it very well may be the request size. – Greg Askew Jan 18 '13 at 14:12
  • @user155019 the request in NTLM is way shorter than Kerberos, since kerberos contains the token on each request (if there is no auth peristence). Were you able to figure out the issue though? Am going through a similar issue. thx – natdico Dec 15 '14 at 21:55
  • @natdico Did increase the header length fix the problem? – Jack Jan 27 '17 at 08:55