On Fri, Dec 18, 2020 at 8:08 AM Olivier Chaudet < [email protected]> wrote:
> Hello, > > this is the user I've created and managed everything else with. It's my > account, in fact, and everything is checked in the "Permissions" area (and > "guacamole_connection_permission" countains the corresponding read, update, > delete and administer rows). A colleague with the same priviledges has the > same problems. > Those accounts authenticate through LDAP, their guacamole passwords beeing > dummies. > That said, we get the same result with the "guacadmin" SQL-only account. > I'll try to spend some time seeing if I can reproduce the behavior you're seeing. I can't say that I've noticed it in any of my experience, but it seems like there's a very specific set of circumstances that produces it, and I don't know that I've been down that path, yet. > By the way, I just noticed that this account can't see LDAP users until > they have an entry in the SQL db, which is weird but isn't a real problem > for us as long as we use LDAP accounts to administrate Guacamole. > > This is normal/intended behavior. The LDAP extension is designed to use the security of the user who is logging in via LDAP in order to query the LDAP. The search user that is configured in guacamole.properties only does the initial lookup for the user who is logging in, at which point LDAP re-binds with the user logging in and performs all other operations as that user. If the user logging in does not exist in LDAP, or fails to authenticate to LDAP, then communication with LDAP will stop and no further operations will be performed. Also, Guacamole does not synchronize user accounts between LDAP and database, and only creates them for you if you enable the auto-create parameter for the database extensions. > Thanks for making Guacamole! > > Thanks for using it and participating in the community. -Nick
