On 04.03.2016 14:40, George Stanchev wrote:
It does not look like HTTP Basic. Did you try different browsers? IE, Chrome,
FF? Do you get same behavior with all? Is the user logging in member of the
domain your IWA is set up to?
Did you try /un/-checking the "Enable WIA authentication" checkbox in IE ?
(I know it sounds counter-intuitive, but try it).
If you set up a 3rd party IWA provider (such as Waffle), does it act the same
on all 3 browsers? There was a recent issue with Waffle that one of my
developers submitted that was dealing with similar issues [1]. You might want
to go over that thread to see it can give you pointers.
[1] https://github.com/dblock/waffle/issues/268
-----Original Message-----
From: Chanchal Kariwala [mailto:chanchal.kariw...@seclore.com]
Sent: Friday, March 04, 2016 2:52 AM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Windows Authentication
But how does the browser decide on Basic Auth?
Usually 401 Response contains WWW-Authenticate: Basic realm="MyREALM" to
indicate Basic Auth
Thanks,
Chanchal R. Kariwala
Product Engineer
Seclore Technology
chanchal.kariw...@seclore.com
www.seclore.com
On Fri, Mar 4, 2016 at 3:16 PM, André Warnier (tomcat) <a...@ice-sa.com>
wrote:
On 04.03.2016 10:11, Chanchal Kariwala wrote:
I tries what you asked and I have observed the following
1. Browser sends a request for the resource Server replies with HTTP
401 and WWW-Authenticate: Negotiate in Response Headers
Fine.
2. Browser sends a new request with the following in Request Headers
Authorization: Negotiate YHkGBisGAQUFAqBvMG2gMDAuBgorBg....
Also seems fine. (But difficult to tell, as these tokens are "opaque" by
design).
Server replies again with HTTP 401 and WWW-Authenticate: Negotiate in
Response Headers
But this does not seem ok. It seems that the browser and server are
failing to agree on an authentication method, and dropping down to HTTP
Basic.
3. At this point the browser shows HTTP Basic Auth form and sends the
following in Headers
Authorization: Negotiate
YIIK1QYGKwYBBQUCoIIKyTCCCsWgMDAuBgkqhkiC9xIBAgIGCSqGS.... (*Really huge
value, much much longer than the first one*)
Now the Server replies with HTTP 200 and the following in headers
WWW-Authenticate: Negotiate oYHzMIHwoAMKAQChCwYJKoZIhvcSAQICom0....
Set-Cookie: JSESSIONID=541FE2EDD35690BBDE99..; Path=/webapp/; HttpOnly
So yes WIA is failing..
Can you help me out with the next step in debugging?
I think at this point, you need to go to your Windows network sysadmins,
with the information above, and ask them what is going on.
There are just too many possible reasons, in the Windows Domain
environment, why this could fail. (browser, browser version, workstation OS
version, browser settings, Domain Controller settings, Domain networkn
policies, membership of Domain or not, etc.).
Thanks,
Chanchal R. Kariwala
Product Engineer
Seclore Technology
chanchal.kariw...@seclore.com
www.seclore.com
On Fri, Mar 4, 2016 at 1:20 PM, André Warnier (tomcat) <a...@ice-sa.com>
wrote:
On 04.03.2016 07:16, Chanchal Kariwala wrote:
I am using Tomcat 8.0.32 and I have followed the guide given at
-
https://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html#Tomcat_instance_(Windows_server)
-
https://dzone.com/articles/do-not-publish-configuring-tomcat-single-sign-on-w
Windows AD Auth is working i.e. when I access the site, I am asked for
credentials and when I enter the correct credentials, the restricted
resource is displayed.
However my question is why the browser is asking for credentials? Why
isn't
it accessing TGT Cache in the OS to fetch the user's credentials?
I have enabled Integrated Windows Auth in IE Settings. I have added the
site in Intranet Sites and set "Logon by Current User" in Custom Level
setting for Intranet.
Hi.
The real *key* to debugging such issues, is to use some plugin or add-on
to the browser, to enable the capture and visualisation of the HTTP
dialog
back and forth between the browser and the server.
Since you are using IE, I suggest "Fiddler2".
Install it, close your browser, re-open the browser, start Fiddler2 in
capture mode, and then do an access to the webserver. When prompted for
an
id/pw, enter them.
Then stop Fiddler2 and examine the HTTP exchanges, starting with your
initial request to the webserver.
You are correct in thinking that, normally, the login should happen
automatically in the background, and you should never see this browser
login dialog.
WIA authentication is a multiple-step process between the browser and the
webserver, and in the background between the webserver and a Domain
Controller.
That the login dialog appears in your case, means :
1) that the integrated WIA failed
2) that the Domain is configured to allow HTTP Basic authentication in a
second step, after WIA fails. That is the login dialog that you see.
So, something is not working as it should in the WIA step.
But to know exactly what, requires examining the HTTP exchanges.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
