On Mon, May 6, 2019 at 20:51 drhy <[email protected]> wrote: > Definitely only a wish to add to the list.
This should probably go into our JIRA instance as an improvement or feature request. > > It would reduce admin for those of us who use Radius for authentication > against a Directory (in our case Microsoft Active Directory) with a > database > provider that will be using Groups to mange connections, if Groups could be > used somehow. > > One possibility... > Radius Servers could be configured to return a Group name that matches a > Group in the database, by using the RADIUS Vendor-Specific attribute, set > to > the desired Group name for that Server authentication rule. > In this wishful scenario the Radius provider would treat the Group name in > the same way the LDAP provider now appears to be doing with the resolution > of issue 715. > Yeah, this should be doable. I actually started to look into it at one point but got side-tracked by other issues and the day job. I would like to see it implementEd both for RADIUS and for CAS - the CAS SSO module also allows for passing through arbitrary data from whatever back-end is doing authentication, and it seems like group membership should be pretty easy to implement in both those modules. > (In our case, we need to use Radius instead of LDAP because of the > requirement to use MFA.) > https://tools.ietf.org/html/rfc2865#page-47 > Implies addition of guacamole.properties entries for the vendor-id and > type. > > It's worth mentioning that MFA need not require RADIUS for authentication - Guacamole has support for 2FA built-nick with the TOTP module, and CAS also allows for MFA configuration. However, of your organization is already using RADIUS for other stuff like VPN and SSO (like mine is), then I totally understand wanting to integrate with that rather than completely reinventing the authentication wheel. -Nick
