| Groups | Blog | Home |
iis security : IIS 6.0 Windows Authentication 401 Every Request
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!
On May 17, 10:12 am, cgambino <cgamb...@discussions.microsoft.com>
[quoted text, click to view] 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. [quoted text, click to view] > 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 //
[quoted text, click to view] "David Wang" wrote: > On May 17, 10:12 am, cgambino <cgamb...@discussions.microsoft.com> > 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?
On May 18, 8:03 am, cgambino <cgamb...@discussions.microsoft.com>
[quoted text, click to view] wrote: > "David Wang" wrote: > > On May 17, 10:12 am, cgambino <cgamb...@discussions.microsoft.com> > > 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. [quoted text, click to view] > 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 //
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |