Problem is def due to my misconfig on Tomcat. I am very confident of the
Workstation. It does WIA successfully with IIS 6, 7.5, and 8 and with the
Sourceforge SPNEGO implementation..
Sent from my Windows Phone
________________________________
From: André Warnier
Sent: 05/03/2013 20:40
To: Tomcat Users List
Subject: Re: Tomcat Built-in WinAuth - NEW THREAD
Hi.
Your message appears quite garbled in my email client.
Some notes in the text below, which I have reformated somewhat.
Chris Fors wrote:
> I have added in a <security-constraint> to the sample application web.xml
> (shown below)
and modified the hello.jsp to show a request.getRemoteUser().
This has shown to successfully invoke an authentication process.
Now when browsing to the http: //server/sample I receive a Windows prompt
for user logon.
That, in my view, is a sign that something is not as it should.
If a real Windows Integrated Authentication (WIA) was taking place, you should
not see a
login dialog.
The browser instead should negociate this directly with the server, using your
Windows
login credentials, and nothing should be visible to the user.
If a login dialog appears, I believe that it is because the browser is falling
back to
attempting a HTTP Basic Authentication. Which may work or not, depending on
whether your
Windows Domain policies (and your server) allow it or not.
This is with IE9 and the browser is configured for autologon for the
Intranet zone
The "autologon" is obviously not working, if you see a login dialog.
and the server is in the Intranet zone.
And there are 401 errors in the localhost_access.log: 10.208.101.129 - -
[05/Mar/2013:16:25:21 +0000] "GET /sample/ HTTP/1.1" 401 951
401 responses are not "errors", they are a normal part of the exchange.
(It means kind of "show me some id, buster")
Roughly, it works as follows :
1) the browser tries to get a protected resource, which is marked (on the
server) as
requiring authentication. But the browser at first doesn't know that, so it
sends a first
request without any form of authentication.
2) the server sees that the resource needs authentication, and that the request
does not
contain an authentication. So it sends back a 401 response.
This is to indicate to the browser that an authentication is required.
If you examine the headers that the server is sending back, you will see that
it even
indicates to the browser which form(s) of authentication is required/accepted.
3) the browser sees the 401 response, and start an authentication cycle.
There are variations of this at this point.
If the browser decides to use WIA (what you call autologon I guess),
3a) it will first re-send the request along with a token;
3b) the server will respond with a new 401 including a token of its own
3c) the browser will then re-send the request again, with a final token
(Yes, it takes 3 such steps to do a WIA authentication, not counting the
server's own
conversation with a Domain Controller)
3d) if the server determines that the provided credentials fit, the server
returns the
requested resource in a 200 OK response. Otherwise it returns a 403 Forbidden.
If the browser instead decides to do a Basic Authentication,
3a) the browser will popup a login dialog to the user, asking for id/pw
3b) the browser will then re-submit the original request along with a
"Authorization:
Basic" header, including the id/pw encoded.
3c) if the server determines that the credentials match, it will return the
requested
resource in a 200 OK response. Otherwise it returns a 403 Forbidden.
In any case, 401 responses from the server are a normal part of the processes
above.
It's only 403 Forbidden that you should worry about.
And the fact that apparently it is not really doing "autologon".
(But maybe this is a feature of the Tomcat SPNEGO authentication, I don't know
it really)
Note : to really see what is going on, I highly recommend that you install some
software
like "Fiddler2" on your workstation, to show the headers of the HTTP requests
and responses.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
