You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@guacamole.apache.org by "Duarte, Alexander A" <al...@udel.edu> on 2018/08/01 13:29:19 UTC

RE: Uniquemember default instead of Member default 389-DS

Nick,

Looks like according to Jira you finished the work on this and it will be implemented in V1.0.1, is there any way to implement the changes on 0.9.14? If not I will just wait but I figured it was worth asking !

Thanks!

Regards,

Alex Duarte

From: Nick Couchman <vn...@apache.org>
Sent: Thursday, July 26, 2018 6:31 AM
To: user@guacamole.apache.org
Subject: Re: Uniquemember default instead of Member default 389-DS

On Wed, Jul 25, 2018 at 6:00 PM Duarte, Alexander A <al...@udel.edu>> wrote:
Hello Everyone,

I have guacamole running just fine on Fedora 29 with the LDAP extension working well. My only issue is that we use 389-DS for LDAP not OpenLDAP. It seems that by default Guacamole is looking for the Member attribute within any group that is part of the guacconfiggroup. By default 389-DS creates a MemberOf attribute (via plugin) which just has a user’s username, and a uniquemember field which seems that this is the equivalent of the Member field for OpenLDAP. Would there be any way to have guac look for the uniquemember field instead of the Member field? The value for the attribute is the same starting with uid=. Right now I have to add users as members of this group and then open the advanced tab and copy and paste the UID to a Member attribute that I have to create for each group. I would like to make it where simply adding someone to the group gives them access to the connection.

Thanks a million for any feedback you can provide!


Currently you would have to modify both the Guacamole schema that is applied to the LDAP tree and the source code of the LDAP module in order to make this happen.  You're welcome to open a feature request in JIRA to add support for making this configurable:

https://issues.apache.org/jira/projects/GUACAMOLE

-Nick

RE: Uniquemember default instead of Member default 389-DS

Posted by "Duarte, Alexander A" <al...@udel.edu>.
Sounds good Nick!

Thank you for all of your work I do greatly appreciate it!

Regards,

Alex Duarte
From: Nick Couchman <vn...@apache.org>
Sent: Wednesday, August 1, 2018 12:33 PM
To: user@guacamole.apache.org
Subject: Re: Uniquemember default instead of Member default 389-DS

On Wed, Aug 1, 2018 at 9:29 AM Duarte, Alexander A <al...@udel.edu>> wrote:
Nick,

Looks like according to Jira you finished the work on this and it will be implemented in V1.0.1, is there any way to implement the changes on 0.9.14? If not I will just wait but I figured it was worth asking !


We will not release the changes for 0.9.14.  If you're feeling adventurous you could trying grabbing the commits from github and applying them to the 0.9.14 build tree, and rebuilding everything, but, at that point you might as well just build from github master and upgrade everything.

Sorry, I know it's frustrating to have to wait for something that's already actually fixed in code to be released, but we're working toward a 1.0.0 release, and I expect that this one will out pretty quickly after that - we're working quite a few issues that could be considered for a pretty quick turn-around on another release (1.0.1, actually may end up being 2.0.0, we'll see...).  I can't promise anything, and that's just my opinion :-).

-Nick

Re: Uniquemember default instead of Member default 389-DS

Posted by Nick Couchman <vn...@apache.org>.
On Wed, Aug 1, 2018 at 9:29 AM Duarte, Alexander A <al...@udel.edu> wrote:

> Nick,
>
>
>
> Looks like according to Jira you finished the work on this and it will be
> implemented in V1.0.1, is there any way to implement the changes on 0.9.14?
> If not I will just wait but I figured it was worth asking !
>
>
>

We will not release the changes for 0.9.14.  If you're feeling adventurous
you could trying grabbing the commits from github and applying them to the
0.9.14 build tree, and rebuilding everything, but, at that point you might
as well just build from github master and upgrade everything.

Sorry, I know it's frustrating to have to wait for something that's already
actually fixed in code to be released, but we're working toward a 1.0.0
release, and I expect that this one will out pretty quickly after that -
we're working quite a few issues that could be considered for a pretty
quick turn-around on another release (1.0.1, actually may end up being
2.0.0, we'll see...).  I can't promise anything, and that's just my opinion
:-).

-Nick