André Warnier wrote:
Rainer Jung wrote:
On 11.06.2010 23:21, Savoy, Melinda wrote:
I am working in my local Eclipse development environment on a Windows
XP box. (As stated in a previous post, I was able to get
authentication working in the Windows 2003 environment after talking
to a MS IIS engineer)
I just got off of a phone call with another IIS engineer at Microsoft
regarding the authentication issue again that I am getting Windows XP
and we spotted something interesting in the ISAPI log and wanted to
run it by you guys.
I've now setup my IIS and browser in Windows XP to FORCE NTLM
authentication and I am getting in the request, per the ISAPI log,
the credentials that it passes from IIS to Tomcat.
What is interesting is that it would appear that from the ISAPI log
that the AJP is returning a 401 code to the browser and therefore
executing a Windows Login prompt. Please see bolded/red type below.
This kind of "graphic highlighting" does not usually work on mailing
lists, which tend to be "pure text". If you want to highlight
something, it is better to insert some blank lines and a comment.
Below is a copy of the entries in my ISAPI log and wanted to get any
input on WHY it would appear that the redirector is returning a 401
status back to my IE or Firefox browser(?):
Because it receives a 401 response form your web application in Tomcat
and forwards the response as is to the client. So why is your web
application sending a 401?
By "application", understand the complete webapp stack, including any
servlet filters which may be configured there.
A 401 is not an error. It is the normal response of the server, in the
NTLM protocol, when trying to access a protected resource.
My guess in this case and at this point, is that it is the "legacy
filter" (jCIFS-based) which sits on top of the webapp, and which does
not check if the request is already authenticated, but returns a 401
right away. Is that a possibility ?
As an addendum, here is a link to a document which explains the NTLM
authentication handshake :
http://www.innovation.ch/personal/ronald/ntlm.html
The "NTLM Handshake" section at the beginning summarises what must
happen. As you can see, there are 2 consecutive server responses
containing a 401 "HTTP status" (not an error per se, they are a normal
part of the protocol).
However, if I follow correctly, in your case, this handshake has already
taken place once before, between the browser and IIS. Then IIS is
satisfied, and forwards the request to Tomcat, via mod_jk, including a
user-id.
If there is a further NTLM authentication layer at the Tomcat level, it
should recognise that the request is already authenticated, and not
start yet another handshake. But apparently it doesn't, and does start
another NTLM handshake sequence (with the first 401 response of the
sequence).
That probably confuses the browser, because it has already gone through
the sequence, and is already sending an "Authorization:" header with its
request. And that is probably why the browser now pops up its "Basic
authentication" login dialog.
Basically what the browser is thinking is : "oh, my NTLM authentication
doesn't work ! Let's try a Basic authentication then."
Just another note : mod_jk (or the isapi_redirector) knows *nothing* of
NTLM, nor of any authentication protocols. It just passes information
back and forth between IIS (or Apache) and Tomcat. It does not add or
subtract any HTTP headers, and does not modify the request nor the
response content.
The only thing it does in terms of authentication, is that if the
webserver has a user-id for a request, it forwards this user-id from the
webserver to Tomcat.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
