答复: guacamole behind haproxy

[zhangbin]

Here's my ajax request method:

 

 

var gua;

 

function getGuacamole(){

var ajaxURL = "http://10.128.0.211:8080/apis/api/tokens;;

 var userparams = {

   "username":"guacadmin",

   "password":"guacadmin"

 };

 

$.ajax({

type:"POST",

url:ajaxURL,

headers:{

"Access-Control-Allow-Headers":"X-Requested-With",

"Access-Control-Allow-Methods":"GET,POST,OPTIONS",

"Access-Control-Allow-Origin":"*",

"ACCEPT":"application/json, text/plain, */*",

   "Content-Type":"application/x-www-form-urlencoded"

},

data:JSON.stringify(userparams),

dataType:"JSON",

success: function(data){

//console.log(data);

   

},

error: function(data){



}

})

 

}

 

发件人: Nick Couchman [mailto:vn...@apache.org] 
发送时间: 当前系统时间为：2018年2月3日 12:14
收件人: user@guacamole.apache.org
主题: Re: guacamole behind haproxy

 

On Fri, Feb 2, 2018 at 3:42 AM, StephenDart  > wrote:

Will post the config when i am back home, but actually there is only one
backend so sticky sessions arent a problem, there is only one possible in
the config to go to.
Any traffic for /guacamole will go to a single server.

I think there must be something regarding how haproxy maybe waits for a
session to complete, I had hoped that the http-server-close may have helped
but it doesnt appear to.

 

This really shouldn't impact the API at all - at least, you shouldn't see any 
404 errors or anything like that.  I'm not sure about the actual connection 
stream, though.

 

Two things come to mind:

- Some sort of incompatibility in how HAProxy handles WebSocket traffic, 
particularly if it is trying to establish it and then dropping it.  I'm not 
sure off the top of my head if HAProxy supports, doesn't support, or is 
ignorant of the use of WebSocket.

- A parameter is being dropped from one of the API or tunnel calls, like the 
token, somewhere along the way - perhaps in HAProxy somewhere.

 

-Nick

答复: Login to guacamole using the web api

[zhangbin]

I tried the way you said, but I'm not sure if there is a bug in my json format 
for submitting data, or anything else,I get an error XMLHttpRequest can not 
load http://10.128.0.211:8080/guacamole/api/tokens. No 
'Access-Control-Allow-Origin' header is present on the requested resource. 
Origin 'null' is therefore not allowed.

 

发件人: Nick Couchman [mailto:vn...@apache.org] 
发送时间: 当前系统时间为：2018年2月3日 12:09
收件人: user@guacamole.apache.org
主题: Re: Login to guacamole using the web api

 

On Fri, Feb 2, 2018 at 10:55 PM, zhangbin  > wrote:

Hello, 

how do I use guacamole/api/tokens and login remotely to guacamole web api by 
submitting username, password json format data to get the authentication code...

 

The easiest way to figure out what you need is to use something like Chrome 
Developer Tools, the Network tab, specifically, and watch the login process.  
Basically it looks sometihng like this:

- You load the page, which posts to the tokens endpoint on the API and receives 
a 403 INSUFFICIENT CREDENTIALS error.

- The AngularJS web application interprets this and presents the 
username/password dialog

- You type your username and password, and submit

- This POSTs a application/x-www-form-urlencoded back to the token endpoint, 
with the username and password as form parameters.

- In response, assuming successful authentication, you receive the authToken 
back in the response, which you can then use as the token parameter in 
subsequent API calls.

 

so that direct calls to the remote desktop window can be made. 

 

 

What kind of "direct calls" are you talking about, here?  Logging into the API 
like this allows you to interact with the API using the token, but I'm not sure 
about making direct calls to a remote desktop window.  You can certainly use 
this method to establish a tunnel to a given connection, but if you're thinking 
you can authenticate to the API and then somehow send and receive data from a 
remote desktop session, this is not how it works - at least, not quite that 
easily.

 

-Nick

Re: guacamole behind haproxy

[Nick Couchman]

On Fri, Feb 2, 2018 at 3:42 AM, StephenDart  wrote:

> Will post the config when i am back home, but actually there is only one
> backend so sticky sessions arent a problem, there is only one possible in
> the config to go to.
> Any traffic for /guacamole will go to a single server.
>
> I think there must be something regarding how haproxy maybe waits for a
> session to complete, I had hoped that the http-server-close may have helped
> but it doesnt appear to.
>

This really shouldn't impact the API at all - at least, you shouldn't see
any 404 errors or anything like that.  I'm not sure about the actual
connection stream, though.

Two things come to mind:
- Some sort of incompatibility in how HAProxy handles WebSocket traffic,
particularly if it is trying to establish it and then dropping it.  I'm not
sure off the top of my head if HAProxy supports, doesn't support, or is
ignorant of the use of WebSocket.
- A parameter is being dropped from one of the API or tunnel calls, like
the token, somewhere along the way - perhaps in HAProxy somewhere.

-Nick

Re: Login to guacamole using the web api

[Nick Couchman]

On Fri, Feb 2, 2018 at 10:55 PM, zhangbin  wrote:

> Hello,
>
> how do I use guacamole/api/tokens and login remotely to guacamole web api
> by submitting username, password json format data to get the authentication
> code...
>

The easiest way to figure out what you need is to use something like Chrome
Developer Tools, the Network tab, specifically, and watch the login
process.  Basically it looks sometihng like this:
- You load the page, which posts to the tokens endpoint on the API and
receives a 403 INSUFFICIENT CREDENTIALS error.
- The AngularJS web application interprets this and presents the
username/password dialog
- You type your username and password, and submit
- This POSTs a application/x-www-form-urlencoded back to the token
endpoint, with the username and password as form parameters.
- In response, assuming successful authentication, you receive the
authToken back in the response, which you can then use as the token
parameter in subsequent API calls.


> so that direct calls to the remote desktop window can be made.
>
>
>

What kind of "direct calls" are you talking about, here?  Logging into the
API like this allows you to interact with the API using the token, but I'm
not sure about making direct calls to a remote desktop window.  You can
certainly use this method to establish a tunnel to a given connection, but
if you're thinking you can authenticate to the API and then somehow send
and receive data from a remote desktop session, this is not how it works -
at least, not quite that easily.

-Nick

Login to guacamole using the web api

[zhangbin]

Hello, 

how do I use guacamole/api/tokens and login remotely to guacamole web api by
submitting username, password json format data to get the authentication
code so that direct calls to the remote desktop window can be made. 

 

Thanks for the help.

 

Re: LDAP Guacamole 9.14

[Nick Couchman]

>
> I also noticed that your running LDAP on port 3268. That's not the port
> that LDAP usually runs on, did you double check that your LDAP server is
> really running on port 3268?
>
>
Port 3268 is standard when running Active Directory - it is the global
catalog port.  There was a referral bug in the LDAP authentication
extension for a while that required you to point at this port to avoid
hitting a LDAP referral - that bug has since been resolved and it is safe
to point at the standard LDAP port.

-Nick

Re: LDAP Guacamole 9.14

[Aaron Newsome]

Hello Ferron. I've got 0.9.14 running with LDAP authentication. I've
actually used an identical config since 0.9.12 without any problems. Here's
the LDAP section of my guacamole.properties file:

ldap-hostname: ads-001.swiftlab.local

ldap-port: 389

ldap-max-search-results: 3000

ldap-search-bind-dn: CN=administrator,CN=Users,dc=swiftlab,dc=local

ldap-search-bind-password: password

ldap-username-attribute: sAMAccountName

ldap-user-base-dn: CN=Users,DC=swiftlab,DC=local

ldap-group-base-dn: CN=Users,DC=swiftlab,DC=local

I also noticed that your running LDAP on port 3268. That's not the port
that LDAP usually runs on, did you double check that your LDAP server is
really running on port 3268?

--Aaron


On Fri, Feb 2, 2018 at 5:25 AM, Ferron Nijland - Switch IT Solutions <
f.nijl...@switch.nl> wrote:

> Hello Everyone,
>
>
>
> I’ve installed a new installation of Guacamole 9.14.
>
> I can access the GUI and login with sql authentication.
>
> Now I’ve added LDAP authentication, but it doesn’t seem to work.
>
> The guacd service starts without problems, so I’ve no idea where to look.
>
>
>
> My guacamole.properties in /etc/guacamole contains is like:
>
>
>
> # Hostname and port of guacamole proxy
>
> guacd-hostname: localhost
>
> guacd-port: 4822
>
>
>
> # Location to read extra .jar's from
>
> lib-directory:  /etc/guacamole/lib
>
>
>
> # Authentication provider class
>
> #auth-provider: net.sourceforge.guacamole.net.basic.
> BasicFileAuthenticationProvider
>
>
>
> auth-provider: net.sourceforge.guacamole.net.auth.ldap.
> LDAPAuthenticationProvider
>
>
>
> #LDAP Properties
>
> ldap-hostname: 10.75.10.12
>
> ldap-port: 3268
>
> ldap-user-base-dn: DC=domain,DC=local
>
> ldap-search-bind-dn: CN=sa_ ldap_guac,OU=Service
> Accounts,DC=domain,DC=local
>
> ldap-search-bind-password: password
>
> ldap-username-attribute: sAMAccountName
>
>
>
> # Properties used by BasicFileAuthenticationProvider
>
> basic-user-mapping: /etc/guacamole/user-mapping.xml
>
>
>
> # MySQL properties
>
> mysql-hostname: localhost
>
> mysql-port: 3306
>
> mysql-database: guacamole_db
>
> mysql-username: guacamole_user
>
> mysql-password: mypassword
>
>
>
> Met vriendelijke groet,
>
>
>
> *Ferron Nijland *
>
>
>

Re: LDAP Guacamole 9.14

[Jerry]

For what it's worth, using ldap-username-attribute sAMAccountname never
worked for me on 0.9.13-incubating (though it seemed to work for other
people based on my googling), but CN worked fine.



--
Sent from: 
http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/

Re: LDAP Guacamole 9.14

[Mike Jumper]

On Fri, Feb 2, 2018 at 5:25 AM, Ferron Nijland - Switch IT Solutions <
f.nijl...@switch.nl> wrote:

> Hello Everyone,
>
>
>

Hello Ferron,

I’ve installed a new installation of Guacamole 9.14.
>
> I can access the GUI and login with sql authentication.
>
> Now I’ve added LDAP authentication, but it doesn’t seem to work.
>
> The guacd service starts without problems, so I’ve no idea where to look.
>
>
>

guacd actually has nothing to do with the authentication mechanism in use;
it handles only the low-level remote desktop connection. If the LDAP
authentication isn't working for you, the first thing to check would be the
logs from the web application. Assuming you are using Tomcat, these will be
logged to Tomcat's logs, most likely "catalina.out".

My guacamole.properties in /etc/guacamole contains is like:
>
>
>
> # Hostname and port of guacamole proxy
>
> guacd-hostname: localhost
>
> guacd-port: 4822
>
>
Beware that these property values are actually the defaults. Having them
will not hurt anything, but Guacamole will assume these values if these
properties are omitted.


>
> # Location to read extra .jar's from
>
> lib-directory:  /etc/guacamole/lib
>
>
The "lib-directory" property has actually been deprecated since 0.9.7, and
as of 0.9.10-incubating no longer has any effect:

http://guacamole.apache.org/releases/0.9.10-incubating/#removal-of-deprecated-lib-directory-and-auth-provider-properties

The lib directory used by Guacamole is now always GUACAMOLE_HOME/lib/,
which matches the value you are trying to use here.


>
> # Authentication provider class
>
> #auth-provider: net.sourceforge.guacamole.net.basic.
> BasicFileAuthenticationProvider
>
>
>
> auth-provider: net.sourceforge.guacamole.net.auth.ldap.
> LDAPAuthenticationProvider
>
>
>

Like the "lib-directory" property, the "auth-provider" property has been
deprecated since 0.9.7 and as of 0.9.10-incubating no longer has any effect:

The "lib-directory" property has actually been deprecated since 0.9.7, and
as of 0.9.10-incubating no longer has any effect:

http://guacamole.apache.org/releases/0.9.10-incubating/#removal-of-deprecated-lib-directory-and-auth-provider-properties

In prior releases which followed 0.9.7, attempting to use this property
would have resulted in a warning in the logs. With the property having now
been fully removed, it is simply silently ignored. The authentication
mechanism in use is dictated purely by the extensions installed within
GUACAMOLE_HOME/extensions/.


> #LDAP Properties
>
> ldap-hostname: 10.75.10.12
>
> ldap-port: 3268
>
> ldap-user-base-dn: DC=domain,DC=local
>
> ldap-search-bind-dn: CN=sa_ ldap_guac,OU=Service
> Accounts,DC=domain,DC=local
>
> ldap-search-bind-password: password
>
> ldap-username-attribute: sAMAccountName
>
>
>
Depending on what you see in the Tomcat logs from Guacamole, I suggest
trying a few searches against your LDAP directory, binding to the LDAP
directory using the search DN and password you've specified here, making
sure you can execute queries against the "DC=domain,DC=local" tree. If you
cannot execute such searches, that is probably why things are failing, and
there should be corresponding errors in the logs.

# Properties used by BasicFileAuthenticationProvider
>
> basic-user-mapping: /etc/guacamole/user-mapping.xml
>
>
The "basic-user-mapping" property has been deprecated since
0.9.10-incubating:

http://guacamole.apache.org/releases/0.9.10-incubating/#deprecation-of-the-basic-user-mapping-property

Its use would have resulted in a warning regarding its deprecation in the
logs. Though still supported in 0.9.14, support for this property has
recently been removed entirely. It will no longer be supported in future
releases:

https://issues.apache.org/jira/browse/GUACAMOLE-494

- Mike

Re: New user, Debian HowTo, some suggestions

[Fabián Rodríguez]

Hi,


On 01/02/18 04:24 PM, Nick Couchman wrote:
> [..] Yeah, but if you have requests for improvements, they should go
> into JIRA.

OK, will do next time - thanks for clarifying.

>  
>
>   * In Settings > Users > $USER > Permissions, I'd like to be able
> to set two extra permissions:
>   o access sessions History tab
>   o access Active Sessions tab
>
> Can you explain why you think it is useful to have these as separate
> permissions?  I guess I can see this for auditing, perhaps, if you
> want users that have the ability to only audit connections and
> connection history, but I'm curious what your use-case is.

It's sometime required to provide a manager access to history and active
sessions without giving them full admin rights (change/add
users/connections).


>   * When using the filter to find connections, I'd like to see
> which Group they belong to (if any). Sometimes I have
> connections with the same name in different groups, the
> current filtering results don't show group membership
>
>
> That's because the idea of "groups" is not implemented at all in
> Guacamole right now.  There is a current JIRA issue, already, for
> adding groups to Guacamole.  See:
>
> https://issues.apache.org/jira/browse/GUACAMOLE-220

I think I wasn't specific enough. I am referring to connection groups,
not user groups. I may have used the wrong term (folders?), sorry.

>  
>
>   * Timezone for each user should be the same as the server's by
> default (or have an option to use the same as the server's)
>   * When clicking on a group checkbox, the selection should also
> include all members of the group, either checking or
> unchecking all boxes. I have some large groups (40+
> connections) and it would be faster to be able to
> include/exclude all connections in any given group.
>
> This also already has a JIRA issue - I'm not sure that I agree that
> checking a top-level box should result in all children being checked -
> there are situations where you want to, for example, assign
> permissions to a user to access a connection group (load-balanced,
> maybe) but not give them any access to the underlying connections.  I
> do agree that there needs to be a way to select all children more
> easily than you can right now.  See:
>
> https://issues.apache.org/jira/browse/GUACAMOLE-181
>
>   * Selecting a connection in a group is not enough to give
> access, the group also needs to be checked which is not
> obvious (perhaps it should be automatic)
>
> This depends on what you're trying to do, but see the point above. 
> This behavior is intentional.

I am not sure how to indicate this otherwise, but it's not intuitive. I
tested this with 2 sysadmins and they both highlighted this - it's not a
huge issue after our initial setup is done, for sure.  The issue seems
to reflect what can be improved. Is there a mechanism in the project to
make a donation or fund this development otherwise?

> My recent setup of Guacamole on a Debian server wasn't easy as the
> packages are outdated and some manual configuration was required.
>
> I've shared my notes for Debian server installation here if anyone
> is interested:
>
> https://wiki.debian.org/Guacamole 
>
>
> Cool :-).
>
> -Nick

Thanks again to everyone involved in this, I hope to be able to
contribute back as time/knowledge permits.

- F.

-- 
Fabián Rodríguez
http://fsf.magicfab.ca/

LDAP Guacamole 9.14

[Ferron Nijland - Switch IT Solutions]

Hello Everyone,

I've installed a new installation of Guacamole 9.14.
I can access the GUI and login with sql authentication.
Now I've added LDAP authentication, but it doesn't seem to work.
The guacd service starts without problems, so I've no idea where to look.

My guacamole.properties in /etc/guacamole contains is like:

# Hostname and port of guacamole proxy
guacd-hostname: localhost
guacd-port: 4822

# Location to read extra .jar's from
lib-directory:  /etc/guacamole/lib

# Authentication provider class
#auth-provider: 
net.sourceforge.guacamole.net.basic.BasicFileAuthenticationProvider

auth-provider: 
net.sourceforge.guacamole.net.auth.ldap.LDAPAuthenticationProvider

#LDAP Properties
ldap-hostname: 10.75.10.12
ldap-port: 3268
ldap-user-base-dn: DC=domain,DC=local
ldap-search-bind-dn: CN=sa_ ldap_guac,OU=Service Accounts,DC=domain,DC=local
ldap-search-bind-password: password
ldap-username-attribute: sAMAccountName

# Properties used by BasicFileAuthenticationProvider
basic-user-mapping: /etc/guacamole/user-mapping.xml

# MySQL properties
mysql-hostname: localhost
mysql-port: 3306
mysql-database: guacamole_db
mysql-username: guacamole_user
mysql-password: mypassword

Met vriendelijke groet,

Ferron Nijland

Re: guacamole behind haproxy

[StephenDart]

Will post the config when i am back home, but actually there is only one
backend so sticky sessions arent a problem, there is only one possible in
the config to go to.
Any traffic for /guacamole will go to a single server. 

I think there must be something regarding how haproxy maybe waits for a
session to complete, I had hoped that the http-server-close may have helped
but it doesnt appear to.

If anyone has any other ideas let me know. 



--
Sent from: 
http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/