IIS x64 in 32-bit mode Basic Auth security demands NTLM or Basic

IIS x64 in 32-bit mode Basic Auth security demands NTLM or Basic

Post by David Wan » Sat, 20 Jan 2007 20:50:50


Both valid IIS configuration and ISAPI Filters can result in the
behavior you observe. Can you validate your configuration?

WSS installs an ISAPI Filter, which can alter request/response behavior
to be inconsistent with IIS Authentication configuration.

Since Authentication protocol can be set at a per-URL basis, you must
also prove that Authentication is set correctly at the URL scopes that
you are using.

Thus, I can certainly configure IIS to respond with the behavior you
claim with either an ISAPI Filter or plain IIS configuration, and it'd
be perfectly correct according to configuration. You have to disprove
my assertions before you can consider the behavior "yet another Basic
Auth/default document bug".


//David
http://www.yqcomputer.com/
http://www.yqcomputer.com/
//
 
 
 

IIS x64 in 32-bit mode Basic Auth security demands NTLM or Basic

Post by Lou Zhe » Sun, 21 Jan 2007 01:16:58

Wow! I can see you are passionate about your work on the IIS team. That's
awesome.

You are correct, I didn't fully isolate the problem down to exact
reproducable steps. I was lazy. I was really asking if anyone had
experienced this problem. I'm pretty sure you are correct, that it is
something in the ISAPI filter stsfltr.dll because requesting
http://site/_layouts which would be served by IIS doesn't produce the
incorrect response, but requesting http://site/sites/root does, and that
would be entirely served by the ISAPI filter. I will redirect my pain and
complaint to the sharepoint team. Hopefully they have someone who has pride
in their work like you.

Cheers,
-LZ

 
 
 

IIS x64 in 32-bit mode Basic Auth security demands NTLM or Basic

Post by Lou Zhe » Sun, 21 Jan 2007 03:25:53

Solved. SharePoint uses _vti_bin/owssvr.dll to perform the redirection. Its
security was set to allow IWA.
Sorry, David. I really shouldn't have assumed it was your product at fault.

Back to the "other bug". Is there an issue with IIS, default documents,
basic auth and wildcard application mapping that could cause the auth header
to be missing the base64 encoded credentials?
-LZ
 
 
 

IIS x64 in 32-bit mode Basic Auth security demands NTLM or Basic

Post by David Wan » Sun, 21 Jan 2007 04:22:31

ildcard Application Mapping and Default Document are both interacting
behaviors of the IIS Request Pipeline, so I recommend first reading
these three blog entries to understanding how they work:
1.
http://blogs.msdn.com/david.wang/archive/2005/10/14/HOWTO_IIS_6_Request_Processing_Basics_Part_1.aspx
2.
http://blogs.msdn.com/david.wang/archive/2005/10/15/Why-Wildcard-application-mapping-can-disable-Default-Document-resolution.aspx
3.
http://blogs.msdn.com/david.wang/archive/2005/10/16/Why-Wildcard-application-mapping-is-not-catching-404s.aspx

To determine the cause of your issue, you have to determine if the
broken response came from IIS, the Wildcard Application Mapping, or an
ISAPI Filter. A common misconception is to blindly consider all three
responses to come from the "Web server" and hence it is an "IIS" issue.
However, I do not consider Wildcard Application Mapping (which is a
specially configured ISAPI Extension) nor ISAPI Filter to be "IIS"
because ISAPIs are specifically designed to alter "IIS" behavior and
are usually written by non-IIS product team.

The analogy would be like saying "if WinZip crashes while handling a
ZIP file, you complain that Windows is unstable".

Thus, it is really critical to troubleshoot to determine proper
responsibility before blaming the issue on entities like "IIS". I
understand that blame is a natural response to anger/frustration and
sometimes necessary politically, so pardon my passion -- I rather look
at the cold, hard facts instead of jumping to emotional conclusions.


Depending on IIS configuration, responding to "Default Document" could
either be made by IIS, by the Wildcard Application Mapping itself, or
by any ISAPI Filter applicable to that URL scope (either global or site
Filter). Thus, one has to verify all of those possibilities to
determine who sent/modified the response incorrectly.

Please provide:
1. The authentication protocol configuration of the URL scope in
question
2. Any wildcard application mappings effective at the URL scope in
question
3. Whether the wildcard application mapping invokes HSE_REQ_EXEC_URL
4. Any ISAPI Filters (global or per-site) applicable at the URL scope
in question

#3 is the hardest thing for most users to verify. You can either report
the ISAPI's name, or you can use a native code debugger like ntsd.exe
to set a breakpoint on w3isapi to verify that HSE_REQ_EXEC_URL is/not
invoked on the request.

My suspicion is that you have Basic auth enabled in IIS for the URL and
that the Default Document is handled by a Wildcard Application Mapping
which does not invoke HSE_REQ_EXEC_URL.


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



Lou Zher wrote:

 
 
 

IIS x64 in 32-bit mode Basic Auth security demands NTLM or Basic

Post by Lou Zhe » Sun, 21 Jan 2007 12:36:47

hanks David. I will read that WAM & DefDoc stuff.

As for your info request:
1. Everything on the entire web site is set for Basic Auth only.
2. WAM is .net v2 aspnet_isapi.dll
3. not sure, but the overall app we are talking about in this case is WSS3
4. no ISAPI filters.

I think it might be that IIS was already given the chance to do DefDoc, but
it didn't find the dir/doc because the URL hadn't been rewritten yet. I'll
do some more looking into that.

Thanks for your patience and help.
-LZ

"David Wang" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...


 
 
 

IIS x64 in 32-bit mode Basic Auth security demands NTLM or Basic

Post by David Wan » Sun, 21 Jan 2007 20:52:31

SS3 is an ASP.Net application, not ISAPI Extension. ASPNET_ISAPI.DLL
is an ISAPI Extension, and by default it does not invoke
HSE_REQ_EXEC_URL unless you write a special HttpHandler and route
requests through it.

This means the behavior you observe is pretty much by-design since you
are not talking about an ISAPI Extension designed to be a Wildcard
Application Mapping. This means that there is no "Basic Auth/default
document bug" since technically you are talking about non-designed
behavior -- which can certainly be broken because there was no design
intent to insure it works.

All this means is that you have to understand deep details of how
things actually interact between IIS6, ASP.Net 2.0, and WSS3, to
attempt to stitch together the behavior you want. None of this is
really documented since it's not meant for public extensibility, so
you'll have to reverse engineer your info from other sources...

I see no reason for IIS to strip Basic auth header from a request
handled by a WAM, so my first inclination is that some custom
HttpModule within ASP.Net is striping out the auth header prior to your
custom code.



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





Lou Zher wrote: