On Thu, May 14, 2020 at 8:28 AM Sven Specker <[email protected]> wrote:
> 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. > > You are certainly entitled to your opinion. My opinion comes from the fact that pretty much every single LDAP directory out there (at least modern ones) contain the ability to be extended, and relatively easily at that. This indicates to me that the designers of both the LDAP standard and the directory servers themselves intended to make it so that the directories are adaptable to your particular needs and requirements as an organization. The Guacamole project has chosen to build upon those capabilities, for a variety of reasons. > > > >> 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. > > That's your decision. I am simply giving you the options you have based upon how the Guacamole software functions. Depending on what software you are using you might be able to generate a "fake group" that contains all authenticated users dynamically. I'm reasonably certain that some of the OpenLDAP overlays will allow you to do this. You don't have to, I'm just suggesting it as a possible alternative to creating a specific global group with all members. > 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. > > My personal opinion is that I would rather create a large group with many members where new accounts are placed by default and use that, rather than creating a connection to which I grant access to any "authenticated user." The former is preferable to me from a security perspective than the later, but that's just my opinion. > 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. > > I would imagine it's possible, and you are certainly welcome to submit a JIRA enhancement for it and a pull request. -Nick
