Re: ldap groups in 1.0.0 RC1
On Mon, Jan 14, 2019 at 12:37 PM Philip Herbert wrote: > > Hello, > > I have now created a testuser who is also member in one group. > > The user himself has a connection assigned, and one connection is assigned > to the TestGroup > > with the modification oft the function getGroupSearchFilter, > Authentication succeeds, but opening the connection assigned tot he group > fails (it is visible to the user) > (see attached log) > If the user is authenticated via LDAP and the group in question exists only in the database, you may be encountering: https://issues.apache.org/jira/browse/GUACAMOLE-696 - Mike
Re: ldap groups in 1.0.0 RC1
On Sun, Jan 13, 2019 at 16:48 Mike Jumper wrote: > On Sun, Jan 13, 2019 at 11:23 AM Nick Couchman wrote: > >> On Sun, Jan 13, 2019 at 7:43 AM Philip Herbert wrote: >> >>> as it seems impossible to change the structure of an ldap, because a >>> single application expects users and groups >>> >>> In different parts oft the ldap directory, I would like to try to find >>> out why this config is failing >>> >> >> We certainly do not try to design the LDAP authentication extension with >> the notion of having you reorganize your entire tree to suite the needs of >> Guacamole. The Guacamole extension does not expect users and groups to be >> in different parts of the tree - it simply gives you different options for >> searching for users, groups, and connections, and leaving them out allows >> you to disable items that you don't use. For example, I use Guacamole, >> with Active Directory, but don't care about having either LDAP groups or >> connections pulled in from AD - I'm only interested in authentication and >> users. Hopefully this helps explain why it is structured the way it is. >> >> > > It sounds like we should provide a group filter option like we already do > for users. > > - Mike > Sounds good to me. Should be a very easy change. -Nick >
Re: ldap groups in 1.0.0 RC1
On Sun, Jan 13, 2019 at 11:23 AM Nick Couchman wrote: > On Sun, Jan 13, 2019 at 7:43 AM Philip Herbert wrote: > >> as it seems impossible to change the structure of an ldap, because a >> single application expects users and groups >> >> In different parts oft the ldap directory, I would like to try to find >> out why this config is failing >> > > We certainly do not try to design the LDAP authentication extension with > the notion of having you reorganize your entire tree to suite the needs of > Guacamole. The Guacamole extension does not expect users and groups to be > in different parts of the tree - it simply gives you different options for > searching for users, groups, and connections, and leaving them out allows > you to disable items that you don't use. For example, I use Guacamole, > with Active Directory, but don't care about having either LDAP groups or > connections pulled in from AD - I'm only interested in authentication and > users. Hopefully this helps explain why it is structured the way it is. > > It sounds like we should provide a group filter option like we already do for users. - Mike
Re: ldap groups in 1.0.0 RC1
On Sun, Jan 13, 2019 at 12:29 PM Philip Herbert wrote: > for some reason I do not understand, I can not enable debug logging. > > I have added the logback.xml to /etc/gucamamole (where > guacamole.properties is located) > > > > startup in catalina.out show > > > > Loading logback configuration from > "/usr/share/tomcat7/.guacamole/logback.xml > > > > (this file i seither copied or contains the same information, however I > only get info level logging. > > > What am I doing wrong ? > > (see appended startup messages) > I would double-check that those files are indeed the same, or migrate entirely to just one of either "/usr/share/tomcat7/.guacamole/" or "/etc/guacamole/". Using two of the possible directories for GUACAMOLE_HOME will only cause confusion. If both exist, Guacamole will only read from one of those locations. In this case, the ".guacamole" one will take effect and "/etc/guacamole" will be ignored: http://guacamole.apache.org/doc/gug/configuring-guacamole.html#overriding-guacamole-home Once you've reduced things down to one GUACAMOLE_HOME and you're still not seeing what you expect with your logback.xml, post it here and we can look. It may just need fresh pair of eyes. > > Regarding https://issues.apache.org/jira/browse/GUACAMOLE-696 > > > > group based-dn is set tot he root oft the directory, I this is should > cause matching groups …? > > Yes, assuming your LDAP directory allows queries against the root. It's my understanding that some, like Active Directory, will not always allow this. Once you have debug-level logging successfully enabled, all LDAP queries will be logged, and it will be clearer what's happening. - Mike
Re: ldap groups in 1.0.0 RC1
On Sun, Jan 13, 2019 at 7:43 AM Philip Herbert wrote: > as it seems impossible to change the structure of an ldap, because a > single application expects users and groups > > In different parts oft the ldap directory, I would like to try to find out > why this config is failing > We certainly do not try to design the LDAP authentication extension with the notion of having you reorganize your entire tree to suite the needs of Guacamole. The Guacamole extension does not expect users and groups to be in different parts of the tree - it simply gives you different options for searching for users, groups, and connections, and leaving them out allows you to disable items that you don't use. For example, I use Guacamole, with Active Directory, but don't care about having either LDAP groups or connections pulled in from AD - I'm only interested in authentication and users. Hopefully this helps explain why it is structured the way it is. > > > If I set ldap-user-base-dn and ldap-group base-dn to he same value > (pointng to the root of the directory like: > > > > DC=DOMAIN,DC=DE > > > > then any attempt to login causes an error: > > > > 13:12:15.772 [http-bio-8080-exec-4] INFO > o.a.g.r.auth.AuthenticationService - User "philip" successfully > authenticated from [192.168.121.212, 0:0:0:0:0:0:0:1]. > > 13:12:16.745 [http-bio-8080-exec-4] WARN > o.a.g.e.AuthenticationProviderFacade - The "ldap" authentication provider > has encountered an internal error which will halt the authentication > process. If this is unexpected or you are the developer of this > authentication provider, you may wish to enable debug-level logging. If > this is expected and you wish to ignore such failures in the future, please > set "skip-if-unavailable: ldap" within your guacamole.properties. > > > > There is no additional output in catalina.out > > Might be worth putting logging into DEBUG mode and see if anything else is captured. Instructions for that is here: http://guacamole.apache.org/doc/gug/configuring-guacamole.html#webapp-logging This looks like it could be a bug, but hard to know for sure without some more detailed logging. > > > In my last post: > > dap-username-attribute:sAMAccountName > > was a copy/past error. The ‚l‘ before ldap is not missing … > > > > I have managed to get clean user / group lists by modifying > > > > The function getGroupSearchFilter in UserGroupService.jar to return only > objectClass=group > > > >//return "(objectClass=*)"; > > return "(objectClass=group)"; > > > > > > > > with the following properties: > > > > > > ldap-hostname: dc.domain.de > > ldap-port:3269 > > ldap-encryption-method:ssl > > ldap-search-bind-dn:cn=GuacamoleLDAP,cn=Users,dc=domain,dc=de > > ldap-search-bind-password: > > ldap-user-base-dn:dc=domain,dc=de > > ldap-group-base-dn:dc=domain,dc=de > > ldap-username-attribute:sAMAccountName > > ldap-max-search-results:4000 > > ldap-follow-referrals:true > > ldap-user-search-filter:(objectClass=user)(!(objectCategory=computer)) > > > > > > With this config and change, I get a clean lisst of (person)users in the > user tab and a clean list of groups in the group tab. > > When I assign a connection profile to a group, the connection is visible > to the users, but he can not connect, due to missing permissions. > > ‚You do not have permissions to access this connection‘ > > > Hmmm. I wonder if this is related to this issue: https://issues.apache.org/jira/browse/GUACAMOLE-696 ?? -Nick >
Re: ldap groups in 1.0.0 RC1
On Sun, Jan 13, 2019 at 7:43 AM Philip Herbert wrote: > as it seems impossible to change the structure of an ldap, because a > single application expects users and groups > > In different parts oft the ldap directory, I would like to try to find out > why this config is failing > > > > If I set ldap-user-base-dn and ldap-group base-dn to he same value > (pointng to the root of the directory like: > > > > DC=DOMAIN,DC=DE > > > > then any attempt to login causes an error: > > > > 13:12:15.772 [http-bio-8080-exec-4] INFO > o.a.g.r.auth.AuthenticationService - User "philip" successfully > authenticated from [192.168.121.212, 0:0:0:0:0:0:0:1]. > > 13:12:16.745 [http-bio-8080-exec-4] WARN > o.a.g.e.AuthenticationProviderFacade - The "ldap" authentication provider > has encountered an internal error which will halt the authentication > process. If this is unexpected or you are the developer of this > authentication provider, you may wish to enable debug-level logging. If > this is expected and you wish to ignore such failures in the future, please > set "skip-if-unavailable: ldap" within your guacamole.properties. > > > > There is no additional output in catalina.out > > > > > > In my last post: > > dap-username-attribute:sAMAccountName > > was a copy/past error. The ‚l‘ before ldap is not missing … > > > > I have managed to get clean user / group lists by modifying > > > > The function getGroupSearchFilter in UserGroupService.jar to return only > objectClass=group > > > >//return "(objectClass=*)"; > > return "(objectClass=group)"; > > > > > > > > with the following properties: > > > > > > ldap-hostname: dc.domain.de > > ldap-port:3269 > > ldap-encryption-method:ssl > > ldap-search-bind-dn:cn=GuacamoleLDAP,cn=Users,dc=domain,dc=de > > ldap-search-bind-password: > > ldap-user-base-dn:dc=domain,dc=de > > ldap-group-base-dn:dc=domain,dc=de > > ldap-username-attribute:sAMAccountName > > ldap-max-search-results:4000 > > ldap-follow-referrals:true > > ldap-user-search-filter:(objectClass=user)(!(objectCategory=computer)) > > > > > > With this config and change, I get a clean lisst of (person)users in the > user tab and a clean list of groups in the group tab. > > When I assign a connection profile to a group, the connection is visible > to the users, but he can not connect, due to missing permissions. > > ‚You do not have permissions to access this connection‘ > > > > > > INFO: Server startup in 3508 ms > > 13:38:18.787 [http-bio-8080-exec-7] INFO > o.a.g.r.auth.AuthenticationService - User "philip" successfully > authenticated from [192.168.121.212, 127.0.0.1]. > > 13:38:20.167 [http-bio-8080-exec-9] INFO > o.a.g.r.auth.AuthenticationService - User "philip" successfully > authenticated from [192.168.121.212, 0:0:0:0:0:0:0:1]. > > 13:38:52.504 [http-bio-8080-exec-8] INFO > o.a.g.r.auth.AuthenticationService - User "testdv" successfully > authenticated from [192.168.121.212, 127.0.0.1]. > > 13:38:55.784 [http-bio-8080-exec-2] ERROR > o.a.g.w.GuacamoleWebSocketTunnelEndpoint - Creation of WebSocket tunnel to > guacd failed: Permission denied. > > 13:38:55.846 [http-bio-8080-exec-7] WARN > o.a.g.s.GuacamoleHTTPTunnelServlet - HTTP tunnel request rejected: > Permission denied. > > 13:39:12.699 [http-bio-8080-exec-5] ERROR > o.a.g.w.GuacamoleWebSocketTunnelEndpoint - Creation of WebSocket tunnel to > guacd failed: Permission denied. > > 13:39:12.754 [http-bio-8080-exec-3] WARN > o.a.g.s.GuacamoleHTTPTunnelServlet - HTTP tunnel request rejected: > Permission denied. > > > > > > Connections assigned to the user (not the group) are still working fine, > as the did in previous versions. > > > > Thanks, Philip > > > > > > > > *Von:* Mike Jumper > *Gesendet:* Sonntag, 6. Januar 2019 08:47 > *An:* user@guacamole.apache.org > *Betreff:* Re: ldap groups in 1.0.0 RC1 > > > > On Sat, Jan 5, 2019, 16:49 Philip Herbert > ... > > Because of global catalogue port(3269), all users in the entire directory > are returned and shown in Users, independant from the ou. > > > > Are you saying your LDAP server ignores the base DN for queries? > > > > > > ... > > dap-username-attribute:sAMAccountName > > > > Is this a correct copy of your guacamole.properties? The "ldap" in this > property name is missing the "l". > > > > ldap-user-search-filter:(objectClass=
Re: ldap groups in 1.0.0 RC1
On Sat, Jan 5, 2019, 16:49 Philip Herbert ... > > Because of global catalogue port(3269), all users in the entire directory > are returned and shown in Users, independant from the ou. > Are you saying your LDAP server ignores the base DN for queries? > ... > > dap-username-attribute:sAMAccountName > Is this a correct copy of your guacamole.properties? The "ldap" in this property name is missing the "l". ldap-user-search-filter:(objectClass=user)(!(objectCategory=computer)) > Is "user" a valid objectClass? simply adding: > > ldap-user-base-dn:dc=mydomain,dc=de > > > > causes a failure: > > > > 01:32:21.232 [http-bio-8080-exec-9] WARN > o.a.g.r.auth.AuthenticationService - Authentication attempt from > [192.168.121.212, 127.0.0.1] for user "service" failed. > > 01:32:25.523 [http-bio-8080-exec-1] INFO > o.a.g.r.auth.AuthenticationService - User "philip" successfully > authenticated from [192.168.121.212, 0:0:0:0:0:0:0:1]. > > 01:32:26.498 [http-bio-8080-exec-1] WARN > o.a.g.e.AuthenticationProviderFacade - The "ldap" authentication provider > has encountered an internal error which will halt the authentication > process. If this is unexpected or you are the developer of this > authentication provider, you may wish to enable debug-level logging. If > this is expected and you wish to ignore such failures in the future, please > set "skip-if-unavailable: ldap" within your guacamole.properties. > There should be an earlier, more specific error. Anything else in your logs? > > When I set: > > ldap-user-base-dn:cn=Users,dc=mydomain,dc=de > > > > I can log in, but in the Administration Groups Tab > > I see all Users and Groups in the Users Container oft the Directory and > not only groups. > You will also need to set the "ldap-group-base-dn" property. As long as your users and groups are beneath separate, distinct base DNs (there are no users beneath the group DN and no groups beneath the user DN), they will be properly distinguished from each other. If you keep your groups in the same part of your LDAP directory as your users, Guacamole will not be able to differentiate an LDAP group from an LDAP user when attempting to list either within the admin interface. - Mike
