iis 5.0 running as domain account

[Scott Walters]

Hi,

I'm trying to get delegation to work in my asp.net 2.0 web service. I've
had the domain admins enable delegation for the web service machine but
when I switch the iis service to run as a domain account instead of
local system, I can't get in anymore from a remote machine. Internet
explorer immediately pops up an authentication dialog and nothing I put
in will work, even if it's the same domain account that the service is
running under. I enabled the logon/logoff audits and this is what the
events look like...

Logon Failure:
Reason: Unknown user name or bad password
User Name:
Domain:
Logon Type: 3
Logon Process: Kerberos
Authentication Package: Kerberos
Workstation Name: -

The web service uses windows impersonation and I'm logging in with a
domain user that's a local admin on both machines. I've downloaded the
utilities to display kerberos tickets & spns but I can't really make
anything out of their output.

Thanks,
Scott

 

[Scott Walters]

I've fixed this by running aspnet_regiis for the domain account and
clearing the ticket cache. Now I can get to the web service but I still
can't stop/start the remote service from the web service code. The
events seem to indicate that it's authenticating with ntlm instead of
kerberos. I thought the articles I've read indicate that if you use a
netbios name, you don't have to add an spn. Is this right? Why else
would it use ntlm?

Thanks,
Scott

 

[Joe Kaplan \(MVP - ADSI\)]

You need SPNs when you are doing Kerberos auth always. Since you are using
IIS5, you will need to be doing Kerberos to Kerberos auth (no protocol
transition or S4U authentication), so you have to ensure that you are
getting Kerberos auth from the client to the web server and Kerberos auth
from the web server to the remote service. If you are using NetBIOS names,
that just implies that you need proper SPNs for your services that include
those NetBIOS names.

Joe K.

 

[Scott Walters]

I got a domain admin to add an spn using the cmd

setspn -A http/{netbios name} {domain}\{domain user}

which seemed to work, but the security event log still says it's using
ntlm, plus I don't get a ticket in the kerbtray.

Now that I have the IIS service running under a domain account, what
else can I check for this?

 

[Joe Kaplan \(MVP - ADSI\)]

The first step is to ensure that you are getting Kerberos auth between the
browser and the web server. Then you can try to make sure you get Kerberos
auth between the web server and the remote service.

Once you have the SPN set and the browser is using a name in the URL that
matches the SPN name, then you should just need to make sure that IIS is set
for IWA auth only (no basic, digest or anon) and is asking for Negotiate
auth and not just NTLM and that the browser's security settings are set to
do integrated auth.

To verify whether IIS is asking for Negotiate or just NTLM, I like to use a
plugin that lets you see request/response headers like IE HTTP Headers
(www.blunck.info, freeware!) or use a tool like wfetch.exe from the IIS 6
res kit (also free and very useful). Essentially, if IIS gives you a 401.1
response and includes a WWW-Authenticate that says "Negotiate" and not
"NTLM". If you are only getting NTLM, then you need to update your IIS
metabase to change the setting to use NTLM. There are some kbase articles
that describe how to do that.

Once you get that working, then you should have Kerberos on the front end.
You should also get Kerberos on the backend if the SPNs match up and the
backend service allows Kerberos auth. As usual, enabling logon event
auditing and carefully watching the security event logs is the most useful
technique to find out what's going on. Also, watching the system event log
for errors from Kerberos can be useful.

HTH,

Joe K.

 

[Joe Kaplan \(MVP - ADSI\)]

On other thing: make sure that when that SPN got added to the domain account
that it did not accidentally duplicate an existing SPN that a machine
account held. If so, Kerb. won't work for either. SPNs must be unique in
the forest. You can use an LDAP query tool like ldp.exe or adfind to try to
discover this.

If you do have a problem with duplicate SPNs, that will usually manifest
itself as a Kerberos error in the system event log saying something about
AP_MODIFIED, which says that a ticket was generated with credentials that
the service account could not decrypt (since it was created for a different
account).

I don't think that's the problem here since you are getting NTLM instead of
Kerberos, but it is something to watch for.

Joe K.