On 4/3/2020 11:12 AM, Nick Couchman wrote:
On Fri, Apr 3, 2020 at 10:40 AM Jason Keltz <[email protected]
<mailto:[email protected]>> wrote:
On 4/3/2020 10:03 AM, Nick Couchman wrote:
On Fri, Apr 3, 2020 at 9:44 AM Jason Keltz <[email protected]
<mailto:[email protected]>> wrote:
Hi.
I have a few questions I was hoping someone might be able to
help me with:
1) Although I have my Guacamole install retrieving users from
my Samba4
AD server, it does not retrieve the "Full Name" field. As a
result, on
the "Users" screen, the Full Name field is empty. Is this
the expected
behaviour? or can I somehow tell Guacamole to retrieve the
"displayName"
field from the LDAP?
At present I do not believe that the LDAP extension maps through
any of the LDAP fields into display fields in the UI. This is
probably worth considering a JIRA issue for as an improvement -
it should be relatively easy to do. Just not implemented today :-).
Thanks Nick. I agree it would be a useful feature in the future.
I just wanted to be sure that I didn't miss configuration.
At the same time,another related question... I know that until
you add an LDAP user, you don't see the users from the LDAP
directory. That just doesn't make sense to me. I've already
provided in guacamole.properties an ldap-search-bind-dn, and an
ldap-search-bind-password. Therefore, even as guacadmin, it should
be able to query the LDAP to get the list of users.
This is how we have designed the LDAP authentication extension to work
- the search bind user is not designed to be an administrative user
that gets to bypass LDAP security measures, it is a user account that
is *ONLY* for the purpose of looking up the account that is trying to
log in. After that account is successfully located, ALL of the
subsequent binds are done with the account that is logging in. So,
the flow looks like this:
- UserX goes to Guacamole Client and enters username UserX and his or
her password and clicks Login
- Guacamole binds using the ldap-search-bind-dn and
ldap-search-bind-password credentials, searches for the UserX account,
and returns the DN of UserX.
- Guacamole closes the original connection and then re-binds to the
LDAP server using the DN of UserX and the password entered by UserX.
- If the bind as UserX fails, the login fails. If the bind as UserX
succeeds, the login continues.
- Once the UserX bind is successful, Guacamole searches using the
UserX credentials to bind for any other users, groups, and/or
connections (as configured) in the LDAP tree.
The extension has been carefully designed to work this way, for the
following reasons:
- It allows the extension to leverage security built-in to the LDAP
tree without having to rewrite a bunch of security layers within the
module. Any/all permissions enforced by the LDAP tree apply to the
user (UserX in the above example), instead of the security that would
apply to the search account. As such, the search account should be an
account that basically can look within the LDAP tree for objects with
the attributes needed to identify users (CN, sAMAccountName, userId,
mail - whatever you choose as your username attribute), and the DN of
the user.
- The bind to check that the user can log correctly happens as a
normal bind and is not relying on trying to use the Search user to
compare a password entered to a password in LDAP, or hash to try to
compare passwords, etc. I haven't run across all that many pieces of
software that try comparing passwords to authenticate logins, but I
have run across a few, and it is awful.
So, the take-away is that the LDAP extension has been designed to work
with LDAP and its features and security, and not circumvent or work
against it.
Thanks for this. I understand now.
2) My Samba AD users are importing into Guacamole, but not
the Samba AD
groups. Can I add the groups as well?
Well, Guacamole doesn't really "import" anything from LDAP - it
will display the information from LDAP that the user who logs in
has access to, and you can relatively easily create users in JDBC
from users in LDAP provided you have admin access on the JDBC
side. However, it does "map" both users and groups between the
various authentication modules, so if you have a user in LDAP
named the same as a user in JDBC, you can assign permissions in
JDBC and those will apply to the LDAP login. The same is true of
groups - if you create a group in the JDBC module and assign it
permissions, a matching group in LDAP will get those
permissions. Hopefully this makes sense.
Sorry for using the wrong terminology. I didn't really mean
"import". That being said, I created a group in Samba AD called
"Users". I added a single user to that group. I logged into
Guacamole as admin, created a group with that name, and selected a
few connection that this group could access. I then logged out as
admin and in as the user and the user had no access to any
connections. Note that I didn't add the group to the user in
Guacamole. The assumption is that if the user exists in LDAP, and
the user is a member of a group in LDAP, then that information
will be read.
Depending on what version you're running there may be some slight
nuances in how this works. The groups were first introduced in 1.0.0
and there were some behaviors that were non-intuitive, so version
1.1.0 got some updates to how that works. We might need to dig into
that a bit more - I'll try to give it a try in my environment and make
sure it works, but one of the key things I would make sure is that
you've enabled group searching (by specifying the group search base in
guacamole.properties), as groups won't be looked up in LDAP by default.
I'm running 1.1.0. I did have to enable additional options in
guacamole.properties. I added:
ldap-group-base-dn: CN=Users,DC=ad,DC=eecs,DC=yorku,DC=ca
ldap-group-name-attribute: memberOf
Now, I see the groups listed in AD, though not just the names, but the
full names like this: CN=Users,CN=Builtin,DC=ad,DC=eecs,DC=yorku,DC=ca
I was able to edit the above group, and add a connection. I then
logged out and back in as the user who is in that group, but they didn't
get the resulting connection access. I may have something wrong in the
configuration.
3) Right now, I have the Guacamole front-end setup, and
working. Now,
I'm concerned about scaling. I have potentially 300
workstations I can
make available through Guacamole. One server can't handle
that load
(it's an 8 core VM with 16 GB and a 2Gb/s network link!).
It's not
really clear to me how much load each client imposes at a
max. I
can't seem to find any information on load balancing between
multiple
Guacamole servers? I wonder if I simply setup the hostname
to have
multiple IPs, each IP is a different guac server, and the DNS
round
robins them if that's enough? Or can multiple servers
connect to the
same MySQL DB.
This is a widely-asked question, with a complicated answer.
First, you should be able to put any/all of the components behind
a load balancer and, provided you have configured the load
balancer correctly (more on that in a minute), all of the
components should work fine behind a load balancer. So, you can
put the Guacamole Client (Tomcat) servers behind a web load
balancer and it can hand out connections to each of those, and
there is no functional issue, there. You can also put guacd
systems behind a load balancer and have it handle assignment of
the web connections to particular guacd instances, and that
should work okay. There are, however, a couple of caveats...
- When I say the load balancer needs to be configured correctly,
I mean that it should be persisting sessions in such a way that a
client (either Web Browsers -> Tomcat or Tomcat -> guacd) doesn't
get swapped around among various back-end components. If the
load balancer moves a client from one back-end component to
another, you'll see very odd problems and bad behavior. So,
you'll want persistent (maybe based on source IP + Port hashing
or something like that) that insures that clients get relatively
consistently connected to the same Tomcat instance, and that the
same Tomcat instance gets relatively consistently connected to
the same guacd instance.
- While all of the components will functionally work behind a
load balancer, there are a couple of things you'll miss or
notice, particularly with the web client. The biggest issue has
to do with active session tracking and the fact that, today,
there is no mechanism for synchronizing active sessions across
multiple web application server (Tomcat) instances. This may not
matter to you, but the one case where it can matter a lot is if
you're relying on the functionality within Guacamole Client to
limit the number of simultaneous (either per-user or total)
sessions connected to a particular connection. If you're
load-balancing across multiple Guacamole Client servers these
limits will, essentially, be meaningless - there is currently no
way for Guacamole Client to enforce these limits or reliably
compute the actual active number of sessions across multiple
instances. The other place where this might have an impact is if
you are using the Connection Sharing feature - when you go to
share a connection, there would be no way to insure that the user
who gets the connection sharing link gets connected to both a
Guacamole Client session and the subsequent guacd session where
the connection is actually running, so you'd more or less lose
that functionality.
Hopefully that helps and makes sense as to what is possible
today. There is a JIRA issue out there to improve HA/Load
Balancing support, it just hasn't had much attention:
https://issues.apache.org/jira/browse/GUACAMOLE-283
Thank you for this. It's very helpful. Given that many of the
components are new to me, can you please recommend a reasonable
open source software load balancer that would fit this bill? It
would be great if it's something you've seen used before, and you
know would work. or do I have to buy a hardware load balancing
device?
HAProxy is a pretty routine go-to for me - I'm doing some SMTP
load-balancing in my current Day Job with it, and I've also done a
decent amount of RDP and HTTP/S load balancing with it in past lives.
Takes some getting used to to configure it, but it's very robust, very
low-overhead, and very configurable. Active open source project with
a good community and ongoing development.
Beyond that, the network team at my Day Job uses NetScalers for load
balancing, and they seem to work reasonably well - I have no
complaints about them.
Excellent. Thanks so much for all of your help!
Jason.
