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