On Fri, Apr 3, 2020 at 10:40 AM Jason Keltz <j...@eecs.yorku.ca> wrote:
> > On 4/3/2020 10:03 AM, Nick Couchman wrote: > > On Fri, Apr 3, 2020 at 9:44 AM Jason Keltz <j...@eecs.yorku.ca> 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. > > >> 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. > > >> 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. -Nick
