[ 
https://issues.apache.org/jira/browse/GUACAMOLE-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16821425#comment-16821425
 ] 

Nick Couchman commented on GUACAMOLE-715:
-----------------------------------------

[~dchuha]: Thanks for confirming.  Unfortunately I'm still unable to reproduce 
this issue, at least with a native install.  I'll continue to try out a few 
things to see what happens.  It is odd that you're able to see the connections 
within the web interface, but you get the error when trying to establish the 
tunnel - I'm not really sure what to make of that.  I'll continue poking at it 
to try to find what fails.  Can you post your full catalina.out file somewhere 
- attach here, or pastebin.com, something like that?  If you need to redact 
stuff, please do that, but it'd be good to see the full set of messages (in 
debug mode).

> Permission management based on LDAP groups not working as documented
> --------------------------------------------------------------------
>
>                 Key: GUACAMOLE-715
>                 URL: https://issues.apache.org/jira/browse/GUACAMOLE-715
>             Project: Guacamole
>          Issue Type: Bug
>          Components: guacamole-auth-jdbc-mysql, guacamole-auth-ldap
>    Affects Versions: 1.0.0
>         Environment: I'm running guacamole in a docker environment using the 
> official base images and a MySQL database. Users are authenticated against an 
> Active Directory server in combination with the MySQL database.
>            Reporter: Micha Kohl
>            Assignee: Nick Couchman
>            Priority: Major
>             Fix For: 1.1.0
>
>
> From the documentation on user groups in 1.0.0 I expected to be able to 
> manage user permissions via LDAP groups like this (using LDAP for 
> authentication and MySQL for configuration management as documented 
> [here|https://guacamole.apache.org/doc/gug/ldap-auth.html#ldap-and-database]):
>  # Create user group in MySQL with the name of a corresponding user group in 
> the LDAP directory 
>  # Create connection in MySQL 
>  # Grant connection permission to the user group created in 1.
>  # LDAP users that are part of the LDAP group (in the directory) are able to 
> log in with their LDAP credentials and access that connection
> This does not work at all (the user does not even see the connection). In my 
> attempt to narrow down the problem and ensure that I'm not just doing it 
> wrong, I tested the following scenarios:
>  # _Having just the LDAP group be mirrored in MySQL by creating an_ 
> _identically named one there_
>  -> Login succeeds, but no associated connections are shown.
>  # _Having both the LDAP group and the user be mirrored in MySQL by creating_ 
> _identically named entities there without manually linking the two (MySQL 
> user is not part of MySQL user group)_
>  -> Login succeeds and guacamole tries to auto-connect to the only available 
> connection/shows all available connections and fails when trying to connect 
> with a permission error.
>  # _Having both the LDAP group and the user be mirrored in MySQL by creating_ 
> _identically named entities there and manually adding the MySQL user to the_ 
> _MySQL group_ _(MySQL user is part of MySQL user group)_
>  -> Connections are established successfully.
> Either there seems to be a big misunderstanding regarding the way the new 
> group system is supposed to work with LDAP, or there's something going wrong 
>  here. It goes without saying that scenario 3 completely eliminates the 
> purpose of relying on existing LDAP groups. Scenario 1 is the configuration I 
> outlined above that would allow managing connections based on LDAP groups 
> without having to create any MySQL users whatsoever. Scenario 2 in 
> combination with similar reports on the mailing list led me to believe that 
> this is either based on a common misconception or there's a bug.
> Side-Note: While it has been suggested that this is already covered by 
> GUACAMOLE-696, I think this could only be said if this turns out to be 
> expected but poorly documented behavior. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to