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.kariw...@seclore.com www.seclore.com On Mon, Mar 7, 2016 at 10:19 AM, Chanchal Kariwala < chanchal.kariw...@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.kariw...@seclore.com > > www.seclore.com > > > > On Sat, Mar 5, 2016 at 3:57 PM, Felix Schumacher < > felix.schumac...@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.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 >> >> >
