As Nick mentioned, before going further, it's really critical to figure out
where your logs are. They will be somewhere. In addition to messages noting
the login failures, there will be messages noting the extensions that were
successfully loaded, as well as relevant errors regarding things like
certificate validation for LDAPS, the network connection to the database,
etc. Lacking that information, guessing at possible causes will be
counterproductive, as will making configuration changes based on those
guesses.
If you're using the "tomcat" package installed directly from Red Hat's
repository, it will be logging to the systemd journal. If you don't see
logs there, I suggest re-checking - they should be there. For the standard
"tomcat" package, you can narrow the output of journalctl to just messages
from the relevant systemd unit:
journalctl -u tomcat
If you are not using the package from Red Hat's repository, you'll need to
consult the documentation of the vendor providing your Tomcat package to
find out where they put their logs.
Michael Jumper
CEO, Lead Developer
Glyptodon Inc <https://glyp.to/>.
On Thu, Apr 22, 2021 at 11:01 PM Allugulapathi, Santhosh
<santhosh.allugulapat...@anz.com.invalid> wrote:
> We use the internal CA certificate and it is having a trusted certificate
> entry as below.
>
>
>
> [root@guac-host-2-0d3ba5 jre]# keytool -list -keystore
> /usr/lib/jvm/java-1.8.0-ibm-1.8.0.6.25-1jpp.1.el7.x86_64/jre/lib/security/cacerts
> | grep anz
>
> Enter keystore password:
>
>
>
> ***************** WARNING WARNING WARNING *****************
>
> * The integrity of the information stored in the keystore *
>
> * has NOT been verified! In order to verify its integrity, *
>
> * you must provide the srckeystore password. *
>
> ***************** WARNING WARNING WARNING *****************
>
>
>
> certv2, Feb 11, 2021, trustedCertEntry,
>
>
>
> Below is snap of ps -ef | grep java. Is it having the correct
> configuration.
>
>
>
> tomcat 17701 1 0 Apr20 ? 00:01:13 /usr/lib/jvm/jre/bin/java
> -Djavx.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory
> -classpath
> /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar
> -Dcatalina.base=/usr/share/tomcat -Dcatalina.home=/usr/share/tomcat
> -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat/temp
> -Djava.util.logging.config.file=/usr/share/tomcat/conf/logging.properties
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> org.apache.catalina.startup.Bootstrap start
>
> root 25899 25812 0 05:52 pts/0 00:00:00 grep --color=auto java
>
> Thanks
> Santhosh
>
> From: Nick Couchman <vn...@apache.org>
> Reply to: "user@guacamole.apache.org" <user@guacamole.apache.org>
> Date: Thursday, 22 April 2021 at 11:21 PM
> To: "user@guacamole.apache.org" <user@guacamole.apache.org>
> Subject: Re: Apache Guacamole [Invalid Login] using AD LDAP
>
> On Wed, Apr 21, 2021 at 2:23 PM Allugulapathi, Santhosh
> <santhosh.allugulapat...@anz.com.invalid> wrote:
> It is pointing unidirectional quotes may be the mail format changed it ,
> its OU="Service Accounts".
>
> Try removing the quotes entirely - they really should not be needed.
>
> Also, you mentioned earlier that you are using LDAPS - you need to make
> sure that the certificate for your LDAP server is trusted by Tomcat, which
> is usually done by adding it to the cacerts keystore for the version of
> Java that is running Tomcat, and then restarting Tomcat. My experience with
> LDAP servers and certificates is that they are usually either self-signed
> or signed by an internal CA (e.g. AD, eDirectory, etc.) and not by a
> globally trusted CA. This is also documented in the manual:
> http://guacamole.apache.org/doc/gug/ldap-auth.html#guac-ldap-config
>
>
> Checked the journalctl logs no messages are getting logged in it aswell.
> Tried to login into guacamole using both LDAP aswell as gucaadmin but no
> loggings are happening.
>
> You really need to determine where the logs are going on your system -
> that will be the key to figuring out why authentication is failing.
>
> -Nick
> "This e-mail and any attachments to it (the "Communication") is, unless
> otherwise stated, confidential, may contain copyright material and is for
> the use only of the intended recipient. If you receive the Communication in
> error, please notify the sender immediately by return e-mail, delete the
> Communication and the return e-mail, and do not read, copy, retransmit or
> otherwise deal with it. Any views expressed in the Communication are those
> of the individual sender only, unless expressly stated to be those of
> Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any
> of its related entities including ANZ Bank New Zealand Limited (together
> "ANZ"). ANZ does not accept liability in connection with the integrity of
> or errors in the Communication, computer virus, data corruption,
> interference or delay arising from or in respect of the Communication."
>
