Taming IIS6, Application Pools, Kerberos and SPN"s

Hi.

I am working for a customer who wants to use kerberos on his application
server. He is running IIS6 on Windows Server 2003 R2.

My problem is taming it - both ensure that I understand this correctly, and
I need comments to some issues I have run into.


The overview

The client connects to the server, and receives info about how to
authenticate. Given it is trying kerberos, it connects to AD and queries for
an SPN for the service, on the format http/servername.

It asks KDC to generate a ticket for accessing the service, using the
account the SPN is registered under.

It connects to the server, using the ticket - and given the server is
running the correct account (the account the SPN is configured under), it
authenticates the client, and lets it in - if it has authorization.


What my customer really wants

To be able to control security for resources (e.g. SQL-server databases) he
wants to run different Web Sites using specific Application Pools for the
given web site. E.g.; the HR-web-services run under the HR-web-site, running
the HR ApplicationPool configured with the DOMAIN\HR-account, another site,
say "Inventory" is running Inventory-web-services under the Inventory web
site, running its application pool with DOMAIN\INVENTORY-account. HR is not
allowed to access the Inventory databases and vice versa.


What works

We have created a new site using its own port, running in the default
application pool with the user Network Service.

As a sub-site to this one, we have created the first service, with its own
Application Pool and its own user.

By disabling anonymous access, configuring the main site to "Negotiate"
using adsutil.vbs and by adding an SPN with the domain user for the custom
application pool, we are able to both identify the user on client and use the
security context of the application pool for controlling access to resources.


The problem

All documentation states that it is impossible to add the second application
pool with its separate user on the same server. The reason is said to be http
itself, but somehow I blame it on microsofts web clients. The SPN could
include port and ServiceName (allowing http-spn's to look like
http/server:port/sitename, instead of http/server). Am I missing something
here? (what information is actually used to form the query for the SPN?)

My largest problem now is that it works. When I add the second application
pool, I am allowed in on that site. It work exactly how my customer wants it
to work - the second site is restricted to the rights the registered user of
the second application pool has.

It almost looks like the web site has switched to NTLM, but that is not the
fact. After removing the SPNs and rebooting the client computer, I cannot
access the sites.

After re-adding the SPN, and then reconnecting the second site (the one for
which the account for the spn does not match the account for the application
pool) - I am allowed back in.

I have also tried to remove the SPN's adding them to the second account -
after a reboot the same happens, I am allowed back in - on both services.


So - what gives?

It is to be said that both accounts may access the database for this
specific test application. But by using WindowsIdentity.GetCurrent().Name I
get the account configured for the application pool for the service I am
accessing.

Also, by using KLIST from the resource kit, I can see that a ticket for
http/server is created. Something that puzzles me is that even though I
delete this ticket, I still can access the services, no new ticket is created
for a long time. After a long time (maybe half an hour), the ticket is back.

Another thing to note is that both applications run as a sub site of the
same main site (sharing the Site identification on which you control the type
of authentication allowed using adsutil.vbs).

I am guessing that when I try to connect to the server, all applications try
to authenticate the client using the given ticket. If one succedes, the
connection is established - and no further questions are asked. Then some
kind of tcp/ip-session holds the connection, even if the ticket is deleted on
the client.

Is this true? and if so - is this a bug? Could I rely on this behaviour,
presenting it as a way to use the web server?

The alternative is to use a separate DNS-record for each service, and
probably creating a separate main site using host header to separate the
applications. I haven't tried this yet, since I wanted to learn how this
worked first.

Thanks for any comments!


Harald Bjorøy
Umoe Consulting AS