> 1. Why isn't the bind user used for all the polling when the > administration/administrator for guacamole can be done with another database > (postgresql) and rights management (in guacamole itself)?
This was a very intentional design, because it allows the LDAP extension to leverage security built-in to LDAP - LDAP access controls - to make sure that the information that is being pulled from LDAP is only accessible to the user who is actually logging in, and not to the initial bind user that has been used to locate the user. While this is certainly applicable and relevant to looking for groups, it is actually more important when one stores Guacamole connections in LDAP, because the extension relies on the LDAP ACLs to limit what connections the user can see and access. > 2. I'm not good with java programming and tried to dig into the source code > already. Is it easily possible to change the behavior of the extension from > user polling to bind polling? It is possible, and it shouldn't be too difficult, but also not a matter of just tweaking one or two lines of code. The portion of the code that deals specifically with searching for groups would have to be tweaked to pull in and use the bind dn and password rather than the current user credentials, so there could be a handful of changes required to make it happen. That said, I'm not 100% sure that making this change would automatically allow all users and groups to show up in the Guacamole admin interface, when logging in with a database-only user (guacadmin, for example). The other aspect of this is that the authentication extensions are evaluated in order (alphabetical, by default), and so if you log in as a user through the database module, and that login succeeds, then the authentication within the LDAP module will never be tried or evaluated, and the groups will not be enumerated. I believe this is more likely the core issue for you and not which user account is used to search the LDAP tree for groups? The best way to resolve this issue is to administer Guacamole with a LDAP account that has also been granted admin access within the JDBC module, which can be accomplished by using the guacadmin user to create a new account with the same username as the LDAP user, and grant that user account admin privileges (make sure not to specify a password so that Guacamole generates a random one that is different from the LDAP module). This should allow you to log in with the LDAP user, which will evaluate the LDAP groups (and connections, if you're using those), but also have admin access to the database and be able to assign LDAP users and groups permissions within the database. The alternative, which is the path you started down would be to 1) modify the LDAP extension to use the bind DN, 2) modify the LDAP extension to search for groups even when a user is not successfully authenticated, and 3) re-order extension processing within your Guacamole install to evaluate LDAP before JDBC. This could be quite a process - while modifying the extension to use the bind DN shouldn't be too difficult, modifying it to continue group search even when authentication fails would probably take some work. > PS: is this the right place to ask these questions? : ) Yep, this is the place! -Nick --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
