On 2020-05-14 13:18, Nick Couchman wrote:
Authenticating with LDAP does not require any changes to your LDAP directory. Storing the connections themselves within LDAP does require schema extensions to your directory. This is fairly normal - if you want to store something other than the default LDAP attributes in LDAP, you have to extend the schema. The Guacamole schema extensions are minimally invasive.
Actually, it is a misuse of directories and one that crept into many a project :) But as an old-school directory admin, I am maybe rather strict when it comes to extensions, especially if it is config data that has no use but for one special service and as such no business to be in a general authentication directory.
I could of course build a server that contains those. But then again, I have two different places to manage guacamole at and that is always bad medicine.
That is beside the point though and more of a policy and directory management matter on my side. :)
Two questions regarding that: - Maybe I missed it, but can I auto-add users from LDAP to the DB?No; however, you also do not necessarily need to add all of the users to the database. You could, instead, add a group to the database that matches a group in LDAP, and assign the permissions to the group. Users who match that group from any other modules, including LDAP, should get access to the connections.
Since ALL users in my directory are allowed to connect and a classic LDAP Server has no concept of a built-in global group, I would have to create a group in my LDAP that includes all user objects in my IDM. That is something I will avoid at all costs.
Basically, "all-in" groups are always an odd thing and I oppose them, since they should not exist. If anyone is allowed, the directory has no need to store that fact.
Maybe I will write an enhancement request for attribute-based grouping. Currently, the database only knows groups that need to map to a group of the same name in the directory. It might be a good idea to do attribute->group mapping/connection mapping.
So I could choose attribute:objectClass/value:posixAccount and map this pair to "group 1". In my case, this would allow all users to access group 1, since all non-special users have that objectclass.
For systems supporting "memberof" like AD or OpenLDAP, you could basically skip the group part altogether by mapping the DN of a group in the AD/LDAP to a connection group/connection in guacamole.
Have not had a peek at the guacamole codebase yet, so if that's possible or not...no idea.
- Is it possible to make connections in a defined connection group accessible by "successfully authenticated" users?Not exactly as stated, but if you're using AD you could use "Domain Users" or something like that with the point above and that should cover pretty much everyone.
Yep, AD provides those, but that is more a feature of the domain part, less of the LDS/LDAP part. Anyway, I am not accessing an AD so that method is out.
Of course, I can write a little program that syncs all of my roughly 60k accounts in the guacamole database and then set the connection permissions....but for some reason, I consider that a bit of a overkill, even though the program would be trivial.Should not be necessary.
Well, it seems it will be. Not the end of the world, I just wanted to make sure to not implement a useless thing. Need to write a cli management tool for guacamole anyway, so I guess it is one module more.
Thanks for the help anyway! Best regards, Sven Specker -- __________________________________________________________________ *** Sven Specker -- University of Frankfurt Computing Center *** *********** UNIX System Administration (Auth/IDM) **************** ***** [email protected] [Phone (+49)-69-798-15188] ***** ****************************************************************** __________________________________________________________________ Johann Wolfgang Goethe Universitaet - Hochschulrechenzentrum - Theodor W. Adorno-Platz 1 (PA-1P16) D-60323 Frankfurt/Main __________________________________________________________________ ______________ TeX-users do it in {groups}________________________
smime.p7s
Description: S/MIME Cryptographic Signature
