Re: IIS 6.0 Windows Authentication 401 Every Request



"David Wang" wrote:

On May 17, 10:12 am, cgambino <cgamb...@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:
Hello,

After reading a lot of articles, I was finally able to get Kerberos and NTLM
both working for an internal server.

I'm not sure if this is supposed to work this way, but it seems that on
every request to a page, it'll throw a 401, and then the next request
authorize the same page.

NTLM was doing this often, but not every page. Once I got Kerberos working,
it was doing it on every request.

Is there some more configuration I need to do? Is this the way that this is
intended to work? I assume that the ultimate goal is to have 1
authentication, and have that work for the rest of the session.

Any tips would be greatly appreciated!

Thanks


What you do depends on the type of 401.
- If it is 401.1, then it's probably more IIS configuration or network
issue
- If it is 401.2, then it's probably a client-side issue or network
issue
- If it is 401.3, 401.4, or 401.5, then the configuration is not with
IIS but at server-side application.


I assume that the ultimate goal is to have 1 authentication
and have that work for the rest of the session.

This assumption is mistaken. Once a resource requires authentication,
the client must prove authenticated access on every request in order
to succeed. It is up to the client to provide evidence, and the
evidence depends on the authentication protocol.

For Basic, Digest, Kerberos, and Cookie-based custom auth (such as
ASP.Net Forms auth), proof is to send over username:password in some
form (or abstracted as Kerberos ticket in Kerberos case) on every
request, and the client must remember to do that.

For NTLM, proof is continued anonymous request over the originally
authenticated connection, and the client and server must remember
that.

Tips are not really helpful because it really depends. You need to
provide more precise information on the type of 401, authentication
protocol used on the request, and whether authorization is passed on
the request (as expected) or connection maintained.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//



Thanks for your comments David,

I read that there were 2 settings in IIS 6.0 for W2K3 SP1 that you could
set, neither of which helped:

EnableKerbAuthPersist in the registry - Is supposed to make requests
continue over a connection.

AuthPersistence in the metabase - Is supposed to make NTLM requests continue
over a connection.

I was looking into this a bit further yesterday, and came across the
following issues:

The requests the 2nd time, fail with the 401.2 error (both Kerberos & NTLM).
In tracing the network traffic, I noticed that the authorization ticket was
not being sent over on subsequent requests. As you mentioned, it seems that
IE6, IE7, and FireFox do not 'remember' to continue to send credentials. Is
there a setting which will allow this?

As far as if the connection maintained, I'm not sure. Keep-alive is enabled
on my IIS sites, and the http requests all have keep-alive in the headers.

In terms of network traffic & performance, is NTLM better than Kerberos?

Are there things I can look at configuration wise to determine where the
disconnect is happening which makes the client & server 'forget' about the
authentication?

Thanks
.

Relevant Pages

  • Re: Each HTTP object being requested twice (401 then 200 responses)
    ... Authentication" and the web.config authentication setting is ... Authorized because the request was made anonymously. ... requests the same object a second time it uses kerberos; ... Kerberos tokens should not be regenerated for every request. ...
    (microsoft.public.inetserver.iis.security)
  • RE: HttpWebRequest over Https Via Proxy Fails using NTLM
    ... The proxy authentication header returns Basic, NTLM, and Negotiate. ... A network trace shows that the https request handshake is as follows: ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Each HTTP object being requested twice (401 then 200 responses)
    ... Authentication" and the web.config authentication setting is ... Authorized because the request was made anonymously. ... requests the same object a second time it uses kerberos; ... Kerberos tokens should not be regenerated for every request. ...
    (microsoft.public.inetserver.iis.security)
  • Re: Integrated Windows Authentication Timeout?
    ... Is it possible that a different host name is being used for one of the subsequent requests that would break Kerberos auth? ... If you have "Negotiate" authentication set in the metabase, then this can still negotiate down to NTLM if for some reason the protocol thinks that Kerberos is unavailable. ... server. ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: Each HTTP object being requested twice (401 then 200 responses)
    ... Authentication" and the web.config authentication setting is ... Authorized because the request was made anonymously. ... requests the same object a second time it uses kerberos; ... pass a session ID cookie and therefore succeed the first time. ...
    (microsoft.public.inetserver.iis.security)