[ https://issues.apache.org/jira/browse/GUACAMOLE-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nick Couchman updated GUACAMOLE-300: ------------------------------------ Fix Version/s: 1.0.0 > Support posixGroup in LDAP Authentication and Group-based Session Admission > --------------------------------------------------------------------------- > > Key: GUACAMOLE-300 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-300 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-auth-ldap > Environment: Oracle Solaris 11.3.19.5.0, Apache Tomcat 8.5.9, > OpenLDAP 2.4.30, LDAP users are organized using the posixGroup scheme. > Reporter: Steffen Moser > Priority: Minor > Fix For: 1.0.0 > > Attachments: LDAP-posixGroup-support_SteffenMoser-20170514.patch > > > Recently, the auth-ldap module was extended by the ability to grant access to > remote terminal connections based on existing LDAP groups using the seeAlso > attribute in Guacamole's LDAP-based configuration settings. This is a great > feature if you've to manage a lot of users which are already organized in > LDAP groups. It works well as long as the groups are of the scheme > groupOfNames. As we have decided for posixGroup (due to other tools' > requirements), we currently cannot use the feature and still have to list all > users individually in the Guacamole remote service configuration. While this > could be scripted easily, it is still a work-around which makes the > administration work unnecessarily complex. > A better solution would be to support both schemes, posixGroup and > groupOfNames. > The attached patch will extend the user lookup code by the ability to search > not only through the groupOfNames but also through the posixGroup scheme. The > piece of code seems to work with both schemes in my tests successfully, I am > not sure if there are any pitfalls when just combining the possible results. > Maybe introducing a configuration flag to choose whether searching posixGroup > or groupOfNames would be a better approach. -- This message was sent by Atlassian JIRA (v7.6.3#76005)