IIS Authentication bug?

I have an application that is accessed via a Java Servlet, and so in an
IIS environment we have the Jakarta redirector ISAPI filter connecting
to Tomcat. This all works perfectly.

Now our application has its own username data store and so we want to
use that as the basis for authentication. We can set the appropriate
WWW-Authenticate: Digest headers in our code and these get passed back
to the browser (or other client). And this indeed works in a non-IIS
environment.

But with IIS, we are seeing additional WWW-Authenticate headers being
put into the response and this is causing problems with the browser.

In IIS, the directory security is set to Anonymous and every other
authentication item is turned off. We don't want the web server doing
any of the work, we just want the authentication headers to pass
untouched between our application and the browser. But even though
we've told IIS to leave along, it insists on adding "WWW-Authenticate:
Negotiate" and "WWW-Authenticate: NTLM" headers.

After much searching I finally tracked this down to the
NTAuthenticationProviders setting in the metabase. But the
documentation for this
(http://www.microsoft.com/resources/documentation/iis/6/all/ proddocs/en-us/ref_mb_ntauthenticationproviders.mspx)
says:

"When Integrated Windows authentication is enabled, ..."

I don't have Integrated Windows authentication enabled. Nowhere. The
value of AuthFlags for w3svc is 1 and it is also 1 for my virtual
directory.

The workaround is to either set NTAuthenticationProviders to a null
string (with obvious consequences for other applications in the same
site).


So it appears that IIS is really looking through the response headers
for WWW-Authenticate and decides to muscle on in, despite no reason to
and contrary to the documentation.

--
Andy

Re: IIS Authentication bug?

I cannot reproduce this.

I setup a vdir with only anonymous authentication and
NTAuthenticationProviders remains at the default unset value (not
empty-string).

- I wrote an ISAPI Extension that sends back WWW-Authenticate: Digest
header on the response, and I do not see any extra WWW-Authenticate headers
- I wrote an ISAPI Filter to also send back WWW-Authenticate: Digest header
on the response, and I also do not see any extra WWW-Authenticate headers

In addition, on the requests, I sent Authenticate: headers to attempt to
entice IIS to authenticate (even though only anonymous authentication is
enabled, so Authenticate: headers should be ignored).

This should cover all possible actions that your Java connector stack could
do on IIS.


Is there any other possibility you can think of -- because it does not look
like an IIS issue to me.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
wrote in message
news:1109899303.291053.323240@l41g2000cwc.googlegroups.com.. .
I have an application that is accessed via a Java Servlet, and so in an
IIS environment we have the Jakarta redirector ISAPI filter connecting
to Tomcat. This all works perfectly.

Now our application has its own username data store and so we want to
use that as the basis for authentication. We can set the appropriate
WWW-Authenticate: Digest headers in our code and these get passed back
to the browser (or other client). And this indeed works in a non-IIS
environment.

But with IIS, we are seeing additional WWW-Authenticate headers being
put into the response and this is causing problems with the browser.

In IIS, the directory security is set to Anonymous and every other
authentication item is turned off. We don't want the web server doing
any of the work, we just want the authentication headers to pass
untouched between our application and the browser. But even though
we've told IIS to leave along, it insists on adding "WWW-Authenticate:
Negotiate" and "WWW-Authenticate: NTLM" headers.

After much searching I finally tracked this down to the
NTAuthenticationProviders setting in the metabase. But the
documentation for this
(http://www.microsoft.com/resources/documentation/iis/6/all/ proddocs/en-us/r
ef_mb_ntauthenticationproviders.mspx)
says:

"When Integrated Windows authentication is enabled, ..."

I don't have Integrated Windows authentication enabled. Nowhere. The
value of AuthFlags for w3svc is 1 and it is also 1 for my virtual
directory.

The workaround is to either set NTAuthenticationProviders to a null
string (with obvious consequences for other applications in the same
site).


So it appears that IIS is really looking through the response headers
for WWW-Authenticate and decides to muscle on in, despite no reason to
and contrary to the documentation.

--
Andy

Re: IIS Authentication bug?

Umm, interesting.

Here's my setup:
On a WXP box I have both Apache (port:80) and IIS (port:81). Both
redirect certain URLs to Tomcat hosting a Java Servlet (that then
redirects them on to another layer). I've put Tomcat on a different
machine to make it easier to trace the AJP13 protocol. Therefore from
Tomcat onwards, the execution path is exactly the same.

I'm using Firefox and am tracing packets with Ethereal.

Issuing the request on port 80 (Apache) I get this response...

HTTP/1.1 401 Unauthorized
Date: Fri, 04 Mar 2005 21:56:25 GMT
Server: Apache/2.0.46 (Win32) PHP/4.3.9 mod_jk/1.2.0
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Language: en-US
Cache-Control: no-cache
WWW-Authenticate: Digest realm="Web Services@daedalus.unival.com",
nonce="5f2825520d0bd401d454f7aba8552f58", algorithm="md5", qop="auth"
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html;charset=ISO-8859-1

Issuing the same request on port 81 (IIS), I get this response...

HTTP/1.1 401 Unauthorized
Server: Microsoft-IIS/5.1
Date: Fri, 04 Mar 2005 21:56:36 GMT
Connection: close
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
Content-Type: text/html;charset=ISO-8859-1
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Language: en-US
Date: 04-mar-05 13:56:36
Cache-Control: no-cache
WWW-Authenticate: Digest realm="Web Services@daedalus.unival.com",
nonce="19db0990d42d0e8b58dd73548e5c52fb", algorithm="md5", qop="auth"

The only variable is the web servers, and so the only way the extra
WWW-Authenticate headers can appear is if IIS adds them. And through
the packet trace of the AJP13 traffic, the response back from Tomcat is
identical for both requests.

Now maybe I'm missing a setup option in IIS, but I cannot see it. This
was a brand new install and I only have the one virtual directory, so
there's not much to check. And as I said in my first message AuthFlags
is set to 1 everywhere.

(Incidently we have a customer who is experiencing the same problem
with IIS6 - I just didn't have that version set up.)

--
Andy

Re: IIS Authentication bug?

My experiments were with IIS6 and IIS5 (comparable to IIS 5.1 codebase).

The response you are getting back from IIS is quite similar to what I could
get back if I had AuthFlags set to NOT be Anonymous and then trigger the 401
response, either by sending a 401 response header or by letting
authentication happen. I cannot make this happen if AuthFlags is set to 1.
Hmm...

The default AuthFlags value is 5 (inherited), so please make sure it is set
to 1 at the ALL levels (I want to make sure it applies to the URL that
Tomcat steals from IIS). I have no idea what that URL looks like, but make
sure AuthFlags does NOT contain 4 for that URL namespace.

I suspect it is either:
1. User Configuration error that has AuthFlags=4 applicable somewhere in the
URL that Tomcat redirects
2. IIS bug with requests containing Authentication: when its AuthFlags is 1
3. Tomcat redirector bug with how it is stealing requests from IIS and
subsequent interactions

If you are pretty sure this is an IIS issue, you can contact Microsoft PSS
with the info and open a case with them -- IIS bugs should not cost you any
money. The information that is really critical are the ISAPI Filter
events+function calls+data on the function calls as well as IIS server
configuration for the URLs involved.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
wrote in message
news:1109975819.842216.50370@g14g2000cwa.googlegroups.com...
Umm, interesting.

Here's my setup:
On a WXP box I have both Apache (port:80) and IIS (port:81). Both
redirect certain URLs to Tomcat hosting a Java Servlet (that then
redirects them on to another layer). I've put Tomcat on a different
machine to make it easier to trace the AJP13 protocol. Therefore from
Tomcat onwards, the execution path is exactly the same.

I'm using Firefox and am tracing packets with Ethereal.

Issuing the request on port 80 (Apache) I get this response...

HTTP/1.1 401 Unauthorized
Date: Fri, 04 Mar 2005 21:56:25 GMT
Server: Apache/2.0.46 (Win32) PHP/4.3.9 mod_jk/1.2.0
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Language: en-US
Cache-Control: no-cache
WWW-Authenticate: Digest realm="Web Services@daedalus.unival.com",
nonce="5f2825520d0bd401d454f7aba8552f58", algorithm="md5", qop="auth"
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html;charset=ISO-8859-1

Issuing the same request on port 81 (IIS), I get this response...

HTTP/1.1 401 Unauthorized
Server: Microsoft-IIS/5.1
Date: Fri, 04 Mar 2005 21:56:36 GMT
Connection: close
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
Content-Type: text/html;charset=ISO-8859-1
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Language: en-US
Date: 04-mar-05 13:56:36
Cache-Control: no-cache
WWW-Authenticate: Digest realm="Web Services@daedalus.unival.com",
nonce="19db0990d42d0e8b58dd73548e5c52fb", algorithm="md5", qop="auth"

The only variable is the web servers, and so the only way the extra
WWW-Authenticate headers can appear is if IIS adds them. And through
the packet trace of the AJP13 traffic, the response back from Tomcat is
identical for both requests.

Now maybe I'm missing a setup option in IIS, but I cannot see it. This
was a brand new install and I only have the one virtual directory, so
there's not much to check. And as I said in my first message AuthFlags
is set to 1 everywhere.

(Incidently we have a customer who is experiencing the same problem
with IIS6 - I just didn't have that version set up.)

--
Andy

Re: IIS Authentication bug?

I'm fairly new at using Windows Server 2003, but I had what appears to be the
same problem with an ASP.NET application that was supposed to allow anonymous
access and use forms authentication. It kept promting me for the Windows
username and password. After trying everything I could read about, I looked
at the IE settings on my machine. In Internet Explorer, I went to
Tools-Internet Options-Securitiy-Internet Zone-Custom Level-User
Authentication, and selected "Anonymous Logon". After that I quit getting the
Windows username and password prompt. The thing that finally clued me in was
that when I tried Mozilla, the prompt wasn't happening, so then I knew it was
some setting in IE.

Re: IIS Authentication bug?

It sounds like you:
1. still have IIS configured with Integrated Authentication enabled
(somewhere) because that was what IE was prompting about
2. Or something running on IIS is adding those WWW-Authenticate headers.

The browser's behavior corroborates with your current situation with
Tomcat -- something is adding WWW-Authenticate headers.

The three prior reasons that I gave still apply -- either you have a
configuration issue, IIS issue, or 3rd party ISAPI Filter issue. You can
certainly verify that after you stop IIS that AuthFlags property in
metabase.xml do *not* include "4" as a bitmask. (i.e. everything looks like
1, not 5 [1+4] or 7 [1+2+4]) to check your configuration. Then it is your
choice between obtaining support for Tomcat's isapi_redirect.dll (and any
other ISAPI Filter you have on the system) and IIS.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Computogeek" wrote in message
news:544E6FB1-6DD7-4CBA-BA77-FE0ED988A107@microsoft.com...
I'm fairly new at using Windows Server 2003, but I had what appears to be
the
same problem with an ASP.NET application that was supposed to allow
anonymous
access and use forms authentication. It kept promting me for the Windows
username and password. After trying everything I could read about, I looked
at the IE settings on my machine. In Internet Explorer, I went to
Tools-Internet Options-Securitiy-Internet Zone-Custom Level-User
Authentication, and selected "Anonymous Logon". After that I quit getting
the
Windows username and password prompt. The thing that finally clued me in was
that when I tried Mozilla, the prompt wasn't happening, so then I knew it
was
some setting in IE.

Re: IIS Authentication bug?

OK, I've now learnt more about the Tomcat redirector and have
discovered the problem, and I'm, going to document it here for all to
see (and find in the future).

The redirector is both an ISAPI Filter and an Extension. The filter is
invoked for each request coming into IIS and if the URI matches a
pattern defined in the uriworkermap.properties, then the filter changes
the initial request URL to what ever is defined as the "extension_uri"
(this is part of the redirector registry settings). The default value
is /jakarta/isapi_redirect.dll". The filter also stashes the original
URI in the header for later.

IIS now handles the new redirection URL and notices it as an ISAPI
Extension, and it is this extension that actually communicates with
Tomcat.

But part of the setup involves creating a virtual directory to match
the extension_uri, and of course has its own metabase settings and
hence security settings. I was completely ignoring this directory. When
the virtual directory was created it would have inherited the
authentication settings in place at that point in time (which was
AuthFlags=5).

So in summary if you have a java servlet managing authentication
outside of IIS then you need to ensure anonymous access is defined not
only for your application's virtual directory but also for the Jakarta
redirector's virtual directory because both of them will apply.

Thanks for the help.

--
Andy

Re: IIS Authentication bug?

Thanks for the details. What you have said makes technical sense to me.

This seems like a bug in the isapi_redirect setup that you should report to
Tomcat folks.

It should create a virtual directory that *inherits* Authentication settings
instead of overwriting with its own. Most of the time, when it redirects,
it wants to pick up the original settings and not its own. By default, when
you create a virtual directory, it inherits all settings other than the
virtual-to-physical path mapping -- so this looks like a isapi_redirect
setup problem to me.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
wrote in message
news:1110231909.054742.146660@g14g2000cwa.googlegroups.com.. .
OK, I've now learnt more about the Tomcat redirector and have
discovered the problem, and I'm, going to document it here for all to
see (and find in the future).

The redirector is both an ISAPI Filter and an Extension. The filter is
invoked for each request coming into IIS and if the URI matches a
pattern defined in the uriworkermap.properties, then the filter changes
the initial request URL to what ever is defined as the "extension_uri"
(this is part of the redirector registry settings). The default value
is /jakarta/isapi_redirect.dll". The filter also stashes the original
URI in the header for later.

IIS now handles the new redirection URL and notices it as an ISAPI
Extension, and it is this extension that actually communicates with
Tomcat.

But part of the setup involves creating a virtual directory to match
the extension_uri, and of course has its own metabase settings and
hence security settings. I was completely ignoring this directory. When
the virtual directory was created it would have inherited the
authentication settings in place at that point in time (which was
AuthFlags=5).

So in summary if you have a java servlet managing authentication
outside of IIS then you need to ensure anonymous access is defined not
only for your application's virtual directory but also for the Jakarta
redirector's virtual directory because both of them will apply.

Thanks for the help.

--
Andy