1

Having a hell of a time trying to get a .NET web app to use Kerberos auth successfully, and would appreciate some assistance from the SF community.

Currently there is a Win2003/IIS6 server hosting a web site out of the default "network service" application pool. Based on the MS How To Create a Service Account page, I performed the following steps:

  1. Created a new domain account MYDOMAIN\CustomASP
  2. Registered the account on the server with aspnet_regiis -ga MYDOMAIN\CustomASP
  3. Created new SPNs HTTP/SERVERNAME and HTTP/SERVERNAME.fqdn.here on the domain account
  4. Made an application pool MyPool running under the MYDOMAIN\CustomASP identity
  5. Created a new virtual directory MyASP running in the new app pool
  6. Made sure that SERVERNAME is in the Intranet zone, and IE has IWA enabled

According to what I've read, this is all that should be necessary. The existing site is using Kerberos and it works fine; but trying to browse to http://servername/MyASP results in a failed login attempt being recorded, and an Event 529 being written to the security log with a blank username.

NTLM authentication will work for this (tested by turning off IE's IWA or accessing the server by IP address) but Kerberos will just not work. I have the option to force NTLM and require SSL for the virtual directory, but that seems like the "ugly hack" way to fix this. Surely I'm just missing some glaringly obvious step in the procedure here caused by an epic lack of sleep.

Any help, suggestions, or stories of people who've been here and fixed it would be greatly appreciated. Thanks in advance.

2 Answers 2

0

Couple of things to try

1) Use a destkop IE. Server based IE's run differently.

2) Check your desktop patches:

3) Check your SPN

SETSPN -L MYDOMAIN\CustomASP

4) Check your Metabase

cscript adsutil.vbs set w3svc/1/NTAuthenticationProviders "Negotiate,NTLM"

5) Turn on Kerberos logging

1
  • Kerberos logging pointed to some domain trust issues with the server; evidently it didn't actually trust all of the domains it should have been according to its Group Policy settings. Also, lots of great useful info here - token bloat is always an issue it seems and I'm surprised I didn't check into it, despite that not being the culprit in this specific case. Thanks!
    – user44172
    Aug 26, 2010 at 14:57
0

Did you enable impersonation in the web.config file?

If you follow the link (http://msdn.microsoft.com/en-us/library/ms998351.aspx) in the Additional Resources section of the article you linked, it talks about enabling impersonation in ASP.NET.

1
  • I'm impersonating a fixed identity, which according to that very article is best done by setting up an app pool. I don't need to access any resources as the user, just be able to ensure that they have a valid domain login and are members of a certain domain group.
    – user44172
    Aug 20, 2010 at 14:46

You must log in to answer this question.