iis security: Hi,

We are currently switching from NTLM to kerberos on a large portal
installation which uses the IIS for SSO purposes. This is a clustered
solution so we've set a domain users as the owner of the IIS app pool
and configured the SPN so it can issue tickets on the cluster address.
We've verified that kerberos is indeed being used(kerbtray, ethereal).

After looking at the network traffic, I can see that for each url that
is requested a kerberos reauthentication is done.
To examplify:
IE sends request
GET /images/photo.jpg HTTP/1.1
Server answers
HTTP 401.2 Unauthorized
WWW-Authenticate: Negotiate
WWW-Authenticate: Kerberos
IE retries the request, now with kerberos ticket
GET /images/photo.jpg HTTP/1.1
Authorization Negotiate <KERBEROS TICKET>
Server returns content
HTTP 200
<actual data>

This is done eventhough it use the same TCP connection as the last
request to the same server (so in this case NTLM actually performs
better).

Since the portal contains of many small files (and iframe), this
actually means that the client sends more data than he received if the
ticket is to be trusted for delegation (we've removed that now and the
kerberos ticket size went from 6000 bytes to 2500 bytes, so that helped
a bit).

I've looked at the various troubleshooting guides from Microsoft on
kerberos, but haven't really found much data for who it is performed
over HTTP.

Is there any way around this limitation?
If not, is it possible to configure IE so that it sends the kerberos
ticket on the first request, so that we avoid the extra round trip?

Regards

No one says that authentication is cheap. :-)

I'm not so certain this is a "limitation". I think you are simply looking at
how Kerberos actually works. The reason it works for SSO and not NTLM is
because authentication is in the ticket and not the physical connection. The
ticket can be safely transported/proxied by untrusted intermediaries; the
connection cannot.

I'm not certain whether it is possible to configure IE to auto-send the
Kerberos ticket. Seems like it should and is the only optimization possible
to remain "Kerberos". But you can optimize the network size of the 401.2
traffic (clamp down on the custom error file) such that it is not really
significant.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
[quoted text, click to view]
Hi,

We are currently switching from NTLM to kerberos on a large portal
installation which uses the IIS for SSO purposes. This is a clustered
solution so we've set a domain users as the owner of the IIS app pool
and configured the SPN so it can issue tickets on the cluster address.
We've verified that kerberos is indeed being used(kerbtray, ethereal).

After looking at the network traffic, I can see that for each url that
is requested a kerberos reauthentication is done.
To examplify:
IE sends request
GET /images/photo.jpg HTTP/1.1
Server answers
HTTP 401.2 Unauthorized
WWW-Authenticate: Negotiate
WWW-Authenticate: Kerberos
IE retries the request, now with kerberos ticket
GET /images/photo.jpg HTTP/1.1
Authorization Negotiate <KERBEROS TICKET>
Server returns content
HTTP 200
<actual data>

This is done eventhough it use the same TCP connection as the last
request to the same server (so in this case NTLM actually performs
better).

Since the portal contains of many small files (and iframe), this
actually means that the client sends more data than he received if the
ticket is to be trusted for delegation (we've removed that now and the
kerberos ticket size went from 6000 bytes to 2500 bytes, so that helped
a bit).

I've looked at the various troubleshooting guides from Microsoft on
kerberos, but haven't really found much data for who it is performed
over HTTP.

Is there any way around this limitation?
If not, is it possible to configure IE so that it sends the kerberos
ticket on the first request, so that we avoid the extra round trip?

Regards

Thanks for your response David,

I've allready stripped the 401.2 error page to 200 bytes, so my main
concern is that the client sends too much data.

Regards
Dagfinn