You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@guacamole.apache.org by sh...@gmx.com on 2023/08/01 19:48:17 UTC
Guacamole Auth Header
Hello,
I'm using Guacamole v1.5.1 with LDAP/MySQL under RHEL 8.8 and NGINX. It works perfectly.
Access to this Guacamole server is made after an MFA authentication (Fortigate Web SSL bookmark) and I would like to minimize as much as possible the number of times the user must enter his identifiers. It seems that the Auth-Header extension answers this need but I can't login without entering my password.
Could you help me?
Thanks
Shaguu
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: Passing IP of connecting client through Proxy
Posted by Robert Dinse <na...@eskimo.com.INVALID>.
The issue with that is Guacamole provides no method for
authenticating against NIS so that does me no good. I don't want to
change 20 machines over from NIS to LDAP just to get this to work. Many
of the clients are not terribly Linux savvy, adding an additional layer
is NOT beneficial from a business standpoint. It would just frustrate
users and drive them elsewhere.
I am a one person company maintaining 500 clients, I don't want to
have to maintain multiple authentication databases, there just are not
enough hours in the day.
I don't care what program does the authentication as long as it can
work from the existing database and the user doesn't have to remember
more login tokens because frankly some of them have problems just
remembering a password. This is not the only way users connect. They
also connect via rdp, vnc, ssh, and x2go, but by all those methods, the
host received the IP address of the originating machine and thus
fail2ban can work with them.\
If I knew Java it probably would not be a big deal to write an
authentication interface that talks to pwauth the same way Apache does,
but I don't.
If I even had a way to attach the guacamole session to the login
session of the host so that when the host fails I could go back and find
what IP address guacamole received and then write a fail2ban jail for
that it would be a pain but potentially doable. Then again in the past
when there was no auth it didn't materialize as a huge issue even though
it could have been perhaps because it was just unusual enough that the
script kiddies didn't have prebuilt tools or perhaps too slow to make it
practical. But if it ever becomes sufficiently popular, someone will
write the tools.
Frustrating, so close but so far away. If apache could have done
the auth, that would have been great because IT can use the same NIS
database AND it gets the connecting IP so it can log the failed logins.
I do not understand why the authentication works with web apps it serves
directly but not with a proxy.
On 8/6/23 00:16, Michael Jumper wrote:
> The headers that you've been working with here will only affect
> whether Tomcat and Guacamole see you as coming from your actual IP
> address instead of the address of the proxy in front of Tomcat.
>
> The destination remote desktop will always see the connecting client
> address as that of the Guacamole server. If you wish to prevent brute
> force auth attempts, the way to do that would be to configure fail2ban
> on the *Guacamole* server such that repeated failing attempts to
> authenticate with *Guacamole* will be blocked at the firewall level.
>
> One of the primary benefits of deploying Guacamole in front of a set
> of servers is to leverage Guacamole as a security layer in front of
> those servers. I would not recommend instead relying on the
> destination servers themselves to provide this. The authentication
> systems of those servers should only come into play after Guacamole
> has established that the user attempting to connect is authorized.
> Ideally, the destination servers would be configured to accept
> connections only from the Guacamole server.
>
> - Mike
>
> On 8/5/2023 7:00 PM, Robert Dinse wrote:
>>
>> I apologize, someone replied to this and I accidentally deleted
>> your reply, but you asked what IP was tomcat logging, and if I'm
>> looking in the right place, in catalina.out:
>>
>> catalina.out:[2023-08-04 17:35:02] [info] 17:35:02.572
>> [http-nio-8080-exec-8] INFO o.a.g.event.EventLoggingListener - User
>> "public" (authenticated by "default") successfully authenticated from
>> [50.251.249.49, 127.0.0.1]
>>
>> In localhost_access_log.2023-08-04.txt.gz:
>>
>> localhost_access_log.2023-08-04.txt.
>>
>> These are both in /var/log/tomcat9.
>>
>> 50.251.249.49 is actually the IP address I am originating
>> from but when I connect to a host, the host sees the connection
>> coming from 204.122.16.20 which is that of the web server. I
>> personally do not understand how it could possibly pass the
>> originating IP address to the host it's connecting to since it is
>> originating the connection from the web server.
>>
>> On 8/4/23 18:12, Robert Dinse wrote
>>>
>>>
>>> I still haven't gotten Apache external authentication to work
>>> properly. I did manage to get mod_authnz_external to peacefully
>>> co-exist with mod_suphp, the secret was to compile
>>> mod_authnz_external and dynamically load it rather than compiling it
>>> statically into httpd, which would have been my preference. But,
>>> for some reason it will work with a static web page or PHP
>>> application, but not a proxy, but that's another issue.
>>>
>>> For now I am just trying to get the Apache to pass the IP of
>>> the connecting customer through to Tomcat, have it pass it through
>>> to the guacamole process so that when a user connects to a host, the
>>> host sees the IP the user is originating from and not the IP of the
>>> web server. I was referred to this webpage for instructions:
>>>
>>> https://guacamole.apache.org/doc/gug/reverse-proxy.html#setting-up-the-remote-ip-valve
>>>
>>>
>>> And so I've setup the <host> section in Tomcat9 as follows:
>>>
>>> The website shows to add this valve to the <host> section of
>>> the server.xml file:
>>>
>>> <ValveclassName="org.apache.catalina.valves.RemoteIpValve"
>>> internalProxies="127.0.0.1"
>>> remoteIpHeader="x-forwarded-for"
>>> remoteIpProxiesHeader="x-forwarded-by"
>>> protocolHeader="x-forwarded-proto"/> Here is what the <host> section
>>> of my servers.xml looks like: <Host name="localhost"
>>> appBase="webapps" unpackWARs="true" autoDeploy="true"> <!--
>>> SingleSignOn valve, share authentication between web applications
>>> Documentation at: /docs/config/valve.html --> <!-- <Valve
>>> className="org.apache.catalina.authenticator.SingleSignOn" /> -->
>>> <!-- Access log processes all example. Documentation at:
>>> /docs/config/valve.html Note: The pattern used is equivalent to
>>> using pattern="common" --> <Valve
>>> className="org.apache.catalina.valves.AccessLogValve" directory="
>>> logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %u
>>> %t "%r" %s %b" /> <Valve
>>> className="org.apache.catalina.valves.RemoteIpValve"
>>> internalProxies="127.0.0.1" remoteIpHeader="x-forwarded-for"
>>> remoteIpProxiesHeader="x-forwarded-by"
>>> protocolHeader="x-forwarded-proto" /> </Host> Note that guacamole is
>>> the only application I have running under tomcat9. I have another
>>> Java application running (yacy) but it is not containerized. Then it
>>> shows for the Apache:
>>> <Location/guacamole/> Orderallow,deny Allowfromall
>>> ProxyPasshttp://HOSTNAME:8080/guacamole/flushpackets=on
>>> ProxyPassReversehttp://HOSTNAME:8080/guacamole/ </Location> I
>>> already had this except for HOSTNAME I had "localhost", then it also
>>> shows proxying guacamole with websocket, and says it will reduce
>>> network latency. Well already it was fast enough to watch videos on
>>> a proxy connection, but why not, so I added:
>>> <Location/new-path/websocket-tunnel> Orderallow,deny
>>> Allowfromall
>>> ProxyPassws://localhost:8080/guacamole/websocket-tunnel
>>> ProxyPassReversews://localhost:8080/guacamole/websocket-tunnel
>>> </Location>
>>>
>>> Like this, if I go to the URL and login to a host, the IP the
>>> hosts sees is that of the web server and not the IP I am originating
>>> from.
>>> With respect authentication, if I wrap these proxy statements
>>> with access statements I get a 404 error with '/#/' as the URL
>>> If I remove the proxy statements and substitute some simple
>>> HTML it works as expected, prompts for login and password, and if
>>> correct displays the code.
>>>
>>> If I type the wrong username and password, it rejects the
>>> attempt.
>>>
>>> This was basically the auth code I was using:
>>>
>>> SetExternalAuthMethod pwauth pipe
>>> AddExternalAuth pwauth /usr/sbin/pwauth
>>> AuthType Basic
>>> AuthName "Authentication Required"
>>> AuthExternal pwauth
>>> Require valid-user
>>> AuthExternal authnz_external
>>> AuthBasicProvider external
>>>
>>> If I can get it to pass IP correctly then auth isn't required
>>> because fail2ban will pick up and ban offending IPs trying to
>>> brute-force passwords so right now that is my focus.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
> For additional commands, e-mail: user-help@guacamole.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: Passing IP of connecting client through Proxy
Posted by Michael Jumper <mj...@apache.org>.
The headers that you've been working with here will only affect whether
Tomcat and Guacamole see you as coming from your actual IP address
instead of the address of the proxy in front of Tomcat.
The destination remote desktop will always see the connecting client
address as that of the Guacamole server. If you wish to prevent brute
force auth attempts, the way to do that would be to configure fail2ban
on the *Guacamole* server such that repeated failing attempts to
authenticate with *Guacamole* will be blocked at the firewall level.
One of the primary benefits of deploying Guacamole in front of a set of
servers is to leverage Guacamole as a security layer in front of those
servers. I would not recommend instead relying on the destination
servers themselves to provide this. The authentication systems of those
servers should only come into play after Guacamole has established that
the user attempting to connect is authorized. Ideally, the destination
servers would be configured to accept connections only from the
Guacamole server.
- Mike
On 8/5/2023 7:00 PM, Robert Dinse wrote:
>
> I apologize, someone replied to this and I accidentally deleted
> your reply, but you asked what IP was tomcat logging, and if I'm looking
> in the right place, in catalina.out:
>
> catalina.out:[2023-08-04 17:35:02] [info] 17:35:02.572
> [http-nio-8080-exec-8] INFO o.a.g.event.EventLoggingListener - User
> "public" (authenticated by "default") successfully authenticated from
> [50.251.249.49, 127.0.0.1]
>
> In localhost_access_log.2023-08-04.txt.gz:
>
> localhost_access_log.2023-08-04.txt.
>
> These are both in /var/log/tomcat9.
>
> 50.251.249.49 is actually the IP address I am originating from
> but when I connect to a host, the host sees the connection coming from
> 204.122.16.20 which is that of the web server. I personally do not
> understand how it could possibly pass the originating IP address to the
> host it's connecting to since it is originating the connection from the
> web server.
>
> On 8/4/23 18:12, Robert Dinse wrote
>>
>>
>> I still haven't gotten Apache external authentication to work
>> properly. I did manage to get mod_authnz_external to peacefully
>> co-exist with mod_suphp, the secret was to compile mod_authnz_external
>> and dynamically load it rather than compiling it statically into
>> httpd, which would have been my preference. But, for some reason it
>> will work with a static web page or PHP application, but not a proxy,
>> but that's another issue.
>>
>> For now I am just trying to get the Apache to pass the IP of the
>> connecting customer through to Tomcat, have it pass it through to the
>> guacamole process so that when a user connects to a host, the host
>> sees the IP the user is originating from and not the IP of the web
>> server. I was referred to this webpage for instructions:
>>
>> https://guacamole.apache.org/doc/gug/reverse-proxy.html#setting-up-the-remote-ip-valve
>>
>> And so I've setup the <host> section in Tomcat9 as follows:
>>
>> The website shows to add this valve to the <host> section of the
>> server.xml file:
>>
>> <ValveclassName="org.apache.catalina.valves.RemoteIpValve"
>> internalProxies="127.0.0.1"
>> remoteIpHeader="x-forwarded-for"
>> remoteIpProxiesHeader="x-forwarded-by"
>> protocolHeader="x-forwarded-proto"/> Here is what the <host> section
>> of my servers.xml looks like: <Host name="localhost" appBase="webapps"
>> unpackWARs="true" autoDeploy="true"> <!-- SingleSignOn valve, share
>> authentication between web applications Documentation at:
>> /docs/config/valve.html --> <!-- <Valve
>> className="org.apache.catalina.authenticator.SingleSignOn" /> --> <!--
>> Access log processes all example. Documentation at:
>> /docs/config/valve.html Note: The pattern used is equivalent to using
>> pattern="common" --> <Valve
>> className="org.apache.catalina.valves.AccessLogValve" directory="
>> logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %u %t
>> "%r" %s %b" /> <Valve
>> className="org.apache.catalina.valves.RemoteIpValve"
>> internalProxies="127.0.0.1" remoteIpHeader="x-forwarded-for"
>> remoteIpProxiesHeader="x-forwarded-by"
>> protocolHeader="x-forwarded-proto" /> </Host> Note that guacamole is
>> the only application I have running under tomcat9. I have another Java
>> application running (yacy) but it is not containerized. Then it shows
>> for the Apache:
>> <Location/guacamole/> Orderallow,deny Allowfromall
>> ProxyPasshttp://HOSTNAME:8080/guacamole/flushpackets=on
>> ProxyPassReversehttp://HOSTNAME:8080/guacamole/ </Location> I already
>> had this except for HOSTNAME I had "localhost", then it also shows
>> proxying guacamole with websocket, and says it will reduce network
>> latency. Well already it was fast enough to watch videos on a proxy
>> connection, but why not, so I added:
>> <Location/new-path/websocket-tunnel> Orderallow,deny
>> Allowfromall
>> ProxyPassws://localhost:8080/guacamole/websocket-tunnel
>> ProxyPassReversews://localhost:8080/guacamole/websocket-tunnel
>> </Location>
>>
>> Like this, if I go to the URL and login to a host, the IP the hosts sees is that of the web server and not the IP I am originating from.
>> With respect authentication, if I wrap these proxy statements with access statements I get a 404 error with '/#/' as the URL
>> If I remove the proxy statements and substitute some simple HTML it works as expected, prompts for login and password, and if correct displays the code.
>>
>> If I type the wrong username and password, it rejects the attempt.
>>
>> This was basically the auth code I was using:
>>
>> SetExternalAuthMethod pwauth pipe
>> AddExternalAuth pwauth /usr/sbin/pwauth
>> AuthType Basic
>> AuthName "Authentication Required"
>> AuthExternal pwauth
>> Require valid-user
>> AuthExternal authnz_external
>> AuthBasicProvider external
>>
>> If I can get it to pass IP correctly then auth isn't required because fail2ban will pick up and ban offending IPs trying to brute-force passwords so right now that is my focus.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: Passing IP of connecting client through Proxy
Posted by Robert Dinse <na...@eskimo.com.INVALID>.
I apologize, someone replied to this and I accidentally deleted
your reply, but you asked what IP was tomcat logging, and if I'm looking
in the right place, in catalina.out:
catalina.out:[2023-08-04 17:35:02] [info] 17:35:02.572
[http-nio-8080-exec-8] INFO o.a.g.event.EventLoggingListener - User
"public" (authenticated by "default") successfully authenticated from
[50.251.249.49, 127.0.0.1]
In localhost_access_log.2023-08-04.txt.gz:
localhost_access_log.2023-08-04.txt.
These are both in /var/log/tomcat9.
50.251.249.49 is actually the IP address I am originating from
but when I connect to a host, the host sees the connection coming from
204.122.16.20 which is that of the web server. I personally do not
understand how it could possibly pass the originating IP address to the
host it's connecting to since it is originating the connection from the
web server.
On 8/4/23 18:12, Robert Dinse wrote
>
>
> I still haven't gotten Apache external authentication to work
> properly. I did manage to get mod_authnz_external to peacefully
> co-exist with mod_suphp, the secret was to compile mod_authnz_external
> and dynamically load it rather than compiling it statically into
> httpd, which would have been my preference. But, for some reason it
> will work with a static web page or PHP application, but not a proxy,
> but that's another issue.
>
> For now I am just trying to get the Apache to pass the IP of the
> connecting customer through to Tomcat, have it pass it through to the
> guacamole process so that when a user connects to a host, the host
> sees the IP the user is originating from and not the IP of the web
> server. I was referred to this webpage for instructions:
>
> https://guacamole.apache.org/doc/gug/reverse-proxy.html#setting-up-the-remote-ip-valve
>
> And so I've setup the <host> section in Tomcat9 as follows:
>
> The website shows to add this valve to the <host> section of the
> server.xml file:
>
> <ValveclassName="org.apache.catalina.valves.RemoteIpValve"
> internalProxies="127.0.0.1"
> remoteIpHeader="x-forwarded-for"
> remoteIpProxiesHeader="x-forwarded-by"
> protocolHeader="x-forwarded-proto"/> Here is what the <host> section
> of my servers.xml looks like: <Host name="localhost" appBase="webapps"
> unpackWARs="true" autoDeploy="true"> <!-- SingleSignOn valve, share
> authentication between web applications Documentation at:
> /docs/config/valve.html --> <!-- <Valve
> className="org.apache.catalina.authenticator.SingleSignOn" /> --> <!--
> Access log processes all example. Documentation at:
> /docs/config/valve.html Note: The pattern used is equivalent to using
> pattern="common" --> <Valve
> className="org.apache.catalina.valves.AccessLogValve" directory="
> logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %u %t
> "%r" %s %b" /> <Valve
> className="org.apache.catalina.valves.RemoteIpValve"
> internalProxies="127.0.0.1" remoteIpHeader="x-forwarded-for"
> remoteIpProxiesHeader="x-forwarded-by"
> protocolHeader="x-forwarded-proto" /> </Host> Note that guacamole is
> the only application I have running under tomcat9. I have another Java
> application running (yacy) but it is not containerized. Then it shows
> for the Apache:
> <Location/guacamole/> Orderallow,deny Allowfromall
> ProxyPasshttp://HOSTNAME:8080/guacamole/flushpackets=on
> ProxyPassReversehttp://HOSTNAME:8080/guacamole/ </Location> I already
> had this except for HOSTNAME I had "localhost", then it also shows
> proxying guacamole with websocket, and says it will reduce network
> latency. Well already it was fast enough to watch videos on a proxy
> connection, but why not, so I added:
> <Location/new-path/websocket-tunnel> Orderallow,deny
> Allowfromall
> ProxyPassws://localhost:8080/guacamole/websocket-tunnel
> ProxyPassReversews://localhost:8080/guacamole/websocket-tunnel
> </Location>
>
> Like this, if I go to the URL and login to a host, the IP the hosts sees is that of the web server and not the IP I am originating from.
> With respect authentication, if I wrap these proxy statements with access statements I get a 404 error with '/#/' as the URL
> If I remove the proxy statements and substitute some simple HTML it works as expected, prompts for login and password, and if correct displays the code.
>
> If I type the wrong username and password, it rejects the attempt.
>
> This was basically the auth code I was using:
>
> SetExternalAuthMethod pwauth pipe
> AddExternalAuth pwauth /usr/sbin/pwauth
> AuthType Basic
> AuthName "Authentication Required"
> AuthExternal pwauth
> Require valid-user
> AuthExternal authnz_external
> AuthBasicProvider external
>
> If I can get it to pass IP correctly then auth isn't required because fail2ban will pick up and ban offending IPs trying to brute-force passwords so right now that is my focus.
Re: Passing IP of connecting client through Proxy
Posted by Michael Jumper <mj...@apache.org>.
If you use a connection, what IP address does Guacamole record in the
history as being your source address?
- Mike
On 8/4/23 23:59, Robert Dinse wrote:
> nslookup localhost
> Server: 127.0.0.53
> Address: 127.0.0.53#53
>
> Non-authoritative answer:
> Name: localhost.eskimo.com
> Address: 127.0.0.1
>
> root@inuvik:~# grep localhost /etc/hosts
> 127.0.0.1 localhost localhost.localdomain loghost
>
> On 8/4/23 22:35, Michael Jumper wrote:
>> It's possible that "localhost" on your system maps to the IPv6 address
>> for localhost, so the source address of your proxy doesn't actually
>> match the value you specified for "internalProxies".
>>
>> - Mike
>>
>> On 8/4/2023 6:12 PM, Robert Dinse wrote:
>>>
>>> I still haven't gotten Apache external authentication to work
>>> properly. I did manage to get mod_authnz_external to peacefully
>>> co-exist with mod_suphp, the secret was to compile
>>> mod_authnz_external and dynamically load it rather than compiling it
>>> statically into httpd, which would have been my preference. But, for
>>> some reason it will work with a static web page or PHP application,
>>> but not a proxy, but that's another issue.
>>>
>>> For now I am just trying to get the Apache to pass the IP of
>>> the connecting customer through to Tomcat, have it pass it through to
>>> the guacamole process so that when a user connects to a host, the
>>> host sees the IP the user is originating from and not the IP of the
>>> web server. I was referred to this webpage for instructions:
>>>
>>> https://guacamole.apache.org/doc/gug/reverse-proxy.html#setting-up-the-remote-ip-valve
>>>
>>> And so I've setup the <host> section in Tomcat9 as follows:
>>>
>>> The website shows to add this valve to the <host> section of
>>> the server.xml file:
>>>
>>> <ValveclassName="org.apache.catalina.valves.RemoteIpValve"
>>> internalProxies="127.0.0.1"
>>> remoteIpHeader="x-forwarded-for"
>>> remoteIpProxiesHeader="x-forwarded-by"
>>> protocolHeader="x-forwarded-proto"/> Here is what the <host> section
>>> of my servers.xml looks like: <Host name="localhost"
>>> appBase="webapps" unpackWARs="true" autoDeploy="true"> <!--
>>> SingleSignOn valve, share authentication between web applications
>>> Documentation at: /docs/config/valve.html --> <!-- <Valve
>>> className="org.apache.catalina.authenticator.SingleSignOn" /> -->
>>> <!-- Access log processes all example. Documentation at:
>>> /docs/config/valve.html Note: The pattern used is equivalent to using
>>> pattern="common" --> <Valve
>>> className="org.apache.catalina.valves.AccessLogValve" directory="
>>> logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %u
>>> %t "%r" %s %b" /> <Valve
>>> className="org.apache.catalina.valves.RemoteIpValve"
>>> internalProxies="127.0.0.1" remoteIpHeader="x-forwarded-for"
>>> remoteIpProxiesHeader="x-forwarded-by"
>>> protocolHeader="x-forwarded-proto" /> </Host> Note that guacamole is
>>> the only application I have running under tomcat9. I have another
>>> Java application running (yacy) but it is not containerized. Then it
>>> shows for the Apache:
>>> <Location/guacamole/> Orderallow,deny Allowfromall
>>> ProxyPasshttp://HOSTNAME:8080/guacamole/flushpackets=on
>>> ProxyPassReversehttp://HOSTNAME:8080/guacamole/ </Location> I already
>>> had this except for HOSTNAME I had "localhost", then it also shows
>>> proxying guacamole with websocket, and says it will reduce network
>>> latency. Well already it was fast enough to watch videos on a proxy
>>> connection, but why not, so I added:
>>> <Location/new-path/websocket-tunnel> Orderallow,deny
>>> Allowfromall
>>> ProxyPassws://localhost:8080/guacamole/websocket-tunnel
>>> ProxyPassReversews://localhost:8080/guacamole/websocket-tunnel
>>> </Location>
>>>
>>> Like this, if I go to the URL and login to a host, the IP the
>>> hosts sees is that of the web server and not the IP I am originating
>>> from.
>>> With respect authentication, if I wrap these proxy statements
>>> with access statements I get a 404 error with '/#/' as the URL
>>> If I remove the proxy statements and substitute some simple
>>> HTML it works as expected, prompts for login and password, and if
>>> correct displays the code.
>>>
>>> If I type the wrong username and password, it rejects the attempt.
>>>
>>> This was basically the auth code I was using:
>>>
>>> SetExternalAuthMethod pwauth pipe
>>> AddExternalAuth pwauth /usr/sbin/pwauth
>>> AuthType Basic
>>> AuthName "Authentication Required"
>>> AuthExternal pwauth
>>> Require valid-user
>>> AuthExternal authnz_external
>>> AuthBasicProvider external
>>>
>>> If I can get it to pass IP correctly then auth isn't required
>>> because fail2ban will pick up and ban offending IPs trying to
>>> brute-force passwords so right now that is my focus.
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
>> For additional commands, e-mail: user-help@guacamole.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
> For additional commands, e-mail: user-help@guacamole.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: Passing IP of connecting client through Proxy
Posted by Robert Dinse <na...@eskimo.com.INVALID>.
nslookup localhost
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: localhost.eskimo.com
Address: 127.0.0.1
root@inuvik:~# grep localhost /etc/hosts
127.0.0.1 localhost localhost.localdomain loghost
On 8/4/23 22:35, Michael Jumper wrote:
> It's possible that "localhost" on your system maps to the IPv6 address
> for localhost, so the source address of your proxy doesn't actually
> match the value you specified for "internalProxies".
>
> - Mike
>
> On 8/4/2023 6:12 PM, Robert Dinse wrote:
>>
>> I still haven't gotten Apache external authentication to work
>> properly. I did manage to get mod_authnz_external to peacefully
>> co-exist with mod_suphp, the secret was to compile
>> mod_authnz_external and dynamically load it rather than compiling it
>> statically into httpd, which would have been my preference. But, for
>> some reason it will work with a static web page or PHP application,
>> but not a proxy, but that's another issue.
>>
>> For now I am just trying to get the Apache to pass the IP of
>> the connecting customer through to Tomcat, have it pass it through to
>> the guacamole process so that when a user connects to a host, the
>> host sees the IP the user is originating from and not the IP of the
>> web server. I was referred to this webpage for instructions:
>>
>> https://guacamole.apache.org/doc/gug/reverse-proxy.html#setting-up-the-remote-ip-valve
>>
>>
>> And so I've setup the <host> section in Tomcat9 as follows:
>>
>> The website shows to add this valve to the <host> section of
>> the server.xml file:
>>
>> <ValveclassName="org.apache.catalina.valves.RemoteIpValve"
>> internalProxies="127.0.0.1"
>> remoteIpHeader="x-forwarded-for"
>> remoteIpProxiesHeader="x-forwarded-by"
>> protocolHeader="x-forwarded-proto"/> Here is what the <host> section
>> of my servers.xml looks like: <Host name="localhost"
>> appBase="webapps" unpackWARs="true" autoDeploy="true"> <!--
>> SingleSignOn valve, share authentication between web applications
>> Documentation at: /docs/config/valve.html --> <!-- <Valve
>> className="org.apache.catalina.authenticator.SingleSignOn" /> -->
>> <!-- Access log processes all example. Documentation at:
>> /docs/config/valve.html Note: The pattern used is equivalent to using
>> pattern="common" --> <Valve
>> className="org.apache.catalina.valves.AccessLogValve" directory="
>> logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %u
>> %t "%r" %s %b" /> <Valve
>> className="org.apache.catalina.valves.RemoteIpValve"
>> internalProxies="127.0.0.1" remoteIpHeader="x-forwarded-for"
>> remoteIpProxiesHeader="x-forwarded-by"
>> protocolHeader="x-forwarded-proto" /> </Host> Note that guacamole is
>> the only application I have running under tomcat9. I have another
>> Java application running (yacy) but it is not containerized. Then it
>> shows for the Apache:
>> <Location/guacamole/> Orderallow,deny Allowfromall
>> ProxyPasshttp://HOSTNAME:8080/guacamole/flushpackets=on
>> ProxyPassReversehttp://HOSTNAME:8080/guacamole/ </Location> I already
>> had this except for HOSTNAME I had "localhost", then it also shows
>> proxying guacamole with websocket, and says it will reduce network
>> latency. Well already it was fast enough to watch videos on a proxy
>> connection, but why not, so I added:
>> <Location/new-path/websocket-tunnel> Orderallow,deny
>> Allowfromall
>> ProxyPassws://localhost:8080/guacamole/websocket-tunnel
>> ProxyPassReversews://localhost:8080/guacamole/websocket-tunnel
>> </Location>
>>
>> Like this, if I go to the URL and login to a host, the IP the
>> hosts sees is that of the web server and not the IP I am originating
>> from.
>> With respect authentication, if I wrap these proxy statements
>> with access statements I get a 404 error with '/#/' as the URL
>> If I remove the proxy statements and substitute some simple
>> HTML it works as expected, prompts for login and password, and if
>> correct displays the code.
>>
>> If I type the wrong username and password, it rejects the attempt.
>>
>> This was basically the auth code I was using:
>>
>> SetExternalAuthMethod pwauth pipe
>> AddExternalAuth pwauth /usr/sbin/pwauth
>> AuthType Basic
>> AuthName "Authentication Required"
>> AuthExternal pwauth
>> Require valid-user
>> AuthExternal authnz_external
>> AuthBasicProvider external
>>
>> If I can get it to pass IP correctly then auth isn't required
>> because fail2ban will pick up and ban offending IPs trying to
>> brute-force passwords so right now that is my focus.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
> For additional commands, e-mail: user-help@guacamole.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: Passing IP of connecting client through Proxy
Posted by Michael Jumper <mj...@apache.org>.
It's possible that "localhost" on your system maps to the IPv6 address
for localhost, so the source address of your proxy doesn't actually
match the value you specified for "internalProxies".
- Mike
On 8/4/2023 6:12 PM, Robert Dinse wrote:
>
> I still haven't gotten Apache external authentication to work
> properly. I did manage to get mod_authnz_external to peacefully
> co-exist with mod_suphp, the secret was to compile mod_authnz_external
> and dynamically load it rather than compiling it statically into httpd,
> which would have been my preference. But, for some reason it will work
> with a static web page or PHP application, but not a proxy, but that's
> another issue.
>
> For now I am just trying to get the Apache to pass the IP of the
> connecting customer through to Tomcat, have it pass it through to the
> guacamole process so that when a user connects to a host, the host sees
> the IP the user is originating from and not the IP of the web server. I
> was referred to this webpage for instructions:
>
> https://guacamole.apache.org/doc/gug/reverse-proxy.html#setting-up-the-remote-ip-valve
>
> And so I've setup the <host> section in Tomcat9 as follows:
>
> The website shows to add this valve to the <host> section of the
> server.xml file:
>
> <ValveclassName="org.apache.catalina.valves.RemoteIpValve"
> internalProxies="127.0.0.1"
> remoteIpHeader="x-forwarded-for"
> remoteIpProxiesHeader="x-forwarded-by"
> protocolHeader="x-forwarded-proto"/> Here is what the <host> section of
> my servers.xml looks like: <Host name="localhost" appBase="webapps"
> unpackWARs="true" autoDeploy="true"> <!-- SingleSignOn valve, share
> authentication between web applications Documentation at:
> /docs/config/valve.html --> <!-- <Valve
> className="org.apache.catalina.authenticator.SingleSignOn" /> --> <!--
> Access log processes all example. Documentation at:
> /docs/config/valve.html Note: The pattern used is equivalent to using
> pattern="common" --> <Valve
> className="org.apache.catalina.valves.AccessLogValve" directory=" logs"
> prefix="localhost_access_log" suffix=".txt" pattern="%h %l %u %t
> "%r" %s %b" /> <Valve
> className="org.apache.catalina.valves.RemoteIpValve"
> internalProxies="127.0.0.1" remoteIpHeader="x-forwarded-for"
> remoteIpProxiesHeader="x-forwarded-by"
> protocolHeader="x-forwarded-proto" /> </Host> Note that guacamole is the
> only application I have running under tomcat9. I have another Java
> application running (yacy) but it is not containerized. Then it shows
> for the Apache:
> <Location/guacamole/> Orderallow,deny Allowfromall
> ProxyPasshttp://HOSTNAME:8080/guacamole/flushpackets=on
> ProxyPassReversehttp://HOSTNAME:8080/guacamole/ </Location> I already
> had this except for HOSTNAME I had "localhost", then it also shows
> proxying guacamole with websocket, and says it will reduce network
> latency. Well already it was fast enough to watch videos on a proxy
> connection, but why not, so I added:
> <Location/new-path/websocket-tunnel> Orderallow,deny
> Allowfromall
> ProxyPassws://localhost:8080/guacamole/websocket-tunnel
> ProxyPassReversews://localhost:8080/guacamole/websocket-tunnel
> </Location>
>
> Like this, if I go to the URL and login to a host, the IP the hosts sees is that of the web server and not the IP I am originating from.
> With respect authentication, if I wrap these proxy statements with access statements I get a 404 error with '/#/' as the URL
> If I remove the proxy statements and substitute some simple HTML it works as expected, prompts for login and password, and if correct displays the code.
>
> If I type the wrong username and password, it rejects the attempt.
>
> This was basically the auth code I was using:
>
> SetExternalAuthMethod pwauth pipe
> AddExternalAuth pwauth /usr/sbin/pwauth
> AuthType Basic
> AuthName "Authentication Required"
> AuthExternal pwauth
> Require valid-user
> AuthExternal authnz_external
> AuthBasicProvider external
>
> If I can get it to pass IP correctly then auth isn't required because fail2ban will pick up and ban offending IPs trying to brute-force passwords so right now that is my focus.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Passing IP of connecting client through Proxy
Posted by Robert Dinse <na...@eskimo.com.INVALID>.
I still haven't gotten Apache external authentication to work
properly. I did manage to get mod_authnz_external to peacefully
co-exist with mod_suphp, the secret was to compile mod_authnz_external
and dynamically load it rather than compiling it statically into httpd,
which would have been my preference. But, for some reason it will work
with a static web page or PHP application, but not a proxy, but that's
another issue.
For now I am just trying to get the Apache to pass the IP of the
connecting customer through to Tomcat, have it pass it through to the
guacamole process so that when a user connects to a host, the host sees
the IP the user is originating from and not the IP of the web server. I
was referred to this webpage for instructions:
https://guacamole.apache.org/doc/gug/reverse-proxy.html#setting-up-the-remote-ip-valve
And so I've setup the <host> section in Tomcat9 as follows:
The website shows to add this valve to the <host> section of the
server.xml file:
<ValveclassName="org.apache.catalina.valves.RemoteIpValve"
internalProxies="127.0.0.1"
remoteIpHeader="x-forwarded-for"
remoteIpProxiesHeader="x-forwarded-by"
protocolHeader="x-forwarded-proto"/> Here is what the <host> section of
my servers.xml looks like: <Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true"> <!-- SingleSignOn valve, share
authentication between web applications Documentation at:
/docs/config/valve.html --> <!-- <Valve
className="org.apache.catalina.authenticator.SingleSignOn" /> --> <!--
Access log processes all example. Documentation at:
/docs/config/valve.html Note: The pattern used is equivalent to using
pattern="common" --> <Valve
className="org.apache.catalina.valves.AccessLogValve" directory=" logs"
prefix="localhost_access_log" suffix=".txt" pattern="%h %l %u %t
"%r" %s %b" /> <Valve
className="org.apache.catalina.valves.RemoteIpValve"
internalProxies="127.0.0.1" remoteIpHeader="x-forwarded-for"
remoteIpProxiesHeader="x-forwarded-by"
protocolHeader="x-forwarded-proto" /> </Host> Note that guacamole is the
only application I have running under tomcat9. I have another Java
application running (yacy) but it is not containerized. Then it shows
for the Apache:
<Location/guacamole/> Orderallow,deny Allowfromall
ProxyPasshttp://HOSTNAME:8080/guacamole/flushpackets=on
ProxyPassReversehttp://HOSTNAME:8080/guacamole/ </Location> I already
had this except for HOSTNAME I had "localhost", then it also shows
proxying guacamole with websocket, and says it will reduce network
latency. Well already it was fast enough to watch videos on a proxy
connection, but why not, so I added:
<Location/new-path/websocket-tunnel> Orderallow,deny
Allowfromall
ProxyPassws://localhost:8080/guacamole/websocket-tunnel
ProxyPassReversews://localhost:8080/guacamole/websocket-tunnel
</Location>
Like this, if I go to the URL and login to a host, the IP the hosts sees is that of the web server and not the IP I am originating from.
With respect authentication, if I wrap these proxy statements with access statements I get a 404 error with '/#/' as the URL
If I remove the proxy statements and substitute some simple HTML it works as expected, prompts for login and password, and if correct displays the code.
If I type the wrong username and password, it rejects the attempt.
This was basically the auth code I was using:
SetExternalAuthMethod pwauth pipe
AddExternalAuth pwauth /usr/sbin/pwauth
AuthType Basic
AuthName "Authentication Required"
AuthExternal pwauth
Require valid-user
AuthExternal authnz_external
AuthBasicProvider external
If I can get it to pass IP correctly then auth isn't required because fail2ban will pick up and ban offending IPs trying to brute-force passwords so right now that is my focus.
Re: Apache verses Guacamole
Posted by Nick Couchman <vn...@apache.org>.
Robert,
Sorry if you already answered this and I missed the answer, but did
you verify that you've configured the Remote IP Valve in Tomcat, as
documented in the Proxying chapter of the manual? This should give you
the correct iP in Guacamole:
https://guacamole.apache.org/doc/gug/reverse-proxy.html#setting-up-the-remote-ip-valve
-Nick
On Wed, Aug 2, 2023 at 4:32 AM Robert Dinse <na...@eskimo.com.invalid> wrote:
>
>
> I have considered LDAP, just the scope of converting so many
> machines is more than a little intimidating for one person. I do not
> have a staff, just me.
>
> I am trying to create one of two scenarios:
>
> 1) A customer using guacamole can login to it with the same
> credentials he uses for servers, e-mail, x2go, vnc, etc.
>
> 2) A customer logs in via apache and bypasses authentication at
> guacamole. In this case apache logs failures, and I realize tomcat can
> as well but I have a jail for apache and not for tomcat and I don't do
> well at creating regular expressions as interpreted by fail2ban which
> has a lot of it's own unique matching rules. I've done it successfully
> before but I'm getting old and would rather not go bald.
>
> 3) If neither of the above solutions can be made to work, then the
> customer goes straight into the host selection page but with the IP he
> is originating at, not the IP of the web server, so that failed logins
> are collected and repeat offending IPs blocked and really of the three
> this is the most convenient for the customer and the preferred one but
> since I don't know how to make tomcat pass through the originating IP
> it's problematic. If I could get this to work though it has some
> marketing advantage, as I could configure a virtual domain with a local
> non-routable IP address that the web server can talk to but that's it,
> and configure Ubuntu with a guest account (where nothing is saved after
> the session), the local address limiting the ability to get out on the
> net and use it for DOS attacks, etc. I think it would be a cool
> marketing ploy.
>
> On 8/2/23 01:08, Ivanmarcus wrote:
> > Thanks Robert, FWIW I was responding to your earlier post which said:
> >
> > "If I can figure out how to get tomcat to pass the IP to guacamole so
> > when someone logs into a server via guacamole it correctly logs the
> > originator IP and failed logins that will work also but I am utterly
> > unfamiliar with tomcat"
> >
> > Which I took to mean you wanted the connection data that's already
> > provided in the referenced log? You could of course run a fail2ban
> > recipe for Tomcat.
> >
> > So while I have probably got the wrong end of your meaning I do
> > understand that you're still trying to deal with the noauth issue ..
> > to that end I don't suppose you've thought about LDAP as a common
> > system across your various options? Guacamole has an option for that
> > (https://guacamole.apache.org/doc/gug/ldap-auth.html), and although
> > I've not had occasion to use it myself I understand various people are
> > doing so successfully.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
> > For additional commands, e-mail: user-help@guacamole.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
> For additional commands, e-mail: user-help@guacamole.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: Apache verses Guacamole
Posted by Robert Dinse <na...@eskimo.com.INVALID>.
I have considered LDAP, just the scope of converting so many
machines is more than a little intimidating for one person. I do not
have a staff, just me.
I am trying to create one of two scenarios:
1) A customer using guacamole can login to it with the same
credentials he uses for servers, e-mail, x2go, vnc, etc.
2) A customer logs in via apache and bypasses authentication at
guacamole. In this case apache logs failures, and I realize tomcat can
as well but I have a jail for apache and not for tomcat and I don't do
well at creating regular expressions as interpreted by fail2ban which
has a lot of it's own unique matching rules. I've done it successfully
before but I'm getting old and would rather not go bald.
3) If neither of the above solutions can be made to work, then the
customer goes straight into the host selection page but with the IP he
is originating at, not the IP of the web server, so that failed logins
are collected and repeat offending IPs blocked and really of the three
this is the most convenient for the customer and the preferred one but
since I don't know how to make tomcat pass through the originating IP
it's problematic. If I could get this to work though it has some
marketing advantage, as I could configure a virtual domain with a local
non-routable IP address that the web server can talk to but that's it,
and configure Ubuntu with a guest account (where nothing is saved after
the session), the local address limiting the ability to get out on the
net and use it for DOS attacks, etc. I think it would be a cool
marketing ploy.
On 8/2/23 01:08, Ivanmarcus wrote:
> Thanks Robert, FWIW I was responding to your earlier post which said:
>
> "If I can figure out how to get tomcat to pass the IP to guacamole so
> when someone logs into a server via guacamole it correctly logs the
> originator IP and failed logins that will work also but I am utterly
> unfamiliar with tomcat"
>
> Which I took to mean you wanted the connection data that's already
> provided in the referenced log? You could of course run a fail2ban
> recipe for Tomcat.
>
> So while I have probably got the wrong end of your meaning I do
> understand that you're still trying to deal with the noauth issue ..
> to that end I don't suppose you've thought about LDAP as a common
> system across your various options? Guacamole has an option for that
> (https://guacamole.apache.org/doc/gug/ldap-auth.html), and although
> I've not had occasion to use it myself I understand various people are
> doing so successfully.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
> For additional commands, e-mail: user-help@guacamole.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: Apache verses Guacamole
Posted by Ivanmarcus <iv...@yahoo.com.INVALID>.
Thanks Robert, FWIW I was responding to your earlier post which said:
"If I can figure out how to get tomcat to pass the IP to guacamole so
when someone logs into a server via guacamole it correctly logs the
originator IP and failed logins that will work also but I am utterly
unfamiliar with tomcat"
Which I took to mean you wanted the connection data that's already
provided in the referenced log? You could of course run a fail2ban
recipe for Tomcat.
So while I have probably got the wrong end of your meaning I do
understand that you're still trying to deal with the noauth issue .. to
that end I don't suppose you've thought about LDAP as a common system
across your various options? Guacamole has an option for that
(https://guacamole.apache.org/doc/gug/ldap-auth.html), and although I've
not had occasion to use it myself I understand various people are doing
so successfully.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: Apache verses Guacamole
Posted by Robert Dinse <na...@eskimo.com.INVALID>.
The site handles approximately half a million hits per day. I've
been offering Linux shell access since 1992, and prior to that SunOS and
SCO Xenix, so I'm familiar with the security issues. The servers are
all individually firewalled and fail2ban watches for password brute
force hacking. I'm trying to extend those protections through
guacamole, that's the current challenge. That's why I want to force a
login at the apache level, a failure of login at guacamole level is only
marginally helpful. I mean yes, one can stop people from hitting it,
but they can get to the servers via ssh, rdp, vnc, and x2go, so the
attack really needs to be stopped at the server level not at a gateway
because there are many paths of attack.
On 8/2/23 00:40, Ivanmarcus wrote:
> Robert,
>
> Just in case it helps; the connecting IP and login attempts are
> typically recorded in the Tomcat log. An example here is from a test
> Ubuntu 22.04 with Tomcat 9, the logfile is located at
> /var/log/tomcat9/catalina.out and you'll see I've tried twice, once
> with incorrect p/w, then the right one:
>
> [2023-08-02 07:27:20] [info] 07:27:20.815 [http-nio-8080-exec-7] WARN
> o.a.g.r.auth.AuthenticationService - Authentication attempt from
> 192.168.1.111 for user "admin" failed.
> [2023-08-02 07:28:09] [info] 07:28:09.889 [http-nio-8080-exec-9] INFO
> o.a.g.r.auth.AuthenticationService - User "admin" successfully
> authenticated from 192.168.1.111.
>
> Also, I'm not sure if the domain you mentioned is live but it might
> pay to obfuscate this on the mailing list. Amongst other things it'll
> end up in the archives and be there for all to see...
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
> For additional commands, e-mail: user-help@guacamole.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: Apache verses Guacamole
Posted by Ivanmarcus <iv...@yahoo.com.INVALID>.
Robert,
Just in case it helps; the connecting IP and login attempts are
typically recorded in the Tomcat log. An example here is from a test
Ubuntu 22.04 with Tomcat 9, the logfile is located at
/var/log/tomcat9/catalina.out and you'll see I've tried twice, once with
incorrect p/w, then the right one:
[2023-08-02 07:27:20] [info] 07:27:20.815 [http-nio-8080-exec-7] WARN
o.a.g.r.auth.AuthenticationService - Authentication attempt from
192.168.1.111 for user "admin" failed.
[2023-08-02 07:28:09] [info] 07:28:09.889 [http-nio-8080-exec-9] INFO
o.a.g.r.auth.AuthenticationService - User "admin" successfully
authenticated from 192.168.1.111.
Also, I'm not sure if the domain you mentioned is live but it might pay
to obfuscate this on the mailing list. Amongst other things it'll end up
in the archives and be there for all to see...
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Apache verses Guacamole
Posted by Robert Dinse <na...@eskimo.com.INVALID>.
I thought I was reasonably proficient with Apache web server but I
discovered it won't do what I want.
I solved the issue with mod_suphp verses mod_authnz_external. I
had compiled the entire server statically, I did this because I have a
machine with a large amount of RAM (256GB) so I prefer eating RAM to CPU
each time the program loads and links. And suphp is structured to only
be compiled statically, mod_authnz_external by contrast can be compiled
statically or dynamically. Any time I tried to compile it static,
mod_suphp would disappear, if I removed mod_authnz_external, then
mod_suphp would return. However, I found that if I compiled
mod_authnz_external dynamically and then loaded it when Apache started,
I could get the two to peacefully co-exist.
Now, I know apache access controls can be applied either to
directories or locations, and since the proxy for guacamole was already
inside a <location /> tag in the virtual domain, I figured it would be
easy to add access controls to this, turns out not.
I tested the access control by substituting a directory and for
directories they work fine. For some reason they do not work with
proxies. It fires off guacamole without requesting authentication then
when guacamole returns with a '/#/' URL, it immediately blows up and
gives me a 404 error.
Now with the header authentication module I can essentially bypass
authentication, and so what I was hoping to do is have apache
authenticate via external authentication and if successful launch
guacamole with a header that allows the user to connect, else reject and
log the failed attempt so that fail2ban can monitor the failures and
lock out offending IP's. That's my preferred method of handling this.
But it may not be a doable method, my main reason for wanting to wrap it
with apache authentication is that apache will log failed to auth temps
and I already have a fail2ban jail set up to watch for those. I have
it setup so that if they get five bad auths in a two day period they get
banned for two days, and if they keep doing this the recidive jail picks
up and blocks the IP for a year save for manual intervention.
If I can figure out how to get tomcat to pass the IP to guacamole
so when someone logs into a server via guacamole it correctly logs the
originator IP and failed logins that will work also but I am utterly
unfamiliar with tomcat.
What I have now in Apache is this:
# guacamole.eskimo.com
<Virtualhost 204.122.16.20:80>
ErrorLog /space/weblogs/guacamole.log
ServerName guacamole.eskimo.com
Redirect permanent / https://guacamole.eskimo.com/
</VirtualHost>
# guacamole.eskimo.com SSL
<VirtualHost 204.122.16.20:443>
ServerName guacamole.eskimo.com
SSLengine On
SSLCertificateFile "/misc/ssl/eskimo.com/certs/STAR_eskimo_com.crt"
SSLCertificateChainFile
"/misc/ssl/eskimo.com/certs/STAR_eskimo_com.ca-bundle"
SSLCertificateKeyFile "/misc/ssl/eskimo.com/key/eskimo.key"
RequestHeader set X-Remote-User "public"
SetExternalAuthMethod pwauth pipe
AddExternalAuth pwauth /usr/sbin/pwauth
<location /#/>
ProxyPass http://localhost:8080/guacamole/ flushpackets=on
ProxyPassReverse http://localhost:8080/guacamole/
AuthType Basic
AuthName "Authentication Required"
AuthExternal pwauth
Require valid-user
AuthExternal authnz_external
AuthBasicProvider external
</location>
</VirtualHost>
If anyone has any suggestions on how to beat this thing into
submission, I'd appreciate it.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: Guacamole Auth Header
Posted by "Molina de la Iglesia, Manuel" <ma...@veolia.com.INVALID>.
Hi,
I'm on the same situation with Palo Alto Global Protect Clientless VPN.
The problem is that works like a reverse proxy but the domain is always the
VPN firewall portal instead of the target web application
El mar, 1 ago 2023 21:48, <sh...@gmx.com> escribió:
> Hello,
>
> I'm using Guacamole v1.5.1 with LDAP/MySQL under RHEL 8.8 and NGINX. It
> works perfectly.
>
> Access to this Guacamole server is made after an MFA authentication
> (Fortigate Web SSL bookmark) and I would like to minimize as much as
> possible the number of times the user must enter his identifiers. It seems
> that the Auth-Header extension answers this need but I can't login without
> entering my password.
>
> Could you help me?
>
> Thanks
>
> Shaguu
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
> For additional commands, e-mail: user-help@guacamole.apache.org
>
>
Re: Guacamole Auth Header
Posted by Nick Couchman <vn...@apache.org>.
On Thu, Aug 3, 2023 at 2:30 AM Stephan <sh...@gmx.com> wrote:
>
>
> Thanks, that makes sense.
>
> Is there a solution that would allow me to use LDAP authentication via SSO?
> As a reminder, my users must already authenticate via MFA (Okta) on our SSL VPN web platform (Fortigate) before accessing the Guacamole web interface.
>
> I want to keep LDAP to use AD groups mapped to connections in Guacamole.
>
> Thanks for your help.
I don't know of a way to do this, no - I think your better path would
be to switch over to using the JDBC module to store the connections
and manage permissions, and then use header to pass through
authentication.
-Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: Guacamole Auth Header
Posted by Stephan <sh...@gmx.com>.
Thanks, that makes sense.
Is there a solution that would allow me to use LDAP authentication via SSO?
As a reminder, my users must already authenticate via MFA (Okta) on our SSL
VPN web platform (Fortigate) before accessing the Guacamole web interface.
I want to keep LDAP to use AD groups mapped to connections in Guacamole.
Thanks for your help.
Stephan
**Envoy e:** mercredi 2 aout 2023 a 22:55
**De:** "Nick Couchman" <vn...@apache.org>
**À :** user@guacamole.apache.org
**Objet:** Re: Guacamole Auth Header
On Wed, Aug 2, 2023 at 11:11 AM Stephan <sh...@gmx.com> wrote:
>
>
> I manually populated the $remote_user variable with an existing account in
> my LDAP, I can automatically connect to Guacamole but I can't find any
> connection already configured. If I try a classic LDAP connection, I see my
> connections.
> Isn't it possible to use Auth-Header and LDAP at the same time ?
No, it isn't - this is because the LDAP extension works in the following way:
* User gets Guacamole login page and enters credentials.
* If a Search DN/password has been configured, the extension connects
with the credentials to locate the user, then disconnects.
* If a Search DN/password has not been configured, the extension
computes the expected DN of the user.
* The DN - either searched for and found or computed - and password
entered by the user are used to establish a new LDAP connection.
* The connection with the user's credentials are then used to search
the LDAP tree to locate connections, connection groups, etc., which
are displayed for the user.
Since the Header auth module will have no knowledge of the user's
password, it isn't possible for it to connect to LDAP using the user's
credentials, so the LDAP module won't be used to retrieve connections.
This is an intentional design - it allows for access control to
Guacamole connections by leveraging the security already present in
LDAP.
-Nick
\---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
\--------------------------------------------------------------------- To
unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org For additional
commands, e-mail: user-help@guacamole.apache.org
Re: Guacamole Auth Header
Posted by Nick Couchman <vn...@apache.org>.
On Wed, Aug 2, 2023 at 11:11 AM Stephan <sh...@gmx.com> wrote:
>
>
> I manually populated the $remote_user variable with an existing account in my LDAP, I can automatically connect to Guacamole but I can't find any connection already configured. If I try a classic LDAP connection, I see my connections.
> Isn't it possible to use Auth-Header and LDAP at the same time ?
No, it isn't - this is because the LDAP extension works in the following way:
* User gets Guacamole login page and enters credentials.
* If a Search DN/password has been configured, the extension connects
with the credentials to locate the user, then disconnects.
* If a Search DN/password has not been configured, the extension
computes the expected DN of the user.
* The DN - either searched for and found or computed - and password
entered by the user are used to establish a new LDAP connection.
* The connection with the user's credentials are then used to search
the LDAP tree to locate connections, connection groups, etc., which
are displayed for the user.
Since the Header auth module will have no knowledge of the user's
password, it isn't possible for it to connect to LDAP using the user's
credentials, so the LDAP module won't be used to retrieve connections.
This is an intentional design - it allows for access control to
Guacamole connections by leveraging the security already present in
LDAP.
-Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: Guacamole Auth Header
Posted by Stephan <sh...@gmx.com>.
I manually populated the $remote_user variable with an existing account in my
LDAP, I can automatically connect to Guacamole but I can't find any connection
already configured. If I try a classic LDAP connection, I see my connections.
Isn't it possible to use Auth-Header and LDAP at the same time ?
Thanks
Stephan
**Envoy e:** mardi 1 aout 2023 a 23:52
**De:** "Stephan" <sh...@gmx.com>
**À :** user@guacamole.apache.org
**Objet:** Re: Guacamole Auth Header
Seems loaded properly :
23:49:54.356 [main] INFO o.a.g.extension.ExtensionModule - Multiple
extensions are installed and will be loaded in order of decreasing priority:
23:49:54.356 [main] INFO o.a.g.extension.ExtensionModule - \-
[tempnamespace] "Tempname" (/etc/guacamole/extensions/branding.jar)
23:49:54.356 [main] INFO o.a.g.extension.ExtensionModule - \- [header] "HTTP
Header Authentication Extension" (/etc/guacamole/extensions/guacamole-auth-
header-1.5.1.jar)
23:49:54.356 [main] INFO o.a.g.extension.ExtensionModule - \- [mysql] "MySQL
Authentication" (/etc/guacamole/extensions/guacamole-auth-jdbc-
mysql-1.5.1.jar)
23:49:54.356 [main] INFO o.a.g.extension.ExtensionModule - \- [ldap] "LDAP
Authentication" (/etc/guacamole/extensions/guacamole-auth-ldap-1.5.1.jar)
23:49:54.356 [main] INFO o.a.g.extension.ExtensionModule - To change this
order, set the "extension-priority" property or rename the extension files.
The default priority of extensions is dictated by the sort order of their
filenames.
23:49:54.390 [main] INFO o.a.g.extension.ExtensionModule - Extension
"Tempname" (tempnamespace) loaded.
23:49:54.490 [main] INFO o.a.g.extension.ExtensionModule - Extension "HTTP
Header Authentication Extension" (header) loaded.
23:49:54.501 [main] INFO o.a.g.a.mysql.conf.MySQLEnvironment - Installed JDBC
driver for MySQL/MariaDB detected as "MySQL Connector/J".
23:49:55.121 [main] INFO o.a.g.extension.ExtensionModule - Extension "MySQL
Authentication" (mysql) loaded.
23:49:55.240 [main] WARN o.a.g.e.LanguageResourceService - Overlay language
resource "de" does not exist.
23:49:55.242 [main] INFO o.a.g.extension.ExtensionModule - Extension "LDAP
Authentication" (ldap) loaded.
I'm not a Nginx expert, how can I verify that the $remote_user variable is
populated ?
Thanks
Stephan
**Envoy e:** mardi 1 aout 2023 a 23:35
**De:** "Nick Couchman" <vn...@apache.org>
**À :** user@guacamole.apache.org
**Objet:** Re: Guacamole Auth Header
On Tue, Aug 1, 2023 at 5:23 PM Stephan <sh...@gmx.com> wrote:
>
> Hi Nick,
>
> Many thanks for your help
>
> Here the interesting part from the Nginx configuration file :
>
> location /guacamole/ {
> proxy_pass <http://172.16.1.58:8080/guacamole/>;
> proxy_buffering off;
> proxy_http_version 1.1;
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> proxy_set_header Upgrade $http_upgrade;
> proxy_set_header Connection $http_connection;
> proxy_set_header Authorization "";
> proxy_set_header X-Guacamole-User $remote_user;
> proxy_cookie_path /guacamole/ "/guacamole/; HTTPOnly; Secure; SameSite";
> access_log /var/log/nginx/guac_access.log;
> error_log /var/log/nginx/guac_error.log;
> }
>
> From guacamole.properties files :
> http-auth-header: X-Guacamole-User
Looks pretty good, like it should be working. Can you verify in the
Tomcat logs that the Guacamole Header authentication extension is
being loaded correctly? And can you verify that the $remote_user
variable that you've specified in the Nginx configuration is actually
populated?
-Nick
\---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
\--------------------------------------------------------------------- To
unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org For additional
commands, e-mail: user-help@guacamole.apache.org
\--------------------------------------------------------------------- To
unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org For additional
commands, e-mail: user-help@guacamole.apache.org
Re: Guacamole Auth Header
Posted by Stephan <sh...@gmx.com>.
Seems loaded properly :
23:49:54.356 [main] INFO o.a.g.extension.ExtensionModule - Multiple
extensions are installed and will be loaded in order of decreasing priority:
23:49:54.356 [main] INFO o.a.g.extension.ExtensionModule - \-
[tempnamespace] "Tempname" (/etc/guacamole/extensions/branding.jar)
23:49:54.356 [main] INFO o.a.g.extension.ExtensionModule - \- [header] "HTTP
Header Authentication Extension" (/etc/guacamole/extensions/guacamole-auth-
header-1.5.1.jar)
23:49:54.356 [main] INFO o.a.g.extension.ExtensionModule - \- [mysql] "MySQL
Authentication" (/etc/guacamole/extensions/guacamole-auth-jdbc-
mysql-1.5.1.jar)
23:49:54.356 [main] INFO o.a.g.extension.ExtensionModule - \- [ldap] "LDAP
Authentication" (/etc/guacamole/extensions/guacamole-auth-ldap-1.5.1.jar)
23:49:54.356 [main] INFO o.a.g.extension.ExtensionModule - To change this
order, set the "extension-priority" property or rename the extension files.
The default priority of extensions is dictated by the sort order of their
filenames.
23:49:54.390 [main] INFO o.a.g.extension.ExtensionModule - Extension
"Tempname" (tempnamespace) loaded.
23:49:54.490 [main] INFO o.a.g.extension.ExtensionModule - Extension "HTTP
Header Authentication Extension" (header) loaded.
23:49:54.501 [main] INFO o.a.g.a.mysql.conf.MySQLEnvironment - Installed JDBC
driver for MySQL/MariaDB detected as "MySQL Connector/J".
23:49:55.121 [main] INFO o.a.g.extension.ExtensionModule - Extension "MySQL
Authentication" (mysql) loaded.
23:49:55.240 [main] WARN o.a.g.e.LanguageResourceService - Overlay language
resource "de" does not exist.
23:49:55.242 [main] INFO o.a.g.extension.ExtensionModule - Extension "LDAP
Authentication" (ldap) loaded.
I'm not a Nginx expert, how can I verify that the $remote_user variable is
populated ?
Thanks
Stephan
**Envoy e:** mardi 1 aout 2023 a 23:35
**De:** "Nick Couchman" <vn...@apache.org>
**À :** user@guacamole.apache.org
**Objet:** Re: Guacamole Auth Header
On Tue, Aug 1, 2023 at 5:23 PM Stephan <sh...@gmx.com> wrote:
>
> Hi Nick,
>
> Many thanks for your help
>
> Here the interesting part from the Nginx configuration file :
>
> location /guacamole/ {
> proxy_pass <http://172.16.1.58:8080/guacamole/>;
> proxy_buffering off;
> proxy_http_version 1.1;
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> proxy_set_header Upgrade $http_upgrade;
> proxy_set_header Connection $http_connection;
> proxy_set_header Authorization "";
> proxy_set_header X-Guacamole-User $remote_user;
> proxy_cookie_path /guacamole/ "/guacamole/; HTTPOnly; Secure; SameSite";
> access_log /var/log/nginx/guac_access.log;
> error_log /var/log/nginx/guac_error.log;
> }
>
> From guacamole.properties files :
> http-auth-header: X-Guacamole-User
Looks pretty good, like it should be working. Can you verify in the
Tomcat logs that the Guacamole Header authentication extension is
being loaded correctly? And can you verify that the $remote_user
variable that you've specified in the Nginx configuration is actually
populated?
-Nick
\---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
\--------------------------------------------------------------------- To
unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org For additional
commands, e-mail: user-help@guacamole.apache.org
Re: Guacamole Auth Header
Posted by Nick Couchman <vn...@apache.org>.
On Tue, Aug 1, 2023 at 5:23 PM Stephan <sh...@gmx.com> wrote:
>
> Hi Nick,
>
> Many thanks for your help
>
> Here the interesting part from the Nginx configuration file :
>
> location /guacamole/ {
> proxy_pass http://172.16.1.58:8080/guacamole/;
> proxy_buffering off;
> proxy_http_version 1.1;
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> proxy_set_header Upgrade $http_upgrade;
> proxy_set_header Connection $http_connection;
> proxy_set_header Authorization "";
> proxy_set_header X-Guacamole-User $remote_user;
> proxy_cookie_path /guacamole/ "/guacamole/; HTTPOnly; Secure; SameSite";
> access_log /var/log/nginx/guac_access.log;
> error_log /var/log/nginx/guac_error.log;
> }
>
> From guacamole.properties files :
> http-auth-header: X-Guacamole-User
Looks pretty good, like it should be working. Can you verify in the
Tomcat logs that the Guacamole Header authentication extension is
being loaded correctly? And can you verify that the $remote_user
variable that you've specified in the Nginx configuration is actually
populated?
-Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: Guacamole Auth Header
Posted by Stephan <sh...@gmx.com>.
Hi Nick,
Many thanks for your help
Here the interesting part from the Nginx configuration file :
location /guacamole/ {
proxy_pass http://172.16.1.58:8080/guacamole/;
proxy_buffering off;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_set_header Authorization "";
proxy_set_header X-Guacamole-User $remote_user;
proxy_cookie_path /guacamole/ "/guacamole/; HTTPOnly; Secure; SameSite";
access_log /var/log/nginx/guac_access.log;
error_log /var/log/nginx/guac_error.log;
}
From guacamole.properties files :
`http-auth-header: X-Guacamole-User`
Let me know if you need more information ?
Thanks
Shaguu
**Envoy e:** mardi 1 aout 2023 a 23:13
**De:** "Nick Couchman" <vn...@apache.org>
**À :** user@guacamole.apache.org
**Objet:** Re: Guacamole Auth Header
On Tue, Aug 1, 2023 at 3:48 PM <sh...@gmx.com> wrote:
>
> Hello,
>
> I'm using Guacamole v1.5.1 with LDAP/MySQL under RHEL 8.8 and NGINX. It
> works perfectly.
>
> Access to this Guacamole server is made after an MFA authentication
> (Fortigate Web SSL bookmark) and I would like to minimize as much as
> possible the number of times the user must enter his identifiers. It seems
> that the Auth-Header extension answers this need but I can't login without
> entering my password.
>
> Could you help me?
Sure, can you share details of your configuration - in particular, the
bits of the Nginx configuration file that you're using to pass the
authentication header through?
-Nick
\---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
\--------------------------------------------------------------------- To
unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org For additional
commands, e-mail: user-help@guacamole.apache.org
Re: Guacamole Auth Header
Posted by Nick Couchman <vn...@apache.org>.
On Tue, Aug 1, 2023 at 3:48 PM <sh...@gmx.com> wrote:
>
> Hello,
>
> I'm using Guacamole v1.5.1 with LDAP/MySQL under RHEL 8.8 and NGINX. It works perfectly.
>
> Access to this Guacamole server is made after an MFA authentication (Fortigate Web SSL bookmark) and I would like to minimize as much as possible the number of times the user must enter his identifiers. It seems that the Auth-Header extension answers this need but I can't login without entering my password.
>
> Could you help me?
Sure, can you share details of your configuration - in particular, the
bits of the Nginx configuration file that you're using to pass the
authentication header through?
-Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org