You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Chanchal Kariwala <ch...@seclore.com> on 2016/03/04 07:16:20 UTC
Windows Authentication
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.
Thanks,
Chanchal R. Kariwala
Product Engineer
Seclore Technology
chanchal.kariwala@seclore.com
www.seclore.com
Re: Windows Authentication
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
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.kariwala@seclore.com]
> Sent: Friday, March 04, 2016 2:52 AM
> To: Tomcat Users List <us...@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.kariwala@seclore.com
> www.seclore.com
>
>
>
> On Fri, Mar 4, 2016 at 3:16 PM, André Warnier (tomcat) <aw...@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.kariwala@seclore.com
>>> www.seclore.com
>>>
>>>
>>>
>>> On Fri, Mar 4, 2016 at 1:20 PM, André Warnier (tomcat) <aw...@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-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Windows Authentication
Posted by George Stanchev <Gs...@serena.com>.
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?
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.kariwala@seclore.com]
Sent: Friday, March 04, 2016 2:52 AM
To: Tomcat Users List <us...@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.kariwala@seclore.com
www.seclore.com
On Fri, Mar 4, 2016 at 3:16 PM, André Warnier (tomcat) <aw...@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.kariwala@seclore.com
>> www.seclore.com
>>
>>
>>
>> On Fri, Mar 4, 2016 at 1:20 PM, André Warnier (tomcat) <aw...@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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Windows Authentication
Posted by Chanchal Kariwala <ch...@seclore.com>.
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.kariwala@seclore.com
www.seclore.com
On Fri, Mar 4, 2016 at 3:16 PM, André Warnier (tomcat) <aw...@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.kariwala@seclore.com
>> www.seclore.com
>>
>>
>>
>> On Fri, Mar 4, 2016 at 1:20 PM, André Warnier (tomcat) <aw...@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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Windows Authentication
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
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.kariwala@seclore.com
> www.seclore.com
>
>
>
> On Fri, Mar 4, 2016 at 1:20 PM, André Warnier (tomcat) <aw...@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Windows Authentication
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
On 07.03.2016 11:39, André Warnier (tomcat) wrote:
> On 07.03.2016 06:10, Chanchal Kariwala wrote:
>> The article which suggested that NTLM is being used by Winlogon instead of
>> Kerberos :
>>
>> http://stackoverflow.com/questions/5597573/how-to-find-if-ntlm-or-kerberos-is-used-from-www-authenticate-negotiate-header
>>
>>
>> So the token browser sends on first 401 starts from YHkG...
>> And the second token begins with YIIK1QYG....
>>
>
> Check also this one :
> https://blogs.msdn.microsoft.com/friis/2009/12/31/things-to-check-when-kerberos-authentication-fails-using-iisie/
>
As you see, there are a lot of things to check, one by one. That is because WIA (and
Kerberos) are very fiddly, and even one little setting or circumstance can result in the
thing not working (as in your case).
P.S. The mere volume of articles on this subject in Google (e.g. "kerberos and wia" or
"kerberos and IE")
1) by itself makes it difficult to know which one to read and believe
2) indicates that this is a complex subject, with which a lot of people have problems
This list here is about Tomcat issues. There is an SPNEGO authentication Valve in Tomcat,
and there are certainly some people on this list with some knowledge of WIA/Kerberos, but
such issues are probably not their main focus, or their main area of expertise.
You may have a bit more luck (or at least find more people focused on Windows
authentication) on the Samba list for example.
Maybe try here : https://lists.samba.org/mailman/listinfo/samba
and supply all your previous information again, including the captured headers.
That would definitely increase your chances of receiving a helpful response.
It is not that we don't /want/ to help, but there are just too many external factors and
settings which can play a role, that it is a bit overwhelming to try this one step remote
from the problem.
If you do in the end identify a specific problem with the Tomcat SPNEGO Valve, don't
hesitate to come back and ask for help here again.
Also, if you do find the solution, please post a short message to this list, so that maybe
other people here with a similar issue could in the future find the solution in the list
archives.
(I presume you have already searched these archives for similar issues ?)
Another thing, at a different level : if your main aim is to solve this issue quickly,
then have a look at Jespa (https://www.ioplex.com/).
I can testify that Jespa works fautlessly in several installations which I did.
And just reading the User Manual may already give you some useful tips.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Windows Authentication
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
On 07.03.2016 06:10, Chanchal Kariwala wrote:
> The article which suggested that NTLM is being used by Winlogon instead of
> Kerberos :
>
> http://stackoverflow.com/questions/5597573/how-to-find-if-ntlm-or-kerberos-is-used-from-www-authenticate-negotiate-header
>
> So the token browser sends on first 401 starts from YHkG...
> And the second token begins with YIIK1QYG....
>
Check also this one :
https://blogs.msdn.microsoft.com/friis/2009/12/31/things-to-check-when-kerberos-authentication-fails-using-iisie/
> Thanks,
> Chanchal R. Kariwala
> Product Engineer
> Seclore Technology
> chanchal.kariwala@seclore.com
> www.seclore.com
>
>
>
> On Mon, Mar 7, 2016 at 10:19 AM, Chanchal Kariwala <
> chanchal.kariwala@seclore.com> wrote:
>
>> In response to *George Stanchev*,
>> I tried with Chrome and IE 11, same behavior in both. And yes I tried
>> waffle, but in another webapp. Waffle does not prompt for the credentials..
>>
>> In response to *André Warnier*,
>> I tired that to no avail :(
>>
>> In response to *Felix Schumacher*,
>> It is not a problem with the webapp. I have tried both of what you asked.
>> Tomcat Keytab is authenticated successfully. And KRB debug
>> shows success for the keytab.
>>
>> So here are my additional findings over the weekend.
>> Background - My test AD is virtual. My Domain Controller and client are
>> VMS.
>>
>> 1. *Windows Logon was using NTLM instead of Kerberos*
>>
>> Some article led me to the following assumption :
>>
>> When the browser receives WWW-Authenticate: Negotiate, it asks for the
>> token from the OS Cache. The OS Cache provides it a token that was obtained
>> via NTLM. The Server does not accept that since it specifically wants
>> Kerberos. And hence the browser asks for Credentials again and this time
>> the user is authenticated via Kerberos. And this token is accepted by the
>> Server.
>>
>>
>> 2. *Windows Logon by IP Address uses NTLM*
>>
>> I access the client machine (with tomcat) using RDP via the IP Address.
>> The following question on StackExchange indicates that in
>> such a scenario NTLM is used to logon to the system.
>>
>> See :
>> http://serverfault.com/questions/357975/is-it-possible-to-switch-to-kerberos-only-windows-domain
>>
>>
>> 3. *Kerberos Event Logging*
>>
>> The next thing I was trying to figure was why Windows logon was using
>> NTLM. The above link suggests that there was no way of forcing
>> LSA to use Kerberos only. So now I am looking at the System events, which
>> might suggest which protocol is being used.
>>
>> Also I enabled Kerberos event logging to see if there were any Kerberos
>> Errors.
>>
>> See : https://support.microsoft.com/en-us/kb/262177
>>
>>
>> Thanks,
>> Chanchal R. Kariwala
>> Product Engineer
>> Seclore Technology
>> chanchal.kariwala@seclore.com
>>
>> www.seclore.com
>>
>>
>>
>> On Sat, Mar 5, 2016 at 3:57 PM, Felix Schumacher <
>> felix.schumacher@internetallee.de> wrote:
>>
>>> Am 04.03.2016 um 10:11 schrieb Chanchal Kariwala:
>>>
>>>> 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
>>>>
>>>> 2. Browser sends a new request with the following in Request Headers
>>>> Authorization: Negotiate YHkGBisGAQUFAqBvMG2gMDAuBgorBg....
>>>>
>>>> Server replies again with HTTP 401 and WWW-Authenticate: Negotiate in
>>>> Response Headers
>>>>
>>>> 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?
>>>>
>>> You can enable debugging for kerberos in the jvm and you can enable debug
>>> logs for the SpnegoAuthenticator in tomcat to get more information.
>>>
>>> To enable debug log messages in the jvm add
>>>
>>> -Dsun.security.krb5.debug=true
>>>
>>> to CATALINA_OPTS. The log messages will appear in catalina.out and are
>>> quite verbose.
>>>
>>> To enable debug log messages for SpnegoAuthenticator, add
>>>
>>> org.apache.catalina.authenticator.SpnegoAuthenticator.level = FINE
>>>
>>> to conf/logging.properties in your CATALINA_BASE directory.
>>>
>>> Regards,
>>> Felix
>>>
>>>
>>>>
>>>>
>>>>
>>>> Thanks,
>>>> Chanchal R. Kariwala
>>>> Product Engineer
>>>> Seclore Technology
>>>> chanchal.kariwala@seclore.com
>>>> www.seclore.com
>>>>
>>>>
>>>>
>>>> On Fri, Mar 4, 2016 at 1:20 PM, André Warnier (tomcat) <aw...@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-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Windows Authentication
Posted by Chanchal Kariwala <ch...@seclore.com>.
The article which suggested that NTLM is being used by Winlogon instead of
Kerberos :
http://stackoverflow.com/questions/5597573/how-to-find-if-ntlm-or-kerberos-is-used-from-www-authenticate-negotiate-header
So the token browser sends on first 401 starts from YHkG...
And the second token begins with YIIK1QYG....
Thanks,
Chanchal R. Kariwala
Product Engineer
Seclore Technology
chanchal.kariwala@seclore.com
www.seclore.com
On Mon, Mar 7, 2016 at 10:19 AM, Chanchal Kariwala <
chanchal.kariwala@seclore.com> wrote:
> In response to *George Stanchev*,
> I tried with Chrome and IE 11, same behavior in both. And yes I tried
> waffle, but in another webapp. Waffle does not prompt for the credentials.
>
> In response to *André Warnier*,
> I tired that to no avail :(
>
> In response to *Felix Schumacher*,
> It is not a problem with the webapp. I have tried both of what you asked.
> Tomcat Keytab is authenticated successfully. And KRB debug
> shows success for the keytab.
>
> So here are my additional findings over the weekend.
> Background - My test AD is virtual. My Domain Controller and client are
> VMS.
>
> 1. *Windows Logon was using NTLM instead of Kerberos*
>
> Some article led me to the following assumption :
>
> When the browser receives WWW-Authenticate: Negotiate, it asks for the
> token from the OS Cache. The OS Cache provides it a token that was obtained
> via NTLM. The Server does not accept that since it specifically wants
> Kerberos. And hence the browser asks for Credentials again and this time
> the user is authenticated via Kerberos. And this token is accepted by the
> Server.
>
>
> 2. *Windows Logon by IP Address uses NTLM*
>
> I access the client machine (with tomcat) using RDP via the IP Address.
> The following question on StackExchange indicates that in
> such a scenario NTLM is used to logon to the system.
>
> See :
> http://serverfault.com/questions/357975/is-it-possible-to-switch-to-kerberos-only-windows-domain
>
>
> 3. *Kerberos Event Logging*
>
> The next thing I was trying to figure was why Windows logon was using
> NTLM. The above link suggests that there was no way of forcing
> LSA to use Kerberos only. So now I am looking at the System events, which
> might suggest which protocol is being used.
>
> Also I enabled Kerberos event logging to see if there were any Kerberos
> Errors.
>
> See : https://support.microsoft.com/en-us/kb/262177
>
>
> Thanks,
> Chanchal R. Kariwala
> Product Engineer
> Seclore Technology
> chanchal.kariwala@seclore.com
>
> www.seclore.com
>
>
>
> On Sat, Mar 5, 2016 at 3:57 PM, Felix Schumacher <
> felix.schumacher@internetallee.de> wrote:
>
>> Am 04.03.2016 um 10:11 schrieb Chanchal Kariwala:
>>
>>> 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
>>>
>>> 2. Browser sends a new request with the following in Request Headers
>>> Authorization: Negotiate YHkGBisGAQUFAqBvMG2gMDAuBgorBg....
>>>
>>> Server replies again with HTTP 401 and WWW-Authenticate: Negotiate in
>>> Response Headers
>>>
>>> 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?
>>>
>> You can enable debugging for kerberos in the jvm and you can enable debug
>> logs for the SpnegoAuthenticator in tomcat to get more information.
>>
>> To enable debug log messages in the jvm add
>>
>> -Dsun.security.krb5.debug=true
>>
>> to CATALINA_OPTS. The log messages will appear in catalina.out and are
>> quite verbose.
>>
>> To enable debug log messages for SpnegoAuthenticator, add
>>
>> org.apache.catalina.authenticator.SpnegoAuthenticator.level = FINE
>>
>> to conf/logging.properties in your CATALINA_BASE directory.
>>
>> Regards,
>> Felix
>>
>>
>>>
>>>
>>>
>>> Thanks,
>>> Chanchal R. Kariwala
>>> Product Engineer
>>> Seclore Technology
>>> chanchal.kariwala@seclore.com
>>> www.seclore.com
>>>
>>>
>>>
>>> On Fri, Mar 4, 2016 at 1:20 PM, André Warnier (tomcat) <aw...@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-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
Re: Windows Authentication
Posted by Chanchal Kariwala <ch...@seclore.com>.
In response to *George Stanchev*,
I tried with Chrome and IE 11, same behavior in both. And yes I tried
waffle, but in another webapp. Waffle does not prompt for the credentials.
In response to *André Warnier*,
I tired that to no avail :(
In response to *Felix Schumacher*,
It is not a problem with the webapp. I have tried both of what you asked.
Tomcat Keytab is authenticated successfully. And KRB debug
shows success for the keytab.
So here are my additional findings over the weekend.
Background - My test AD is virtual. My Domain Controller and client are VMS.
1. *Windows Logon was using NTLM instead of Kerberos*
Some article led me to the following assumption :
When the browser receives WWW-Authenticate: Negotiate, it asks for the
token from the OS Cache. The OS Cache provides it a token that was obtained
via NTLM. The Server does not accept that since it specifically wants
Kerberos. And hence the browser asks for Credentials again and this time
the user is authenticated via Kerberos. And this token is accepted by the
Server.
2. *Windows Logon by IP Address uses NTLM*
I access the client machine (with tomcat) using RDP via the IP Address. The
following question on StackExchange indicates that in
such a scenario NTLM is used to logon to the system.
See :
http://serverfault.com/questions/357975/is-it-possible-to-switch-to-kerberos-only-windows-domain
3. *Kerberos Event Logging*
The next thing I was trying to figure was why Windows logon was using NTLM.
The above link suggests that there was no way of forcing
LSA to use Kerberos only. So now I am looking at the System events, which
might suggest which protocol is being used.
Also I enabled Kerberos event logging to see if there were any Kerberos
Errors.
See : https://support.microsoft.com/en-us/kb/262177
Thanks,
Chanchal R. Kariwala
Product Engineer
Seclore Technology
chanchal.kariwala@seclore.com
www.seclore.com
On Sat, Mar 5, 2016 at 3:57 PM, Felix Schumacher <
felix.schumacher@internetallee.de> wrote:
> Am 04.03.2016 um 10:11 schrieb Chanchal Kariwala:
>
>> 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
>>
>> 2. Browser sends a new request with the following in Request Headers
>> Authorization: Negotiate YHkGBisGAQUFAqBvMG2gMDAuBgorBg....
>>
>> Server replies again with HTTP 401 and WWW-Authenticate: Negotiate in
>> Response Headers
>>
>> 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?
>>
> You can enable debugging for kerberos in the jvm and you can enable debug
> logs for the SpnegoAuthenticator in tomcat to get more information.
>
> To enable debug log messages in the jvm add
>
> -Dsun.security.krb5.debug=true
>
> to CATALINA_OPTS. The log messages will appear in catalina.out and are
> quite verbose.
>
> To enable debug log messages for SpnegoAuthenticator, add
>
> org.apache.catalina.authenticator.SpnegoAuthenticator.level = FINE
>
> to conf/logging.properties in your CATALINA_BASE directory.
>
> Regards,
> Felix
>
>
>>
>>
>>
>> Thanks,
>> Chanchal R. Kariwala
>> Product Engineer
>> Seclore Technology
>> chanchal.kariwala@seclore.com
>> www.seclore.com
>>
>>
>>
>> On Fri, Mar 4, 2016 at 1:20 PM, André Warnier (tomcat) <aw...@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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Windows Authentication
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 04.03.2016 um 10:11 schrieb Chanchal Kariwala:
> 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
>
> 2. Browser sends a new request with the following in Request Headers
> Authorization: Negotiate YHkGBisGAQUFAqBvMG2gMDAuBgorBg....
>
> Server replies again with HTTP 401 and WWW-Authenticate: Negotiate in
> Response Headers
>
> 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?
You can enable debugging for kerberos in the jvm and you can enable
debug logs for the SpnegoAuthenticator in tomcat to get more information.
To enable debug log messages in the jvm add
-Dsun.security.krb5.debug=true
to CATALINA_OPTS. The log messages will appear in catalina.out and are
quite verbose.
To enable debug log messages for SpnegoAuthenticator, add
org.apache.catalina.authenticator.SpnegoAuthenticator.level = FINE
to conf/logging.properties in your CATALINA_BASE directory.
Regards,
Felix
>
>
>
>
> Thanks,
> Chanchal R. Kariwala
> Product Engineer
> Seclore Technology
> chanchal.kariwala@seclore.com
> www.seclore.com
>
>
>
> On Fri, Mar 4, 2016 at 1:20 PM, André Warnier (tomcat) <aw...@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Windows Authentication
Posted by Chanchal Kariwala <ch...@seclore.com>.
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
2. Browser sends a new request with the following in Request Headers
Authorization: Negotiate YHkGBisGAQUFAqBvMG2gMDAuBgorBg....
Server replies again with HTTP 401 and WWW-Authenticate: Negotiate in
Response Headers
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?
Thanks,
Chanchal R. Kariwala
Product Engineer
Seclore Technology
chanchal.kariwala@seclore.com
www.seclore.com
On Fri, Mar 4, 2016 at 1:20 PM, André Warnier (tomcat) <aw...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Windows Authentication
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org