Re: Windows Authentication
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Windows Authentication
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.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) 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
Re: Windows Authentication
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) >>> 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 c
Re: Windows Authentication
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) >> 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". >>>
Re: Windows Authentication
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) 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
Re: Windows Authentication
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.kariw...@seclore.com] Sent: Friday, March 04, 2016 2:52 AM To: Tomcat Users List 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.kariw...@seclore.com www.seclore.com On Fri, Mar 4, 2016 at 3:16 PM, André Warnier (tomcat) 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) 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
RE: Windows Authentication
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.kariw...@seclore.com] Sent: Friday, March 04, 2016 2:52 AM To: Tomcat Users List 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.kariw...@seclore.com www.seclore.com On Fri, Mar 4, 2016 at 3:16 PM, André Warnier (tomcat) 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) >> 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
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.kariw...@seclore.com www.seclore.com On Fri, Mar 4, 2016 at 3:16 PM, André Warnier (tomcat) 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) >> 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 > >
Re: Windows Authentication
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) 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
Re: Windows Authentication
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.kariw...@seclore.com www.seclore.com On Fri, Mar 4, 2016 at 1:20 PM, André Warnier (tomcat) 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 > >
Re: Windows Authentication
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
Re: Windows authentication : outdated link
2015-03-13 15:13 GMT+03:00 Konstantin Kolinko : > 2015-03-13 15:04 GMT+03:00 André Warnier : >> Hi. >> >> Errata : >> >> In the page >> http://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html#References >> (and also in the corresponding Tomcat 7 page), the link to >> >> Geronimo configuration for Windows authentication >> >> leads to : >> >> https://cwiki.apache.org/GMOxDOC21/using-spengo-in-geronimo.html#UsingSpengoingeronimo-SettinguptheActiveDirectoryDomainController >> >> which returns : >> >> The requested URL >> /confluence/display/GMOxDOC21/using-spengo-in-geronimo.html was not found on >> this server. >> >> (neither does it work if one replaces the "spengo" parts by "spnego"..) >> > > Apparently they replaced '-' with '+' and have lost the ".html" suffix. > > https://cwiki.apache.org/confluence/display/GMOxDOC21/Using+SPNEGO+in+Geronimo#UsingSPNEGOinGeronimo-SettinguptheDomainControllerMachine I updated the docs in Tomcat 9/8/7. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Windows authentication : outdated link
2015-03-13 15:04 GMT+03:00 André Warnier : > Hi. > > Errata : > > In the page > http://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html#References > (and also in the corresponding Tomcat 7 page), the link to > > Geronimo configuration for Windows authentication > > leads to : > > https://cwiki.apache.org/GMOxDOC21/using-spengo-in-geronimo.html#UsingSpengoingeronimo-SettinguptheActiveDirectoryDomainController > > which returns : > > The requested URL > /confluence/display/GMOxDOC21/using-spengo-in-geronimo.html was not found on > this server. > > (neither does it work if one replaces the "spengo" parts by "spnego"..) > Apparently they replaced '-' with '+' and have lost the ".html" suffix. https://cwiki.apache.org/confluence/display/GMOxDOC21/Using+SPNEGO+in+Geronimo#UsingSPNEGOinGeronimo-SettinguptheDomainControllerMachine Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Windows Authentication on Tomcat 7.0.37 and JRE 7u13 / 64-bit
All systems are domain-joined to a mature IT Lab and the issue is with the Tomcat server configuration as it should load the krb5.ini and or jaas.conf and activity should be observable on the Web server - whether or not any error is generated. It is not clear to me what the design load process / order of the call stack should be in the SPNEGO Authentication design. This would help focus on where the issue is. I ran Process Monitor during a Network Client PC TCP session to the Tomcat Web Server as well as during start of the Tomcat Web service. During either of these I don’t observe any calls to jaas.conf, or krb5.ini. What should initiate loading of these and at what point should they load? Observation Notes: Process Monitor for Tomcat7.exe when browsing to http://server/SPNEGOAuthTest.jsp shows in summary TCP Accept: Server -> PC TCP Receive: Server -> PC CreateFile: .\Tomcat7.0\webapps\ROOT\SPNEGOAuthTest.jsp QueryNetworkOpenInformationFile: CloseFile: CreateFile:... CreateFile: .\ \_\org\apache\jsp\SPNEGOAuthTest_jsp.class CloseFole . \ \_\org\apache\jsp\SPNEGOAuthTest_jsp.class ... TCP Send: Server -> PC In the SPNEGOAuthTest.jsp HTML response: request.getRemoteUser() response shows value of “Nul” request.getRemoteAddr() does show the IP address of the PC Process Monitor during Tomcat Service start - Calls are shown to .\conf\server.xml mbeans-descriptors.xml .\conf\tomcat-users.xml .\conf\context.xml .\conf\web.xml Again no calls to jaas.conf, or krb5.ini > Date: Thu, 28 Feb 2013 06:42:35 -0800 > From: ma...@apache.org > To: users@tomcat.apache.org > Subject: Re: Windows Authentication on Tomcat 7.0.37 and JRE 7u13 / 64-bit > > On 28/02/2013 02:18, Chris Fors wrote: > > Trying to get Windows > > Authentication operational using the Tomcat Built-in method. Implemented > > the following but not > > observed any Windows / Kerberos authentication occuring: > > > > - > > Domain joined > > windows member server > > > > - > > Domain service > > account > > > > - > > Delegated SPN for > > HTTP protocol on the member server to the service account > > > > - > > Generated keytab > > file for the service account and saved in $catalina.base\conf folder > > > > - > > Created Valve in context.xml of className > > org.apache.catalina.authenticator.SpnegoAuthenticator > > > > - > > Created krb5.ini and > > saved in $catalina.base\conf folder > > > > - > > Created jaas.conf and > > saved in $catalina.base\conf folder > > > > > > > > After this still no observed > > effect on logon authentications – all still apparently anonymous. > > As expected from what you have described. > > If there are no security constraints on a resource, Tomcat isn't going > to require authentication. > > > > Anyone had success with this ? > > Yes. I have a set of test VMs (1 domain controller, 1 Tomcat server and > 1 client) where this feature works. > > > Any ideas on what is missing?Is there a good way to > > debug the process? > > See above. I'd expect to see some changes to the webapp. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
Re: Windows Authentication on Tomcat 7.0.37 and JRE 7u13 / 64-bit
On 28/02/2013 02:18, Chris Fors wrote: Trying to get Windows Authentication operational using the Tomcat Built-in method. Implemented the following but not observed any Windows / Kerberos authentication occuring: - Domain joined windows member server - Domain service account - Delegated SPN for HTTP protocol on the member server to the service account - Generated keytab file for the service account and saved in $catalina.base\conf folder - Created Valve in context.xml of className org.apache.catalina.authenticator.SpnegoAuthenticator - Created krb5.ini and saved in $catalina.base\conf folder - Created jaas.conf and saved in $catalina.base\conf folder After this still no observed effect on logon authentications – all still apparently anonymous. As expected from what you have described. If there are no security constraints on a resource, Tomcat isn't going to require authentication. Anyone had success with this ? Yes. I have a set of test VMs (1 domain controller, 1 Tomcat server and 1 client) where this feature works. Any ideas on what is missing?Is there a good way to debug the process? See above. I'd expect to see some changes to the webapp. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Windows Authentication on Tomcat 7.0.37 and JRE 7u13 / 64-bit
Chris Fors wrote: Trying to get Windows Authentication operational using the Tomcat Built-in method. Implemented the following but not observed any Windows / Kerberos authentication occuring: - Domain joined windows member server - Domain service account - Delegated SPN for HTTP protocol on the member server to the service account - Generated keytab file for the service account and saved in $catalina.base\conf folder - Created Valve in context.xml of className org.apache.catalina.authenticator.SpnegoAuthenticator - Created krb5.ini and saved in $catalina.base\conf folder - Created jaas.conf and saved in $catalina.base\conf folder After this still no observed effect on logon authentications – all still apparently anonymous. Anyone had success with this ? Any ideas on what is missing?Is there a good way to debug the process? What is the OS platform ? To debug the process : other than what you already did above, a network trace with Wireshark or similar ? (should be SMB exchanges I suppose) Another couple of questions : - is the client workstation that accesses the Tomcat server, itself in the Domain to which you are trying to authenticate ? - from the point of view of that workstation and its browser, is that Tomcat server considered as inside the Domain, or at least "trusted" ? (because if not, then the browser will not even /try/ to use WIA authentication) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Windows Authentication: Issue 49318 vs 47679
On Mon, Mar 28, 2011 at 7:26 AM, Stefan Mayr wrote: > Hello everybody, > > as many others before we wanted to do single-sign-on for intranet web > applications using integrated windows authentication (negotiate because IE > sometimes tries NTLM instead of using plain kerberos - breaking all our > kerberos-only experiments). > > We thought that IIS would be the best choice for integrated windows > authentication and we could pass the user via AJP (using mod_jk) to our > tomcat instances. > > Our setup: > - Windows 2008 R2 using IIS 7.5 (64bit) > - mod_jk 1.2.31 > - Oracle Java 1.6 U24 > - Tomcat 6.0.32 > > At first glance using tomcatAuthentication=false worked as expected. We got > the remote user and started deploying an application. End of happiness - the > application complained about a missing user-agent. That header was not > passed to tomcat when authentication was enabled on IIS. > > Some research revealed Bug 47679 - Not all headers get passed to Tomcat > server from isapi_redirect.dll > (https://issues.apache.org/bugzilla/show_bug.cgi?id=47679) > > Today I've found Bug 49318 - add a Negotiate (Kerberos/NTLM) authenticator / > integrate Waffle (https://issues.apache.org/bugzilla/show_bug.cgi?id=49318). > The last comment links a new Windows Authentication How-To from Mark Thomas. > Looks like we have already tried almost all proposed solutions: > > - IIS + mod_jk: > tried but stuck in Bug 47679. Also tried ARR to pass the user name > as a request header from IIS to Tomcat without success > - Apache mod_ntlm: used it and we replaced it by the much more stable > mod_auth_ntlm_winbind. NTLMv1 is also disabled on Windows 7 (default) > - Apache mod_auth_ntlm: in heavy use but stuck to Apache 2.0 and 32bit > plattform - we couldn't get stability problems solved on Apache 2.2 > and 64bit Linux. No ongoing development. > - Apache mod_auth_sspi: till now in internal use for a very small > project (works just fine), not sure about the future. Although > there seems to be some new activity on 1.0.5 beta > - Waffle: found it on thursday and it is on my our todo-list for > testing it next week > > Any chances to get Bug 47679 solved? How can we help (we are admins, no > devs)? > What solutions have you deployed? Recommendations? I've committed a fix for Bug 47679, which I hope will resolve the issues people have been having using the ISAPI redirector in an extension only mode. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Windows Authentication: Issue 49318 vs 47679
Stefan Mayr wrote: Native SPNEGO in Tomcat sounds great. Waiting a little while depends on your scale of "little". Is there already some development we can follow? Will this use Java GSS? I never figured out how to configure this with Tomcat. If you are in a hurry, you may want to have a look at Jespa : www.ioplex.com. Have it installed at numerous customers sites and works great. About the sequence of rewrite/forward with IIS, have a look at isapi_rewrite : http://www.helicontech.com/isapi_rewrite/doc/ It can pick up the user's Windows domain user-id, and pass it on as a HTTP header. You would then need a simple servlet filter at the Tomcat level, to pick up the content of this header and use it as the authenticated Tomcat user-id. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Windows Authentication: Issue 49318 vs 47679
On 29/03/2011 21:18, Borut Hadžialić wrote: > On Tue, Mar 29, 2011 at 9:57 PM, Mark Thomas wrote: >> It is in scope with the caveat - as always - that it depends on what the >> final implementation looks like. I do know (from debug logging) that >> right now tokens do not allow delegation. I suspect the hardest part of >> implementing this will be figuring out what config needs tweaking to >> allow that. > > I think that credential delegation is configured at the domain > controller and client side, as this nice article describes: > http://spnego.sourceforge.net/credential_delegation.html Thanks. That is one of the many articles I have read over the last few days but I had forgotten which ones mentioned what. I'll take a look. >>> I am sure this would be useful for some applications - for example the >>> one that we are currently developing needs functionality like this. >> >> Testing help always appreciated if you are happy running the latest >> 7.0.x release (this should be in 7.0.12 which I plan to start releasing >> just as soon as I finish everything on my todo list). >> > > We already have some hand written custom code for this. We will not be > switching to 7.0.x (we will be deploying to tcServer in producion, and > it will probably take lots of time for 7.0.12 changes to appear in > some version of tcServer, so we need the custom code we have at the > moment). Fair enough. With my VMware hat on that is is probably going to be sooner than you think it is but I can't give you any firm dates. > I might however try to deploy our app to 7.0.12 when it is out - and > see how much of our custom code will get removed by this spnego > support that you are writing now. That would be great. Any testing and feedback is always helpful. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Windows Authentication: Issue 49318 vs 47679
On Tue, Mar 29, 2011 at 9:57 PM, Mark Thomas wrote: > It is in scope with the caveat - as always - that it depends on what the > final implementation looks like. I do know (from debug logging) that > right now tokens do not allow delegation. I suspect the hardest part of > implementing this will be figuring out what config needs tweaking to > allow that. I think that credential delegation is configured at the domain controller and client side, as this nice article describes: http://spnego.sourceforge.net/credential_delegation.html >> I am sure this would be useful for some applications - for example the >> one that we are currently developing needs functionality like this. > > Testing help always appreciated if you are happy running the latest > 7.0.x release (this should be in 7.0.12 which I plan to start releasing > just as soon as I finish everything on my todo list). > We already have some hand written custom code for this. We will not be switching to 7.0.x (we will be deploying to tcServer in producion, and it will probably take lots of time for 7.0.12 changes to appear in some version of tcServer, so we need the custom code we have at the moment). I might however try to deploy our app to 7.0.12 when it is out - and see how much of our custom code will get removed by this spnego support that you are writing now. -- Why? Because YES! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Windows Authentication: Issue 49318 vs 47679
On 29/03/2011 20:47, Borut Hadžialić wrote: > Would adding support for client credential delegation be out of scope > for this implementation or not? It is in scope with the caveat - as always - that it depends on what the final implementation looks like. I do know (from debug logging) that right now tokens do not allow delegation. I suspect the hardest part of implementing this will be figuring out what config needs tweaking to allow that. > //Store the clientSubject somewhere - maybe to the HttpServletRequest? That needs a little more thought. I am leaning towards a request attribute at the moment unless I can find a way to get it into the result of getUserPrincipal() (which I don't think I can without requiring a cast to a Tomcat internal class which is just horrible). > I am sure this would be useful for some applications - for example the > one that we are currently developing needs functionality like this. Testing help always appreciated if you are happy running the latest 7.0.x release (this should be in 7.0.12 which I plan to start releasing just as soon as I finish everything on my todo list). Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Windows Authentication: Issue 49318 vs 47679
Whoops, i reversed the condition of the if statement, it should be: //check if the credentials can be delegated if (context.getCredDelegState()) { ... } On Tue, Mar 29, 2011 at 9:47 PM, Borut Hadžialić wrote: > Would adding support for client credential delegation be out of scope > for this implementation or not? > > Client credential delegation is when you use the spnego token > construct a javax.security.auth.Subject instance that represents the > client - which the server side application can use this to impersonate > the client (eg. connect to some Kerberized database as the client that > sent the request, or consume some other kerberized service as the > client). > > The code for creating such a Subject would be something like this: > > GSSContext context = > GSSManager.getInstance().createContext((GSSCredential) null); > context.acceptSecContext(...); > > //check if the credentials can be delegated > if (!context.getCredDelegState()) { > > //get the delegated credentials from the calling peer... > GSSCredential clientCred = context.getDelegCred(); > > //Create a Subject out of the delegated credentials. > //With this Subject the application server can impersonate the > client that sent the request. > Subject clientSubject = > com.sun.security.jgss.GSSUtil.createSubject(context.getSrcName(), > clientCred); > } > > //Store the clientSubject somewhere - maybe to the HttpServletRequest? > > I am sure this would be useful for some applications - for example the > one that we are currently developing needs functionality like this. > > On Tue, Mar 29, 2011 at 9:09 PM, Mark Thomas wrote: >> On 29/03/2011 15:20, Mark Thomas wrote: >>> On 28/03/2011 22:31, Stefan Mayr wrote: Native SPNEGO in Tomcat sounds great. Waiting a little while depends on your scale of "little". Is there already some development we can follow? Will this use Java GSS? I never figured out how to configure this with Tomcat. >>> >>> "little" hopefully means the next week or so in a 7.0.12 release. I have >>> a handful of things I need/want to get into 7.0.12 and SPNEGO is one of >>> them. >>> >>> Having spent more time than I want to think about and having lost count >>> of the number of times I re-installed Windows 2k8 server to test this, I >>> finally got this working a few minutes ago. The current code is *very* >>> rough and ready and it only does authentication, not authorisation so I >>> still have some work to do. >>> >>> The solution is based on ideas from Spring Security's Kerberos extension >>> and the most recent patches attached to bug 48685. >>> >>> I'll be committing an initial implementation once I have cleaned up the >>> code a bit and then I'll build on that to add authorisation, more >>> configuration etc. >> >> The first part just got committed [1]. More to follow over the next day >> or so. >> >> Mark >> >> [1] http://svn.apache.org/viewvc?rev=1086683&view=rev >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > > > > -- > Why? > Because YES! > -- Why? Because YES! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Windows Authentication: Issue 49318 vs 47679
Would adding support for client credential delegation be out of scope for this implementation or not? Client credential delegation is when you use the spnego token construct a javax.security.auth.Subject instance that represents the client - which the server side application can use this to impersonate the client (eg. connect to some Kerberized database as the client that sent the request, or consume some other kerberized service as the client). The code for creating such a Subject would be something like this: GSSContext context = GSSManager.getInstance().createContext((GSSCredential) null); context.acceptSecContext(...); //check if the credentials can be delegated if (!context.getCredDelegState()) { //get the delegated credentials from the calling peer... GSSCredential clientCred = context.getDelegCred(); //Create a Subject out of the delegated credentials. //With this Subject the application server can impersonate the client that sent the request. Subject clientSubject = com.sun.security.jgss.GSSUtil.createSubject(context.getSrcName(), clientCred); } //Store the clientSubject somewhere - maybe to the HttpServletRequest? I am sure this would be useful for some applications - for example the one that we are currently developing needs functionality like this. On Tue, Mar 29, 2011 at 9:09 PM, Mark Thomas wrote: > On 29/03/2011 15:20, Mark Thomas wrote: >> On 28/03/2011 22:31, Stefan Mayr wrote: >>> Native SPNEGO in Tomcat sounds great. Waiting a little while depends on >>> your scale of "little". Is there already some development we can follow? >>> Will this use Java GSS? I never figured out how to configure this with >>> Tomcat. >> >> "little" hopefully means the next week or so in a 7.0.12 release. I have >> a handful of things I need/want to get into 7.0.12 and SPNEGO is one of >> them. >> >> Having spent more time than I want to think about and having lost count >> of the number of times I re-installed Windows 2k8 server to test this, I >> finally got this working a few minutes ago. The current code is *very* >> rough and ready and it only does authentication, not authorisation so I >> still have some work to do. >> >> The solution is based on ideas from Spring Security's Kerberos extension >> and the most recent patches attached to bug 48685. >> >> I'll be committing an initial implementation once I have cleaned up the >> code a bit and then I'll build on that to add authorisation, more >> configuration etc. > > The first part just got committed [1]. More to follow over the next day > or so. > > Mark > > [1] http://svn.apache.org/viewvc?rev=1086683&view=rev > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Why? Because YES! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Windows Authentication: Issue 49318 vs 47679
On 29/03/2011 15:20, Mark Thomas wrote: > On 28/03/2011 22:31, Stefan Mayr wrote: >> Native SPNEGO in Tomcat sounds great. Waiting a little while depends on >> your scale of "little". Is there already some development we can follow? >> Will this use Java GSS? I never figured out how to configure this with >> Tomcat. > > "little" hopefully means the next week or so in a 7.0.12 release. I have > a handful of things I need/want to get into 7.0.12 and SPNEGO is one of > them. > > Having spent more time than I want to think about and having lost count > of the number of times I re-installed Windows 2k8 server to test this, I > finally got this working a few minutes ago. The current code is *very* > rough and ready and it only does authentication, not authorisation so I > still have some work to do. > > The solution is based on ideas from Spring Security's Kerberos extension > and the most recent patches attached to bug 48685. > > I'll be committing an initial implementation once I have cleaned up the > code a bit and then I'll build on that to add authorisation, more > configuration etc. The first part just got committed [1]. More to follow over the next day or so. Mark [1] http://svn.apache.org/viewvc?rev=1086683&view=rev - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Windows Authentication: Issue 49318 vs 47679
On 28/03/2011 22:31, Stefan Mayr wrote: > Native SPNEGO in Tomcat sounds great. Waiting a little while depends on > your scale of "little". Is there already some development we can follow? > Will this use Java GSS? I never figured out how to configure this with > Tomcat. "little" hopefully means the next week or so in a 7.0.12 release. I have a handful of things I need/want to get into 7.0.12 and SPNEGO is one of them. Having spent more time than I want to think about and having lost count of the number of times I re-installed Windows 2k8 server to test this, I finally got this working a few minutes ago. The current code is *very* rough and ready and it only does authentication, not authorisation so I still have some work to do. The solution is based on ideas from Spring Security's Kerberos extension and the most recent patches attached to bug 48685. I'll be committing an initial implementation once I have cleaned up the code a bit and then I'll build on that to add authorisation, more configuration etc. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Windows Authentication: Issue 49318 vs 47679
Hi Mark, Am 28.03.2011 10:49, schrieb Mark Thomas: On 28/03/2011 08:42, Borut Hadžialić wrote: Hellos Stefan, if you can't fix your problem with configuration and decide that you want to solve the problem by programming, then this might help you http://blog.springsource.com/2009/09/28/spring-security-kerberos/ After understanding that article a developer should be able to add a SPNEGO implementation (probably not the whole protocol, just as much it is needed for your app) to your Tomcat application by adding some filters. Or you could just add Spring Security to your app. I'll add that as an option to the new How-To. I guess this is the classic kerberos/keytab approach (no NTLM-fallback) that many solutions offer. Today I've found Bug 49318 - add a Negotiate (Kerberos/NTLM) authenticator / integrate Waffle (https://issues.apache.org/bugzilla/show_bug.cgi?id=49318). The last comment links a new Windows Authentication How-To from Mark Thomas. Looks like we have already tried almost all proposed solutions: Thanks for the great feedback on the options. I put the existing how-to together pretty much entirely on some Google searches. I'll add your feedback to the how-to / maybe remove some options that don't look viable. - IIS + mod_jk: tried but stuck in Bug 47679. Also tried ARR to pass the user name as a request header from IIS to Tomcat without success - Apache mod_ntlm: used it and we replaced it by the much more stable mod_auth_ntlm_winbind. NTLMv1 is also disabled on Windows 7 (default) - Apache mod_auth_ntlm: in heavy use but stuck to Apache 2.0 and 32bit plattform - we couldn't get stability problems solved on Apache 2.2 and 64bit Linux. No ongoing development. - Apache mod_auth_sspi: till now in internal use for a very small project (works just fine), not sure about the future. Although there seems to be some new activity on 1.0.5 beta - Waffle: found it on thursday and it is on my our todo-list for testing it next week Any chances to get Bug 47679 solved? How can we help (we are admins, no devs)? What solutions have you deployed? Recommendations? It is tricky to recommend something right now. I'm guessing you want something that a) works reliably and b) is likely to be supported for the long term. Right now Waffle probably comes closest to that. It you can wait a little while, I should have SPNEGO support in Tomcat 7 fairly soon. It may - or may not - get back-ported to Tomcat 6. It will depend on the eventual solution. You're definitely right. We search for the holy grail of intranet authentication. a+b is a must. The idea of using IIS with ARR in reverse proxy mode passing a username was dead end: Microsoft pointed us to a nice article describing HTTP request processing order. Rewriting a request comes before the authentication modul - so nothing to append to a header or request in the first place. See http://learn.iis.net/page.aspx/501/iis-70-request-filtering-and-url-rewriting/ Leaves IIS with mod_jk if you can live with Bug 47679. Our first test with Waffle is promising. Now it needs to be integrated and in our application for further testing. Native SPNEGO in Tomcat sounds great. Waiting a little while depends on your scale of "little". Is there already some development we can follow? Will this use Java GSS? I never figured out how to configure this with Tomcat. Stefan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Windows Authentication: Issue 49318 vs 47679
> I should have SPNEGO support in Tomcat 7 fairly soon. This would be great! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Windows Authentication: Issue 49318 vs 47679
On 28/03/2011 08:42, Borut Hadžialić wrote: > Hellos Stefan, > > if you can't fix your problem with configuration and decide that you > want to solve the problem by programming, then this might help you > http://blog.springsource.com/2009/09/28/spring-security-kerberos/ > After understanding that article a developer should be able to add a > SPNEGO implementation (probably not the whole protocol, just as much > it is needed for your app) to your Tomcat application by adding some > filters. Or you could just add Spring Security to your app. I'll add that as an option to the new How-To. >> Today I've found Bug 49318 - add a Negotiate (Kerberos/NTLM) authenticator / >> integrate Waffle (https://issues.apache.org/bugzilla/show_bug.cgi?id=49318). >> The last comment links a new Windows Authentication How-To from Mark Thomas. >> Looks like we have already tried almost all proposed solutions: Thanks for the great feedback on the options. I put the existing how-to together pretty much entirely on some Google searches. I'll add your feedback to the how-to / maybe remove some options that don't look viable. >> - IIS + mod_jk: >> tried but stuck in Bug 47679. Also tried ARR to pass the user name >> as a request header from IIS to Tomcat without success >> - Apache mod_ntlm: used it and we replaced it by the much more stable >> mod_auth_ntlm_winbind. NTLMv1 is also disabled on Windows 7 (default) >> - Apache mod_auth_ntlm: in heavy use but stuck to Apache 2.0 and 32bit >> plattform - we couldn't get stability problems solved on Apache 2.2 >> and 64bit Linux. No ongoing development. >> - Apache mod_auth_sspi: till now in internal use for a very small >> project (works just fine), not sure about the future. Although >> there seems to be some new activity on 1.0.5 beta >> - Waffle: found it on thursday and it is on my our todo-list for >> testing it next week >> >> Any chances to get Bug 47679 solved? How can we help (we are admins, no >> devs)? >> What solutions have you deployed? Recommendations? It is tricky to recommend something right now. I'm guessing you want something that a) works reliably and b) is likely to be supported for the long term. Right now Waffle probably comes closest to that. It you can wait a little while, I should have SPNEGO support in Tomcat 7 fairly soon. It may - or may not - get back-ported to Tomcat 6. It will depend on the eventual solution. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Windows Authentication: Issue 49318 vs 47679
Hellos Stefan, if you can't fix your problem with configuration and decide that you want to solve the problem by programming, then this might help you http://blog.springsource.com/2009/09/28/spring-security-kerberos/ After understanding that article a developer should be able to add a SPNEGO implementation (probably not the whole protocol, just as much it is needed for your app) to your Tomcat application by adding some filters. What the implementation needs to do is basically: 1. If there is a 'Negotiate ..' http header or other authentication, read it and process it. 2. Otherwise if there is no authentication, send a spnego challenge //HttpServletResponse response response.addHeader("WWW-Authenticate", "Negotiate"); response.setStatus(HttpServletResponse.SC_UNAUTHORIZED); response.flushBuffer(); On Sun, Mar 27, 2011 at 8:26 PM, Stefan Mayr wrote: > Hello everybody, > > as many others before we wanted to do single-sign-on for intranet web > applications using integrated windows authentication (negotiate because IE > sometimes tries NTLM instead of using plain kerberos - breaking all our > kerberos-only experiments). > > We thought that IIS would be the best choice for integrated windows > authentication and we could pass the user via AJP (using mod_jk) to our > tomcat instances. > > Our setup: > - Windows 2008 R2 using IIS 7.5 (64bit) > - mod_jk 1.2.31 > - Oracle Java 1.6 U24 > - Tomcat 6.0.32 > > At first glance using tomcatAuthentication=false worked as expected. We got > the remote user and started deploying an application. End of happiness - the > application complained about a missing user-agent. That header was not > passed to tomcat when authentication was enabled on IIS. > > Some research revealed Bug 47679 - Not all headers get passed to Tomcat > server from isapi_redirect.dll > (https://issues.apache.org/bugzilla/show_bug.cgi?id=47679) > > Today I've found Bug 49318 - add a Negotiate (Kerberos/NTLM) authenticator / > integrate Waffle (https://issues.apache.org/bugzilla/show_bug.cgi?id=49318). > The last comment links a new Windows Authentication How-To from Mark Thomas. > Looks like we have already tried almost all proposed solutions: > > - IIS + mod_jk: > tried but stuck in Bug 47679. Also tried ARR to pass the user name > as a request header from IIS to Tomcat without success > - Apache mod_ntlm: used it and we replaced it by the much more stable > mod_auth_ntlm_winbind. NTLMv1 is also disabled on Windows 7 (default) > - Apache mod_auth_ntlm: in heavy use but stuck to Apache 2.0 and 32bit > plattform - we couldn't get stability problems solved on Apache 2.2 > and 64bit Linux. No ongoing development. > - Apache mod_auth_sspi: till now in internal use for a very small > project (works just fine), not sure about the future. Although > there seems to be some new activity on 1.0.5 beta > - Waffle: found it on thursday and it is on my our todo-list for > testing it next week > > Any chances to get Bug 47679 solved? How can we help (we are admins, no > devs)? > What solutions have you deployed? Recommendations? > > Thank you, > > Stefan Mayr > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Why? Because YES! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Windows Authentication against multiple domains
I can't suggest any open-source/free products but allow me to suggest reading the following article if you want to roll your own solution one of these days in the windows world: http://www.microsoft.com/msj/0899/kerberos/kerberos.aspx Once you read it, I hope you will be able to see how you can put some amount of work in from your side and leverage Kerberos as a solution across Windows domains. But may be I misunderstood your problem, may be you don't want SSO across multiple domains. Maybe you simply want a piece of code that can connect to multiple ADs instead of just one? I suggest a bit more clarification so that the list readers may understand your use-case. Cheers! On 2/9/07, Suneet Shah <[EMAIL PROTECTED]> wrote: Hello, We have this capability in our open source identity and access management solution where you can use more then one use more then one repository for authentication. You may be able to use just the authentication service as taking on the rest of it may be more then what you need. The project is OpenIAM on sourceforge. We will be putting a new release this weekend. If you are interested in taking a look, let me know and I can send you a link. Regards Suneet On 2/9/07, Uwe_77 <[EMAIL PROTECTED]> wrote: > > > Sure, I will let you know. Perhaps we need third party tools. Doese > someone > knows a solution? > -- > View this message in context: > http://www.nabble.com/RE%3A-Windows-Authentication-against-multiple-domains-tf3203321.html#a8895171 > Sent from the Tomcat - User mailing list archive at Nabble.com. > > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
RE: Windows Authentication against multiple domains
I am yet another barking up that tree. --- "Propes, Barry L [GCG-NAOT]" <[EMAIL PROTECTED]> wrote: > if you find out, please let me know...I'm barking up > that tree, too. > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Friday, February 09, 2007 4:50 PM > To: users@tomcat.apache.org > Subject: Windows Authentication against multiple > domains > > > Hi, > > I am having a tomcat webapplication and logon needs > to be done via > windows-authentication (ldap). I configured > authentication against ldap, > that works fine for one domain. The problem is, that > we are having users in > multiple domains. Is there a way to configure > authentication against the > whole active directory forest? > > Thanks for your help! > > Uwe > > > - > To start a new topic, e-mail: > users@tomcat.apache.org > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Windows Authentication against multiple domains
Hello, We have this capability in our open source identity and access management solution where you can use more then one use more then one repository for authentication. You may be able to use just the authentication service as taking on the rest of it may be more then what you need. The project is OpenIAM on sourceforge. We will be putting a new release this weekend. If you are interested in taking a look, let me know and I can send you a link. Regards Suneet On 2/9/07, Uwe_77 <[EMAIL PROTECTED]> wrote: Sure, I will let you know. Perhaps we need third party tools. Doese someone knows a solution? -- View this message in context: http://www.nabble.com/RE%3A-Windows-Authentication-against-multiple-domains-tf3203321.html#a8895171 Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Windows Authentication against multiple domains
Sure, I will let you know. Perhaps we need third party tools. Doese someone knows a solution? -- View this message in context: http://www.nabble.com/RE%3A-Windows-Authentication-against-multiple-domains-tf3203321.html#a8895171 Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Windows Authentication against multiple domains
if you find out, please let me know...I'm barking up that tree, too. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, February 09, 2007 4:50 PM To: users@tomcat.apache.org Subject: Windows Authentication against multiple domains Hi, I am having a tomcat webapplication and logon needs to be done via windows-authentication (ldap). I configured authentication against ldap, that works fine for one domain. The problem is, that we are having users in multiple domains. Is there a way to configure authentication against the whole active directory forest? Thanks for your help! Uwe - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]