IIS 6.0 Windows Authentication 401 Every Request

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

Re: IIS 6.0 Windows Authentication 401 Every Request

On May 17, 10:12 am, cgambino
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
//

Re: IIS 6.0 Windows Authentication 401 Every Request

"David Wang" wrote:

> On May 17, 10:12 am, cgambino
> 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

Re: IIS 6.0 Windows Authentication 401 Every Request

On May 18, 8:03 am, cgambino
wrote:
> "David Wang" wrote:
> > On May 17, 10:12 am, cgambino
> > 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- Hide quoted text -
>
> - Show quoted text -


It sounds like something between the client and server is making the
request come over a new TCP connection to the server. Such as a proxy
server with connection pooling that is not NTLM aware.

Enabling Keep-Alive at IIS level and sending Keep-Alive at request
level does not assure keeping a TCP connection. It only means that the
client and server are sending HINTS that they want to keep a TCP
connection open -- cooperation of everything between client and server
is needed to actually keep a TCP connection open.

For example, if a proxy between client and server is connection
pooling, regardless of what the client sent for Keep-Alive or server
allowance for Keep-Alive, the client's request over the same
"connection" on the client side can appear as different connections
from the proxy's connection pool on the server side.

There are many things that control client and server keep-alive hints,
but most of them are not configurable by the user. The only one that
you can configure is the global "AllowKeepAlive" in IIS, where if you
set it to false you guarantee no keep-alive, while setting it to true
means you allow keep-alive but can never force keep-alive since it is
mutual agreement between client and server.


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

NTLM is potentially more performant, more fragile, and less capable
than Kerberos.

EnableKerbAuthPersist makes Kerberos similarly optimized as NTLM, with
the added bonus that Kerberos supports delegation.

I would choose Kerberos over NTLM anytime as long as you've got the
infrastructure set up. Kerberos is an excellent authentication
protocol; just expensive startup costs.


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