Re: Microsoft Edge (Chromium based) not prompting for logons
On Mon, 2020-09-14 at 09:12 -0400, Christopher Schultz wrote: > Are you using HTTP or HTTPS? HTTPS. > TLDR: visit edge://policy in Edge and look for AuthSchemes. If the > value doesn't include "basic", add it and re-try. Yeah, that was it - I wasn't able to change our edge settings - that's locked down by others. Finding out where to change the authentication methods at the tomcat end was a bit harder than I hoped - I'd assumed it was in the tomcat server area, rather than th eapplication itself, which explains why I wasn't able to find much in the documentation - I was looking at the wrong place. Thanks very much - got a route forward throug this now Thanks Dave
Microsoft Edge (Chromium based) not prompting for logons
We've set up out Tomcat Manager to use LDAP for authentication - (note, this is not MS AD, but linux-based LDAP server). The OS our tomcat servers are running on is Linux and they're not intergrated with our AD domain in any way at all. Our users have been happily logging into the Tomcat manager app using various web browsers for some time - they get prompted for a username and password, they provide their credentials (which is the same user name and password as they're currently logged onto windows with, but with no domain\ or @domain info in the username), they're checked against LDAP servers, and are let into the app assuming they're allowed. However, we've recently received reports that some of our users who have had their Windows machines copies of Edge upgraded to the latest version are no longer being prompted for credentials. Instead, they're directly immediately to a 401 unauthorised message. Other browsers, including Chrome, still prompt. We've changed nothing at the tomcat end, so this is clearly a problem with the behaviour of Edge - but I'm keep to try and understand it. I can't find any useful information in the tomcat logs - is it possible to turn up the logging for the manager app to see exactly what credentials (well, username) is being passed by Edge to it? Thanks Dave
Re: Fix for the Ghostcat vulnerability
On Wed, 2020-03-04 at 13:19 -0500, Christopher Schultz wrote: > > > We're in the same position as you. External web servers talking > > to Tomcat servers on other boxes via AJP. > > Are those connections properly secured? That's not a tremendously helpful question. Which connections are you talking about? How do you propose 'securing' an AJP connection? > If your connections are properly-secured, simply set > secretRequired="false" and move on. If they aren't properly-secured, > then you need to fix that (and you had to fix that before this recent > announcement). Can you point the ill-informed amongst us to any helpful resources you may have that describe what you mean by 'properly secured'? Regards Dave
Re: issue faced in tomcat 8.5.51
On Fri, 2020-02-28 at 13:39 +, Rathore, Rajendra wrote: > Caused by: java.lang.IllegalArgumentException: The AJP Connector is > configured with secretRequired="true" but the secret attribute is > either null or "". This combination is not valid. Are you talking to this via an apache webserver using mod_proxy_ajp? Only, the current stable release of apache (2.4.41) doesn't support 'secret' AFAIK. See https://httpd.apache.org/docs/2.4/mod/mod_proxy_ajp.html and https://bz-he-de.apache.org/bugzilla/show_bug.cgi?id=53098 Note the above 'bug' in Apache is only 12 years old :-( Dave
Re: Fix for the Ghostcat vulnerability
On Wed, 2020-03-04 at 10:24 +0100, Jürgen Göres wrote: > > If it is, what is the recommended mitigation? We consider using the > "secret" feature (the filtering by request attributes is infeasible > for us), but that would be a bit of effort and we are in a hurry. > We're in the same position as you. External web servers talking to Tomcat servers on other boxes via AJP. We've looked at a few options, none of which seemed great: * The current stable version of Apache doesn't support the 'secret' attribute for AJP connectors in mod_proxy. * Valves can be used to secure Tomcat from listening to certain IPs Hostnames or subnets/vlans. But * The RemoteCIDRValve affects every protocol/port. * The RemoteHostValve and RemoteAddrValve only allow a single allow or deny rule, which needs a regexp to match every required combinations of port and address/names for the whole of the desired context. In ours case, we'd want to permit a different set of hosts on AJP to those who can read the manager app, for instance. As this is being managed by puppet at our end, we decided the required regexp would be too complex and breakable and are probably going to isolate the AJP traffic using a firewall rule via iptables instead of relying on any intrinsic Tomcat feature. Dave
Minor version upgrades
Hello, We've running many instances of Tomcat 8.5 on some dozens of linux servers. All of this is being managed by Puppet using the puppetforge tomcat module. The Puppet module that deploys tomcat simple checks to see if the NOTICE file is the correct place to determine whether or not it should unpack a provided tarball into Catalina_home. My question is this - as we've gone and placed our catalina_base folder within a subfolder of catalina_home, we're not going to want to simply delete the C_H folder to reinstall a newer version. Is it safe/sane to unpack a new minor release (say 8.5.40) over the existing installation of (8.4.32) over an existing Catalina_Home? Or should I simply bite the bullet, rework my puppet code to deploy the instances outside of Catalina_Home and wipe C_H before redeploying it with a newer version? Regards, Dave - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Minor version upgrading
Hello, We've running many instances of Tomcat 8.5 on some dozens of linux servers. All of this is being managed by Puppet using the puppetforge tomcat module. The Puppet module that deploys tomcat simple checks to see if the NOTICE file is the correct place to determine whether or not it should unpack a provided tarball into Catalina_home. My question is this - as we've gone and placed our catalina_base folder within a subfolder of catalina_home, we're not going to want to simply delete the C_H folder to reinstall a newer version. Is it safe/sane to unpack a new minor release (say 8.5.40) over the existing installation of (8.4.32) over an existing Catalina_Home? Or should I simply bite the bullet, rework my puppet code to deploy the instances outside of Catalina_Home and wipe C_H before redeploying it with a newer version? Regards, Dave
Re: Beginner help setting up test vertical cluster
On Mon, 2017-10-30 at 09:15 -0400, Christopher Schultz wrote: > Dave, > > Can you please post your and associated elements from > conf/server.xml -- minus any secrets that may have crept in there? > Also, what does your network look like? Any intermediates such as > load > balancers/firewalls? What about software firewalls? Hi Chris - thanks for responding. This is all running withing a single machine with no firewall, so nothing should be getting in the way network wise. Here's the my server.xml from one of the instances, with the comments removed and IPs and Hostnames removed also. The IPs/Hostnames are the same on the other server.xml, with just the Member and StaticMember UniqueIDs and port number entries appropriately reversed. Dave --
Beginner help setting up test vertical cluster
Hello,
I should apologise in advance as I'm very new to Tomcat and, I'm sure,
will be making some daft mistakes and silly errors. I hope this
question and any that follow it aren't too dumb.
I've recently started a new job and have inherited a half-finished
tomcat cluster on solaris.
While I'm not going to immediately try and finish that cluster, I would
like to try setting up some test instances to ensure I know what to
expect - but I'm having trouble doing even this.
I've gotten my head round how to set up individual instances of Tomcat
8.5.23 running from different sub folders of a common CATALINA_HOME
folder, and now I'm trying to get the two instances to talk to each
other using StaticMember on specific ports rather than the automatic
multicasting.
But instances start up, and the logs at least suggest they're aware of
each other. But one server takes forever to start, and I'm not
convinced they're talking to each other properly. For example, in the
catalina.out logs I'm seeing messages such as:
30-Oct-2017 09:28:29.632 INFO [MyHost-startStop-1]
org.apache.catalina.ha.session.DeltaManager.getAllClusterSessions
Manager [/sample], requesting session state from
[org.apache.catalina.tribes.membership.StaticMember[tcp://my.ip.addr:40
01,my.ip.addr,4001, alive=0, securePort=-1, UDP Port=-1, id={1 2 3 4 5
6 7 8 9 10 11 12 13 14 15 0 }, payload={}, command={}, domain={99 108
117 115 116 101 114 116 101 ...(11)}, ]]. This operation will timeout
if no session state has been received within [60] seconds.
30-Oct-2017 09:28:34.111 WARNING [Tribes-Task-Receiver[MyHost-Channel]-
2]
org.apache.catalina.tribes.group.interceptors.DomainFilterInterceptor.m
essageReceived Received message from
cluster[org.apache.catalina.tribes.membership.MemberImpl[tcp://{my, ip,
nn, nn}:4001,{my, ip, nn, nn},4001, alive=1509355714104, securePort=-
1,
UDP Port=-1, id={1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0 }, payload={},
command={}, domain={99 108 117 115 116 101 114 116 101 ...(11)}, ]] was
refused.
Which does not seem encouraging. Yet on the other instance, I'm
seeing:
30-Oct-2017 09:28:34.105 INFO [GroupChannel-Heartbeat[MyHost-Channel]-
1] org.apache.catalina.ha.tcp.SimpleTcpCluster.memberAdded Replication
member
added:[org.apache.catalina.tribes.membership.StaticMember[tcp://my.ip.a
ddr:4000,my.ip.addr,4000, alive=0, securePort=-1, UDP Port=-1, id={0 1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 }, payload={}, command={}, domain={99
108 117 115 116 101 114 116 101 ...(11)}, ]]
30-Oct-2017 09:28:34.105 INFO [GroupChannel-Heartbeat[MyHost-Channel]-
1]
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.perfor
mBasicCheck Suspect member, confirmed
alive.[org.apache.catalina.tribes.membership.StaticMember[tcp://my.ip.a
ddr:4000,my.ip.addr,4000, alive=0, securePort=-1, UDP Port=-1, id={0 1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 }, payload={}, command={}, domain={99
108 117 115 116 101 114 116 101 ...(11)}, ]]
Which seems better... But then I see back on instance one,
30-Oct-2017 09:32:30.178 INFO [main]
org.apache.catalina.startup.Catalina.start Server startup in 241109 ms
Which seems really bad.
I've installed the 'examples' app on both instances, have added
'' to both's web.xml file.
I can see on one instance a message such as
30-Oct-2017 09:35:22.600 INFO [http-nio-8081-exec-7]
org.apache.catalina.core.ApplicationContext.log SessionListener:
sessionCreated('C2C3720879E72D558EEF4B0655188EBD.beta')
30-Oct-2017 09:35:26.912 INFO [http-nio-8081-exec-8]
org.apache.catalina.core.ApplicationContext.log SessionListener:
attributeAdded('C2C3720879E72D558EEF4B0655188EBD.beta', 'foo', 'bar')
When I play with the sessions example code. But nothing on the other
instance that would suggest this is being replicated.
Before I make this post too long and post my server.xml code, could
someone advise me as to what I should be looking for, or what these
messages suggest? Any pointers at this stage would be grateful as I'm
unsure even what a working cluster should look like.
Thanks
Dave
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
