Kerberos and IIS6 issues

I'm seeing a problem in trying to get a web application to authenticate
cleanly and Not getting a lot of targeted errors that provide sufficient info
to troubleshoot effectively, so here I am.

Environment:
all affected systems are in a single domain run by a Win 2k3R2 server,
relatively up-to-date.
The DC is also the Kerberos server, and we have 2 other machines in this
setup.
The first is a webserver and the second is a custom application server.
Planned usage runs something like this:
From a client system you open the browser and go to the Virtual Directory
(VDir) set up on the webserver. The homepage of our client machines (hosted
by a different server), authenticates folks fine via integrated windows
authentication at this time, and as such generally no login prompts should
pop up when going to the problem webserver. This should authenticate through
via kerberos to the app server and then give the user the option to display
data via the webpage to the user, tailored based on the Windows ID.

So, instead of seeing that what I've got is the following:

1. User opens web browser, goes to homeapge and everything works fine.
2. User tries to go to the VDir hosted by the problem webserver and gets a
separate window prompting for logon. After typing in id and password
correctly three times, the webpage comes up with "Access is Denied" and
nothing else.

So, in reviewing this, I've found out a few things.
- First, the Virtual Directory appears to be properly configured. No
anonymous access, set up for Integrated Windows Authentication.
- The WebApp Pool is set to a Domain ID that in the security event logs
appears to properly authenticate using the Negotiate Package.
- The Domain Controller Verifies that the ID of the user trying to get in
Successfully authenticates as far as it's concerned, via the Security event
log on the domain controller.
- The Application server shows no failed authentication on it's end, but the
problem Webserver does:
Logon Failure:
Reason: Unknown user name or bad password
User Name:
Domain:
Logon Type: 3
Logon Process: Kerberos
Authentication Package: Kerberos
Workstation Name: -
Caller User Name: -
Caller Domain: -
Caller Logon ID: -
Caller Process ID: -
Transited Services: -
Source Network Address: 10.0.2.136
Source Port: 4558


Note iirc the port does change from time-to-time, which suggests that DCOM
might be involved? (based on DCOM's habit of changing ports, I'm assuming)

The error here shows in the problem web server's event log roughly 7 times
each attempt.

From all I can tell it looks like the data isn't making it back from the DC
to the webserver.

There is one other potential complication in that the two systems are hosted
by a cisco switch that offers VLAN capability. As a result, both are on
separate VLANs, but I can verify they can ping each other, etc.

At this time I've forced Kerberos to use TCP instead of UDP authentication
and set the token size to 65535, both to no effect. One thing that is
curious is that if the AppPool is set to use NetworkService instead of the
domain ID it at least loads the login page, which is a step further but not
what the user wants, as we lose fine auditing of data access on the app.

thoughts?

Re: Kerberos and IIS6 issues

Hi,

Have you read the following?

IIS and Kerberos Part 1 - What is Kerberos and how does it work?
http://www.adopenstatic.com/cs/blogs/ken/archive/2006/10/19/ 512.aspx

IIS and Kerberos Part 2 - What are Service Principal Names?
http://www.adopenstatic.com/cs/blogs/ken/archive/2006/11/19/ 606.aspx

IIS and Kerberos. Part 3 - A simple scenario
http://www.adopenstatic.com/cs/blogs/ken/archive/2007/01/16/ 1054.aspx

IIS and Kerberos Part 4 - A simple delegation scenario
http://www.adopenstatic.com/cs/blogs/ken/archive/2007/01/27/ 1282.aspx

A few things from your post:
a) you mention a webpage on the client, and a link to a vdir on the
webserver. The browser will not pass credentials to the webserver just
because it authenticated to some other site (your client). To avoid the
login prompts when connecting to the webserver, see:
http://support.microsoft.com/?id=258063

b) The varying ports that you are seeing probably have nothing to do with
DCOM - it's just that clients typically use ephemeral ports when connecting
to a service (e.g. when connecting to port 80 on a server, the client will
typically use a random port >1024)

c) The message in the security event log might indicate that Kerberos is
being attempted, but is failing. To work out why, you can enable Kerberos
logging: http://support.microsoft.com/?id=262177. After enabling this on
your webserver and DC, restart both machines. Alternatively, you can get a
network packet capture of the 401 packets being returned by IIS. If Kerberos
is being used, you should probably see a Kerberos error in that packet (e.g.
KRB_ERR_APP_MODIFIED or similar - which probably indicates an SPN issue)

Cheers
Ken


"trm1995" wrote in message
news:EBB13BBA-6DDD-4ADC-B696-45FCE61B92B5@microsoft.com...
> I'm seeing a problem in trying to get a web application to authenticate
> cleanly and Not getting a lot of targeted errors that provide sufficient
> info
> to troubleshoot effectively, so here I am.
>
> Environment:
> all affected systems are in a single domain run by a Win 2k3R2 server,
> relatively up-to-date.
> The DC is also the Kerberos server, and we have 2 other machines in this
> setup.
> The first is a webserver and the second is a custom application server.
> Planned usage runs something like this:
> From a client system you open the browser and go to the Virtual Directory
> (VDir) set up on the webserver. The homepage of our client machines
> (hosted
> by a different server), authenticates folks fine via integrated windows
> authentication at this time, and as such generally no login prompts should
> pop up when going to the problem webserver. This should authenticate
> through
> via kerberos to the app server and then give the user the option to
> display
> data via the webpage to the user, tailored based on the Windows ID.
>
> So, instead of seeing that what I've got is the following:
>
> 1. User opens web browser, goes to homeapge and everything works fine.
> 2. User tries to go to the VDir hosted by the problem webserver and gets
> a
> separate window prompting for logon. After typing in id and password
> correctly three times, the webpage comes up with "Access is Denied" and
> nothing else.
>
> So, in reviewing this, I've found out a few things.
> - First, the Virtual Directory appears to be properly configured. No
> anonymous access, set up for Integrated Windows Authentication.
> - The WebApp Pool is set to a Domain ID that in the security event logs
> appears to properly authenticate using the Negotiate Package.
> - The Domain Controller Verifies that the ID of the user trying to get in
> Successfully authenticates as far as it's concerned, via the Security
> event
> log on the domain controller.
> - The Application server shows no failed authentication on it's end, but
> the
> problem Webserver does:
> Logon Failure:
> Reason: Unknown user name or bad password
> User Name:
> Domain:
> Logon Type: 3
> Logon Process: Kerberos
> Authentication Package: Kerberos
> Workstation Name: -
> Caller User Name: -
> Caller Domain: -
> Caller Logon ID: -
> Caller Process ID: -
> Transited Services: -
> Source Network Address: 10.0.2.136
> Source Port: 4558
>
>
> Note iirc the port does change from time-to-time, which suggests that DCOM
> might be involved? (based on DCOM's habit of changing ports, I'm assuming)
>
> The error here shows in the problem web server's event log roughly 7 times
> each attempt.
>
> From all I can tell it looks like the data isn't making it back from the
> DC
> to the webserver.
>
> There is one other potential complication in that the two systems are
> hosted
> by a cisco switch that offers VLAN capability. As a result, both are on
> separate VLANs, but I can verify they can ping each other, etc.
>
> At this time I've forced Kerberos to use TCP instead of UDP authentication
> and set the token size to 65535, both to no effect. One thing that is
> curious is that if the AppPool is set to use NetworkService instead of the
> domain ID it at least loads the login page, which is a step further but
> not
> what the user wants, as we lose fine auditing of data access on the app.
>
> thoughts?