Heidi, I have the set of test VMs I used when first implementing this feature. They are the ones I used when I wrote: http://tomcat.apache.org/tomcat-9.0-doc/windows-auth-howto.html
I'll fire them up, install 9.0.24, test and report back. I have done a quick diff of the key classes between 9.0.x and 8.5.x and I don't see any changes that should cause problems. Experience tells me I am going to spend more time getting the VMs updated with the latest patches (I don't turn them on that often) than I am going to spend testing. Don't be surprised if it takes until tomorrow for me to report back. Mark On 03/09/2019 17:38, Heidi Leerink - Duverger wrote: > Hello Alex, > > This is the result of the nslookup: > > C:\Users\hduverge>nslookup nlsl-decadetest > Server: nlsl-dccrp01p.corp.u4agr.com > Address: 10.100.2.2 > > *** nlsl-dccrp01p.corp.u4agr.com can't find nlsl-decadetest: Non-existent > domain > > C:\Users\hduverge> > C:\Users\hduverge>nslookup nlsl-decadetest.u4agr.com > Server: nlsl-dccrp01p.corp.u4agr.com > Address: 10.100.2.2 > > *** nlsl-dccrp01p.corp.u4agr.com can't find nlsl-decadetest.u4agr.com: > Non-existent domain > >> Q3: Is the PC where you are using the browser to test, also the same one >> where Tomcat is installed ? >> (I am not sure that this type of authentication should work, if the same >> machine is at the same time the client and the server) In any case, it may >> >be a good idea if you tested the same access, with a browser on another PC >> workstation. > I test the SSO URL on my own desktop in Google chrome and IE11, but if I test > de URL in IE11 on de nls-decadetest it asks for a window login and then gives > the same error as I get on my desktop. > > I think that it would be better to move this test to a real server , but ATM > we have everything in the cloud (azure) and it is so nearly impossible to get > a setup (AD user principal and tomcat.keytab) from support, but I will check > if I can further test at our customers site.... > > Thank you for your help with this, it must be that Tomcat 9 SPNEGO is more > strict than the Tomcat 8 implementation was... > > Met vriendelijke groeten van > Heidi Leerink - Duverger > Technisch Consultant > > > In business for people. > Unit4 Business Software Netherlands B.V. > Papendorpseweg 100, 3710 BJ Utrecht, Netherlands > T +31 88 247 1444 > E heidi.duver...@unit4.com > This message and any attachment(s) are intended only for the use of the named > recipient and may contain information that is privileged, confidential or > otherwise exempt from disclosure under applicable law. If you are not the > intended recipient, please notify the sender by return e-mail and delete this > message from your system. Do not disclose the contents of this document to > any other persons. Violation of this notice may be unlawful. Please note that > internet communications are not secure and e-mails are susceptible to change. > Thank you for your cooperation. > > -----Original Message----- > From: André Warnier (tomcat) [mailto:a...@ice-sa.com] > Sent: dinsdag 3 september 2019 14:27 > To: users@tomcat.apache.org > Subject: Re: SSO fails on Tomcat 9 > > Hi. > See below. > > On 03.09.2019 11:56, Heidi Leerink - Duverger wrote: >> Hello Alex, >> >> Thank you for the extensive answer. >> >> Q1: Are you sure that it is *exactly* the same ? >> Yes the installation is done on the same PC with the same user principal for >> the Tomcat service to log in . >> The Tomcat 8 service is stopped during the Tomcat 9 test. >> We had the exact same problem when installing in a test environment at one >> of our Customer sites. Most of our customers that are using SSO with our >> application are still using Tomcat 8 with no problems and all with the same >> spnego config. >> My colleague initially set up this Tomcat 9 installation using a few tomcat >> 9 versions ( .8 .20 and .24). I myself, reinstalled and configured Tomcat >> 9.024 from scratch, with no success and always the same results. >> > > Q3: Is the PC where you are using the browser to test, also the same one > where Tomcat is installed ? > (I am not sure that this type of authentication should work, if the same > machine is at the same time the client and the server) In any case, it may be > a good idea if you tested the same access, with a browser on another PC > workstation. > >> Q2: when "it does not work", does the browser popup a login dialog ? >> Yes I have seen that one be not with the recent config. >> Browser response : >> >> Google Chrome >> This site can't be reachedThe webpage at http://nlsl-decadetst:8787/apex42a/ >> might be temporarily down or it may have moved permanently to a new web >> address. >> ERR_INVALID_RESPONSE >> >> Internet Explorer 11: >> Can't reach this page >> .Make sure the web address http://nlsl-decadetst:8787 is correct >> .Search for this site on Bing .Refresh the page More information More >> information The connection to the website was reset. >> Error Code: INET_E_DOWNLOAD_FAILURE >> > > Both of the errors above indicate more a DNS or TCP issue, than a tomcat or > authentication issue. > (As shown, they indicate that the browser can either not find the server > "nlsl-decadetst", or cannot make a TCP connection to "nlsl-decadetst:8787") > > On the same workstation PC where you are doing these tests, can you > a) open a command window > b) enter : nslookup nlsl-decadetst > c) tell us what the response is ? > d) enter : nslookup nlsl-decadetst.u4agr.com > e) tell us what the response is ? > >> (attachements the most recent stderr and stdout) >> > > Unfortunately, I am no Kerberos specialist and cannot tell you what the > messages in the log really mean. > But the following (from the stderr) should probably be investigated further : > >>>KRBError: > sTime is Tue Sep 03 11:47:29 CEST 2019 1567504049000 > suSec is 329207 > error code is 25 > error Message is Additional pre-authentication required > sname is krbtgt/u4agr....@u4agr.com > eData provided. > msgType is 30 > > That seems to indicate that something is not working as expected, at the > Kerberos level. > > > Note : why it would work with tomcat8 and not with tomcat9 is still not clear > to me, unless there have been some changes between the tomcat8 SPNEGO Valve > and the tomcat9 SPNGEGO Valve, or else maybe in terms of the tomcat hostname > considerations. > >> >> I know off Fiddler2 but never used it before, I will try to set that up... >> >> >> Met vriendelijke groeten van >> Heidi Leerink - Duverger >> Technisch Consultant >> >> >> In business for people. >> Unit4 Business Software Netherlands B.V. >> Papendorpseweg 100, 3710 BJ Utrecht, Netherlands >> T +31 88 247 1444 >> E heidi.duver...@unit4.com >> This message and any attachment(s) are intended only for the use of the >> named recipient and may contain information that is privileged, confidential >> or otherwise exempt from disclosure under applicable law. If you are not the >> intended recipient, please notify the sender by return e-mail and delete >> this message from your system. Do not disclose the contents of this document >> to any other persons. Violation of this notice may be unlawful. Please note >> that internet communications are not secure and e-mails are susceptible to >> change. Thank you for your cooperation. >> >> -----Original Message----- >> From: André Warnier (tomcat) [mailto:a...@ice-sa.com] >> Sent: dinsdag 3 september 2019 10:39 >> To: users@tomcat.apache.org >> Subject: Re: SSO fails on Tomcat 9 >> >> Hello Heidi. >> >> Thank you for the complete information provided in your post below. >> >> I do not have any experience with the Tomcat SPNEGO Valve per se, but quite >> a bit of experience with Windows Integrated Authentication. >> To me, the symptoms that you describe below, do not really look like a >> problem at the Tomcat level, but more like a problem between the browser and >> the Windows authentication in general. >> >> See notes and questions in the text below. >> >> On 02.09.2019 12:35, Heidi Leerink - Duverger wrote: >>> We have the following problem with connecting from the tomcat >>> environment 9.024 with the Active Directory of Windows, Kerberos >>> database. (win2008 DC's) >>> >>> In Tomcat's log files, with Tomcat8, which gives no problems, it is >>> connected to the Active directory. >>> >>> It indicates that a login attempt is made 3 times whether the person >>> can log in with the Active directory account. >>> >>> After that the login is accepted and qualified as successful. >>> >>> In tomcat 9, different versions tried, also version 9.024, the control >>> of 1 attempt becomes visible, >>> >>> which is successful. But then the check is stopped (not 3 times as >>> Tomcat8) and the connection is marked as unsuccessful. >>> >>> The environment for Tomcat9 is the same as from Tomcat8. >> >> Q1: Are you sure that it is *exactly* the same ? >> For example, do the tomcat8 installation, and the tomcat9 installation, run >> on the same server, and is the server *domain* the same in both cases ? >> >> Q2: when "it does not work", does the browser popup a login dialog ? >> >> Reason for the questions : >> Typically, a succesful Windows authentication consists of indeed 3 exchanges >> (what you say happens with tomcat8). >> The first of these exchanges consists of the browser requesting the original >> URL. >> The server then responds with a 401 response ("need authentication"), in >> which it indicates that it wants an authentication, of the SPNEGO type. >> The browser then normally responds with a 2d request for the same URL, >> containing a partial "Authorization:" header containing some encrypted token. >> If the browser does NOT send this 2d request, it indicates that *the browser >> refuses* to do an SPNEGO authentication in this case. >> And that happens when the browser does not think that the server "can be >> trusted" for doing SPNEGO authentication. >> The browser will not trust the server, if it thinks that the server is not >> in the same domain as itself (unless you have manually added this server in >> the "trusted servers", at the browser level). >> >> Q2: Usually, when the browser refuses to do a WIA authentication, it tries a >> Basic authentication instead, and this login dialog pops up. With Windows >> authentication, that is usually the first sign that something is not correct >> in the browser/server setup. >> >> Note: I'm not saying that this IS your problem. But it is the first thing to >> verify, with WIA authentication. >> >> To see this more clearly, you could try to install on the workstation, some >> software that allows you to trace the HTTP exchanges between the browser and >> the server (example : >> Fiddler2), and compare what happens with tomcat8 and tomcat9 (look at the >> HTTP headers for request/response). >> >>> >>> Windows 10 PRO >>> >>> Oracle database rdbms 11.203 >>> >>> Apex 4.2.3.008 >>> >>> Ords2019 - Oracle listener >>> >>> ojdbc6.jar >>> >>> Tried both java versions: >>> >>> E:\java\jre64b\bin>java -version >>> >>> java version "1.8.0_202" >>> >>> Java(TM) SE Runtime Environment (build 1.8.0_202-b08) >>> >>> Java HotSpot(TM) 64-Bit Server VM (build 25.202-b08, mixed mode) >>> >>> And >>> >>> E:\java\openjdk\bin>java -version >>> >>> openjdk version "11.0.1" 2018-10-16 >>> >>> OpenJDK Runtime Environment 18.9 (build 11.0.1+13) >>> >>> OpenJDK 64-Bit Server VM 18.9 (build 11.0.1+13, mixed mode) >>> >>> Tomcat 9.024 directory structure. >>> >>> ( log files in the attachments ) >>> >>> e:\Tomcat9\ >>> >>> \Cataline\localhost\apex42a.xml >>> >>> +++...+++ >>> >>> <?xml version="1.0" encoding="UTF-8"?> >>> >>> <Context> >>> >>> <Valve className="org.apache.catalina.authenticator.SpnegoAuthenticator" >>> >>> loginConfigName="APEX42A" >>> >>> /> >>> >>> <Realm className="org.apache.catalina.realm.JAASRealm" >>> >>> allRolesMode="authOnly" >>> >>> appName="APEX42A" >>> >>> /> >>> >>> </Context> >>> >>> +++...+++ >>> >>> \conf\jaas.conf >>> >>> +++...+++ >>> >>> APEX42A { >>> >>> com.sun.security.auth.module.Krb5LoginModule required >>> >>> doNotPrompt=true >>> >>> principal="HTTP/nlsl-decadetst.u4agr....@u4agr.com" >>> >>> useKeyTab=true >>> >>> keyTab="E:/Decade_appl/Tomcat9/conf/tomcat.keytab" >>> >>> storeKey=true; >>> >>> }; >>> >>> +++...+++ >>> >>> \conf\krb5.ini >>> >>> +++...+++ >>> >>> [libdefaults] >>> >>> default_realm = U4AGR.COM >>> >>> default_tkt_enctypes = rc4-hmac aes256-cts-hmac-sha1-96 >>> aes128-cts-hmac-sha1-96 >>> >>> default_tgs_enctypes = rc4-hmac aes256-cts-hmac-sha1-96 >>> aes128-cts-hmac-sha1-96 >>> >>> permitted_enctypes = rc4-hmac aes256-cts-hmac-sha1-96 >>> aes128-cts-hmac-sha1-96 >>> >>> dns_lookup_kdc = true >>> >>> dns_lookup_relam = false >>> >>> [realms] >>> >>> U4AGR.COM = { >>> >>> kdc = u4agr.com >>> >>> default_domain = U4AGR.COM >>> >>> } >>> >>> [domain_realm] >>> >>> .u4agr.com= U4AGR.COM >>> >>> u4agr.com= U4AGR.COM >>> >>> +++...+++ >>> >>> \conf\tomcat.keytab >>> >>> Creation statement for tomcat.keytab: >>> >>> ktpass /out c:\Temp\tomcat.keytab /mapuser DECADE_SSO_TC.U4AGR.COM /princ >>> HTTP/nlsl-decadetst.u4agr....@u4agr.com /pass "D3cad3401" /kvno 0 -ptype >>> KRB5_NT_PRINCIPAL >>> >>> ktpass /out c:\temp\1c-tomcat.keytab /mapuser DECADE_SSO_TC.U4AGR.COM /princ >>> HTTP/nlsl-decadetst.u4agr....@u4agr.com /pass "D3cad3401" -crypto All /kvno >>> 0 -ptype >>> KRB5_NT_PRINCIPAL >>> >>> \webapps\apex42a\WEB-INF\web.xml >>> >>> +++...+++ >>> >>> <servlet-mapping> >>> >>> <servlet-name>Forbidden</servlet-name> >>> >>> <url-pattern>/oracle/dbtools/jarcl</url-pattern> >>> >>> </servlet-mapping> >>> >>> <security-constraint> >>> >>> <web-resource-collection> >>> >>> >>> <web-resource-name>APEX42A</web-resource-name> >>> >>> <url-pattern>/*</url-pattern> >>> >>> </web-resource-collection> >>> >>> <auth-constraint> >>> >>> <role-name>*</role-name> >>> >>> </auth-constraint> >>> >>> </security-constraint> >>> >>> <login-config> >>> >>> <auth-method>SPNEGO</auth-method> >>> >>> </login-config> >>> >>> <welcome-file-list> >>> >>> <welcome-file>index.html</welcome-file> >>> >>> <welcome-file>index.htm</welcome-file> >>> >>> +++...+++ >>> >>> *Met vriendelijke groeten van*** >>> >>> *Heidi Leerink - Duverger* >>> *Technisch Consultant* >>> >>> Unit4 >>> In business for people. >>> >>> *Unit4 Business Software Netherlands B.V.* >>> Papendorpseweg 100, 3710 BJ Utrecht, Netherlands >>> >>> *T *+31 88 247 1444 >>> *E *heidi.duver...@unit4.com >>> >>> This message and any attachment(s) are intended only for the use of the >>> named recipient >>> and may contain information that is privileged, confidential or otherwise >>> exempt from >>> disclosure under applicable law. If you are not the intended recipient, >>> please notify the >>> sender by return e-mail and delete this message from your system. Do not >>> disclose the >>> contents of this document to any other persons. Violation of this notice >>> may be unlawful. >>> Please note that internet communications are not secure and e-mails are >>> susceptible to >>> change. Thank you for your cooperation. >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> 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 >> >> >> >> >> --------------------------------------------------------------------- >> 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 > > > --------------------------------------------------------------------- > 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
