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 > >
