tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier (tomcat) ...@ice-sa.com>
Subject Re: Windows Authentication
Date Mon, 07 Mar 2016 10:39:42 GMT
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


Mime
View raw message