[jira] [Commented] (GUACAMOLE-137) Feature Request - Quick Connect
[ https://issues.apache.org/jira/browse/GUACAMOLE-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15791638#comment-15791638 ] Nick Couchman commented on GUACAMOLE-137: - I agree this would be really nice. I actually started working on an implementation of this. Given the nature of needing to define the connection both on the back-end (Java Servlet) and the front-end (AngularJS application), I was wondering if the best way to handle this within Guacamole is to actually use an extension similar to the JDBC ones, but instead of a persistent on-disk database, create an in-memory database with the connections. A "Quick-Connect" area could be created on the home screen, and when the connection information is entered the connection will be created in the in-memory database and then connected both on guacd and web side. Maybe there's a simpler way - maybe I'm overthinking it, but that's the direction I was working. I was also thinking of making it an extension, not a patch or change to the core Guacamole application. > Feature Request - Quick Connect > --- > > Key: GUACAMOLE-137 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-137 > Project: Guacamole > Issue Type: New Feature >Reporter: Greg >Priority: Minor > Labels: features > > A feature that I would find very handy is to have a Quick Connect options so > that rather than creating a connection, there is a text box that accepts the > server name with a drop down on the service type (RDP, VNC, etc) with some > preconfigured defaults... > Personally, I have a lot of servers and it would be much quicker for me to > type the server name than creating all of the connections > Thanks, > Greg -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GUACAMOLE-151) Support Prompting for Authenticators
Nick Couchman created GUACAMOLE-151: --- Summary: Support Prompting for Authenticators Key: GUACAMOLE-151 URL: https://issues.apache.org/jira/browse/GUACAMOLE-151 Project: Guacamole Issue Type: New Feature Components: guacamole Affects Versions: 0.9.10-incubating Reporter: Nick Couchman Priority: Minor Support interactive authentication prompts for connections. There are several reasons for this: - Ability to create connections at an administrative level that apply to many users. - Ability to support RDP NLA authentication/encryption without having to save authenticators. - Ability to have Guacamole authentication different from connection authentication in the above scenarios - no GUAC_USERNAME/PASSWORD passthrough. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GUACAMOLE-151) Support Prompting for Authenticators
[
https://issues.apache.org/jira/browse/GUACAMOLE-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15792106#comment-15792106
]
Nick Couchman commented on GUACAMOLE-151:
-
What if we did a special value similar to the ${GUAC_USERNAME} (and password)
ones that triggers a prompt for that value - something like ${GUAC_PROMPT}?
> Support Prompting for Authenticators
>
>
> Key: GUACAMOLE-151
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-151
> Project: Guacamole
> Issue Type: New Feature
> Components: guacamole
>Reporter: Nick Couchman
>Priority: Minor
>
> Support interactive authentication prompts for connections. There are
> several reasons for this:
> - Ability to create connections at an administrative level that apply to many
> users.
> - Ability to support RDP NLA authentication/encryption without having to save
> authenticators.
> - Ability to have Guacamole authentication different from connection
> authentication in the above scenarios - no GUAC_USERNAME/PASSWORD passthrough.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GUACAMOLE-47) Get client hostname for use in guac RDP session
[ https://issues.apache.org/jira/browse/GUACAMOLE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15805027#comment-15805027 ] Nick Couchman commented on GUACAMOLE-47: Could you clarify what your use-case is for this particular request - what are you wanting to do with the "Clientname" variable? > Get client hostname for use in guac RDP session > --- > > Key: GUACAMOLE-47 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-47 > Project: Guacamole > Issue Type: New Feature > Components: guacamole-client >Affects Versions: 0.9.9 >Reporter: Zach Bonjour >Priority: Minor > > The "Clientname" variable should show the client name connected to the Apache > server. I am not a programmer, but if I am understanding this right, there > is a java servlet that could gather that information so it can be used in the > Guacamole session. > http://docs.oracle.com/javaee/6/api/javax/servlet/ServletRequest.html#getRemoteHost() > Is this possible? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GUACAMOLE-137) Feature Request - Quick Connect
[ https://issues.apache.org/jira/browse/GUACAMOLE-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15805162#comment-15805162 ] Nick Couchman commented on GUACAMOLE-137: - I believe these issues are roughly the same request, combining them. > Feature Request - Quick Connect > --- > > Key: GUACAMOLE-137 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-137 > Project: Guacamole > Issue Type: New Feature >Reporter: Greg >Priority: Minor > Labels: features > > A feature that I would find very handy is to have a Quick Connect options so > that rather than creating a connection, there is a text box that accepts the > server name with a drop down on the service type (RDP, VNC, etc) with some > preconfigured defaults... > Personally, I have a lot of servers and it would be much quicker for me to > type the server name than creating all of the connections > Thanks, > Greg -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GUACAMOLE-47) Get client hostname for use in guac RDP session
[ https://issues.apache.org/jira/browse/GUACAMOLE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15806239#comment-15806239 ] Nick Couchman commented on GUACAMOLE-47: Okay, I've got an initial implementation of this going, which I'll link to after I get it onto GitHub and make sure all of my changes match the contribution guidelines. There are some caveats: - The easiest way to make this work is to grab the HttpServletRequest.getRemoteHost() and getRemoteAddr() values and use those. It's a little more complicated than just that, but that gets what the servlet has as the remote host. Unfortunately this doesn't always work as expected, particularly in situations where Guacamole/Tomcat is behind a reverse proxy, like Apache/mod_proxy or Nginx. - Dealing with the reverse proxy issue isn't too terribly difficult - there's a X-Forwarded-For header that is set by Apache's mod_proxy that can be passed through to the servlet. This has a couple of catches, though - first, it only passes through the IP address that it is forwarding for (essentially the original REMOTE_ADDR request header), and, second, you have to do a little bit extra Tomcat configuration to allow it to be passed through (via the RemoteIP valve). - To deal with proxy scenarios and get both the original REMOTE_HOST and REMOTE_ADDR values, you have to set up custom headers in whatever you're using to proxy, and the Guacamole code has to deal with it. I've written the code to use the custom X-Guacamole-Client-Host and X-Guacamole-Client-IP headers. I'm actually going to deal with these in reverse order - check for the custom headers, first, check for the X-Forwarded-For header, next, and finally use the getRemoteHost and getRemoteAddr methods. I'm happy to take comments from anyone off the bat - I'll post the forked GitHub code in a little while. > Get client hostname for use in guac RDP session > --- > > Key: GUACAMOLE-47 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-47 > Project: Guacamole > Issue Type: New Feature > Components: guacamole-client >Affects Versions: 0.9.9 >Reporter: Zach Bonjour >Priority: Minor > > The "Clientname" variable should show the client name connected to the Apache > server. I am not a programmer, but if I am understanding this right, there > is a java servlet that could gather that information so it can be used in the > Guacamole session. > http://docs.oracle.com/javaee/6/api/javax/servlet/ServletRequest.html#getRemoteHost() > Is this possible? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GUACAMOLE-47) Get client hostname for use in guac RDP session
[
https://issues.apache.org/jira/browse/GUACAMOLE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15806405#comment-15806405
]
Nick Couchman commented on GUACAMOLE-47:
So, code should be ready for review and to try out - if people think I should
submit a pull request, I will, or if you'd rather review in my git repo before
that, that's fine by me. I think I messed up one of the contribution
guidelines in that I committed to the master branch instead of creating a
separate branch, but hopefully that's not a show-stopper. If it is, I'll redo
it. Here's the repo URL:
https://github.com/necouchman/incubator-guacamole-client
To use it, compile and load up the guacamole code. The two new tokens are:
- GUAC_REMHOST
- GUAC_REMIP
If you're connecting to Guacamole directly through Tomcat this should work with
no additional configuration, aside from using the tokens in the connection
configuration.
If you're using a proxy, you'll need to do one of two things:
1) Define the X-Guacamole-Client-Hostname and/or X-Guacamole-Client-IP headers.
Here's an example for Apache that uses the REMOTE_HOST and REMOTE_ADDR headers:
RequestHeader set X-Guacamole-Client-Hostname %{REMOTE_HOST}s
RequestHeader set X-Guacamole-Client-IP %{REMOTE_ADDR}s
2) Configure Tomcat to allow the X-Forwarded-For header to be passed through.
This is done with the following configuration in server.xml. Remember this
will only ever have the IP address - X-Forwarded-For never has the hostname.
Note that you need to set internalProxies to the list of hosts that are
proxying to Guacamole. In my case I'm just doing it on the local system, so I
have 127.0.0.1.
> Get client hostname for use in guac RDP session
> ---
>
> Key: GUACAMOLE-47
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-47
> Project: Guacamole
> Issue Type: New Feature
> Components: guacamole-client
>Affects Versions: 0.9.9
>Reporter: Zach Bonjour
>Priority: Minor
>
> The "Clientname" variable should show the client name connected to the Apache
> server. I am not a programmer, but if I am understanding this right, there
> is a java servlet that could gather that information so it can be used in the
> Guacamole session.
> http://docs.oracle.com/javaee/6/api/javax/servlet/ServletRequest.html#getRemoteHost()
> Is this possible?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GUACAMOLE-29) Add support for requesting HTTP Basic Authentication
[
https://issues.apache.org/jira/browse/GUACAMOLE-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15806734#comment-15806734
]
Nick Couchman commented on GUACAMOLE-29:
So, I took a look at the previous PR and the Guacamole source code has changed
enough between the PR and the Apache Incubator version that I decided just to
rewrite it as an extension module. I have the initial stab out on Github if
anyone wants to take a look and comment/criticize/contribute:
https://github.com/necouchman/guacamole-auth-http/tree/GUACAMOLE-29
A couple of notes:
- I have yet to test this out in a Tomcat environment without a proxy in front
of it. I'll try to get it tested out here, but I'm making the assumption that
it works.
- If you're using a proxy you have to configure it to pass through REMOTE_USER
(or your user-defined header). In Apache you can do this using the
RequestHeader set configuration option.
- If you'd rather use a different header than REMOTE_USER, you can configure it
via the guacamole.properties file and set the http-auth-header option.
> Add support for requesting HTTP Basic Authentication
>
>
> Key: GUACAMOLE-29
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-29
> Project: Guacamole
> Issue Type: Improvement
>Reporter: Michael Jumper
>
> {panel:bgColor=#EE}
> *The description of this issue was copied from
> [GUAC-1489|https://glyptodon.org/jira/browse/GUAC-1489], an issue in the JIRA
> instance used by the Guacamole project prior to its acceptance into the
> Apache Incubator.*
> Comments, attachments, related issues, and history from prior to acceptance
> *have not been copied* and can be found instead at the original issue.
> {panel}
> Some reverse proxies support SSO via HTTP Basic authentication if the server
> requests it with 401 Unauthorized response.
> As Guacamole already reads Authorization header, it looks trivial to add
> guacamole.properties option such as "enable-http-basic-auth", to tell
> Guacamole to request HTTP Basic Authentication .
> PR on its way :)
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (GUACAMOLE-47) Get client hostname for use in guac RDP session
[
https://issues.apache.org/jira/browse/GUACAMOLE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15806405#comment-15806405
]
Nick Couchman edited comment on GUACAMOLE-47 at 1/7/17 4:21 PM:
So, code should be ready for review and to try out - if people think I should
submit a pull request, I will, or if you'd rather review in my git repo before
that, that's fine by me. I think I messed up one of the contribution
guidelines in that I committed to the master branch instead of creating a
separate branch, but hopefully that's not a show-stopper. If it is, I'll redo
it. Here's the repo URL:
https://github.com/necouchman/incubator-guacamole-client
To use it, compile and load up the guacamole code. The two new tokens are:
- GUAC_REMHOST
- GUAC_REMIP
If you're connecting to Guacamole directly through Tomcat this should work with
no additional configuration, aside from using the tokens in the connection
configuration.
If you're using a proxy, you'll need to do one of two things:
1) Define the X-Guacamole-Client-Hostname and/or X-Guacamole-Client-IP headers.
Here's an example for Apache that uses the REMOTE_HOST and REMOTE_ADDR headers:
{code}
RequestHeader set X-Guacamole-Client-Hostname %{REMOTE_HOST}s
RequestHeader set X-Guacamole-Client-IP %{REMOTE_ADDR}s
{code}
2) Configure Tomcat to allow the X-Forwarded-For header to be passed through.
This is done with the following configuration in server.xml. Remember this
will only ever have the IP address - X-Forwarded-For never has the hostname.
{code:xml}
{code}
Note that you need to set internalProxies to the list of hosts that are
proxying to Guacamole. In my case I'm just doing it on the local system, so I
have 127.0.0.1.
was (Author: nick.couch...@yahoo.com):
So, code should be ready for review and to try out - if people think I should
submit a pull request, I will, or if you'd rather review in my git repo before
that, that's fine by me. I think I messed up one of the contribution
guidelines in that I committed to the master branch instead of creating a
separate branch, but hopefully that's not a show-stopper. If it is, I'll redo
it. Here's the repo URL:
https://github.com/necouchman/incubator-guacamole-client
To use it, compile and load up the guacamole code. The two new tokens are:
- GUAC_REMHOST
- GUAC_REMIP
If you're connecting to Guacamole directly through Tomcat this should work with
no additional configuration, aside from using the tokens in the connection
configuration.
If you're using a proxy, you'll need to do one of two things:
1) Define the X-Guacamole-Client-Hostname and/or X-Guacamole-Client-IP headers.
Here's an example for Apache that uses the REMOTE_HOST and REMOTE_ADDR headers:
RequestHeader set X-Guacamole-Client-Hostname %{REMOTE_HOST}s
RequestHeader set X-Guacamole-Client-IP %{REMOTE_ADDR}s
2) Configure Tomcat to allow the X-Forwarded-For header to be passed through.
This is done with the following configuration in server.xml. Remember this
will only ever have the IP address - X-Forwarded-For never has the hostname.
Note that you need to set internalProxies to the list of hosts that are
proxying to Guacamole. In my case I'm just doing it on the local system, so I
have 127.0.0.1.
> Get client hostname for use in guac RDP session
> ---
>
> Key: GUACAMOLE-47
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-47
> Project: Guacamole
> Issue Type: New Feature
> Components: guacamole-client
>Affects Versions: 0.9.9
>Reporter: Zach Bonjour
>Priority: Minor
>
> The "Clientname" variable should show the client name connected to the Apache
> server. I am not a programmer, but if I am understanding this right, there
> is a java servlet that could gather that information so it can be used in the
> Guacamole session.
> http://docs.oracle.com/javaee/6/api/javax/servlet/ServletRequest.html#getRemoteHost()
> Is this possible?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GUACAMOLE-142) Implement a web-browser UA as one of the client protocols
[ https://issues.apache.org/jira/browse/GUACAMOLE-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15807747#comment-15807747 ] Nick Couchman commented on GUACAMOLE-142: - This request appears to be the same as GUACAMOLE-57. > Implement a web-browser UA as one of the client protocols > - > > Key: GUACAMOLE-142 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-142 > Project: Guacamole > Issue Type: New Feature >Reporter: Kristopher Lalletti > Labels: features > > I saw this on a similar product; basically, on-top-and-above supporting > RDP/VNC/SSH/TELNET, support web applications through a stripped-down web > browser running from the guacd host. > As a lot of applications/administration consoles are moving towards HTML5 > interfaces; this opens-up some interesting potential to leverage Guacamole as > a gateway to secure web apps where one would want to isolate everything > except the display rendered to the end-user. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GUACAMOLE-47) Get client hostname for use in guac RDP session
[ https://issues.apache.org/jira/browse/GUACAMOLE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15837932#comment-15837932 ] Nick Couchman commented on GUACAMOLE-47: Pull request 109 created: https://github.com/apache/incubator-guacamole-client/pull/109 > Get client hostname for use in guac RDP session > --- > > Key: GUACAMOLE-47 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-47 > Project: Guacamole > Issue Type: New Feature > Components: guacamole-client >Affects Versions: 0.9.9 >Reporter: Zach Bonjour >Priority: Minor > > The "Clientname" variable should show the client name connected to the Apache > server. I am not a programmer, but if I am understanding this right, there > is a java servlet that could gather that information so it can be used in the > Guacamole session. > http://docs.oracle.com/javaee/6/api/javax/servlet/ServletRequest.html#getRemoteHost() > Is this possible? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GUACAMOLE-29) Add support for requesting HTTP Basic Authentication
[
https://issues.apache.org/jira/browse/GUACAMOLE-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15838147#comment-15838147
]
Nick Couchman commented on GUACAMOLE-29:
Pull request created:
https://github.com/apache/incubator-guacamole-client/pull/110
> Add support for requesting HTTP Basic Authentication
>
>
> Key: GUACAMOLE-29
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-29
> Project: Guacamole
> Issue Type: Improvement
>Reporter: Michael Jumper
>
> {panel:bgColor=#EE}
> *The description of this issue was copied from
> [GUAC-1489|https://glyptodon.org/jira/browse/GUAC-1489], an issue in the JIRA
> instance used by the Guacamole project prior to its acceptance into the
> Apache Incubator.*
> Comments, attachments, related issues, and history from prior to acceptance
> *have not been copied* and can be found instead at the original issue.
> {panel}
> Some reverse proxies support SSO via HTTP Basic authentication if the server
> requests it with 401 Unauthorized response.
> As Guacamole already reads Authorization header, it looks trivial to add
> guacamole.properties option such as "enable-http-basic-auth", to tell
> Guacamole to request HTTP Basic Authentication .
> PR on its way :)
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GUACAMOLE-29) Add support for requesting HTTP Basic Authentication
[
https://issues.apache.org/jira/browse/GUACAMOLE-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15838375#comment-15838375
]
Nick Couchman commented on GUACAMOLE-29:
Sorry, new pull request after dealing with some git issues:
https://github.com/apache/incubator-guacamole-client/pull/111
> Add support for requesting HTTP Basic Authentication
>
>
> Key: GUACAMOLE-29
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-29
> Project: Guacamole
> Issue Type: Improvement
>Reporter: Michael Jumper
>
> {panel:bgColor=#EE}
> *The description of this issue was copied from
> [GUAC-1489|https://glyptodon.org/jira/browse/GUAC-1489], an issue in the JIRA
> instance used by the Guacamole project prior to its acceptance into the
> Apache Incubator.*
> Comments, attachments, related issues, and history from prior to acceptance
> *have not been copied* and can be found instead at the original issue.
> {panel}
> Some reverse proxies support SSO via HTTP Basic authentication if the server
> requests it with 401 Unauthorized response.
> As Guacamole already reads Authorization header, it looks trivial to add
> guacamole.properties option such as "enable-http-basic-auth", to tell
> Guacamole to request HTTP Basic Authentication .
> PR on its way :)
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GUACAMOLE-168) Add support for X.Org
[ https://issues.apache.org/jira/browse/GUACAMOLE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15838407#comment-15838407 ] Nick Couchman commented on GUACAMOLE-168: - I'm not sure if this is related to this issue or not, but alongside this, and one of the reasons that X2Go and NX are nice, is session persistence. This is currently difficult to do with VNC, as it requires that you have a specific port allocated for each user and that you somehow keep track of that port. X2Go and NX implement a back-end that keeps track of user sessions and allows disconnecting and reconnecting without losing the state of the session. This would be *really* nice, in addition to all of the obvious performance benefits...I'm just not sure it is within the scope of the Guacamole project itself, since that is more a function of those specific protocols (RDP, NX, X2Go, etc.). > Add support for X.Org > - > > Key: GUACAMOLE-168 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-168 > Project: Guacamole > Issue Type: New Feature > Components: guacamole-client, guacamole-server >Reporter: Michael Jumper >Assignee: Michael Jumper > > It's been frequently requested that we add support for a more efficient > protocol like NX or X2Go. Though that sounds nice on the surface, and > theoretically would allow us to leverage some of Guacamole's nicer > protocol-level features, investigating deeper reveals: > # X2Go *is* NX - it uses the same protocol behind the scenes. > # NX isn't really a protocol - it is essentially a compressor for X11, and > depends on the client having a local X11 server to handle the decompressed > result. > Implementing support for either of these would thus involve implementing > support for X11, which is crazy. *However:* > What about implementing a driver for the X.Org X11 server? > The X.Org server provides a driver abstraction layer which exposes access to > windows (including their hierarchy) and pixmaps, much in the same way the > Guacamole protocol provides nestable layers and buffers. If we were to > implement a Guacamole driver for X.Org, we would be able to make much greater > use Guacamole protocol features like client-side compositing. Operations > which are typically expensive in VNC or RDP like window movement suddenly > become simple, as they only involve updating the properties of a layer. > I have an experimental implementation of all this, built upon several other > improvements which ended up being required. Work started several years ago, > even before Guacamole was accepted into the Apache Incubator, but I think > it's finally ready to move forward. I've been using it myself for roughly a > month now, and so far so good. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GUACAMOLE-103) SAML 2.0 support for user authentication
[ https://issues.apache.org/jira/browse/GUACAMOLE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15838411#comment-15838411 ] Nick Couchman commented on GUACAMOLE-103: - There are a couple of potential starting points for this: - Mike has an implementation of an OpenID module: https://github.com/mike-jumper/guacamole-auth-openid - Using the OpenID module as a base, I have a very preliminary implementation of a CAS module: https://github.com/necouchman/guacamole-auth-cas The OpenID module is probably the best starting place for SAML, since I believe OpenID is using SAML. You could check out that module and see if it works at all for you. > SAML 2.0 support for user authentication > > > Key: GUACAMOLE-103 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-103 > Project: Guacamole > Issue Type: New Feature >Reporter: Justin P > > It'd be great if Guacamole supported SAML 2.0 so it could integrate with an > organization's single sign-on (SSO) solution (especially popular platforms > like OneLogin, Okta, Bitium, etc.) > This would make authenticating to Guacamole easier for an organization's > users, and it would make organization's IT/IS admins happier being able to > apply authentication security controls to guacamole, such as password > complexity rules, two-factor authentication rules, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GUACAMOLE-195) Support for HTTP Header-Based Authentication
Nick Couchman created GUACAMOLE-195: --- Summary: Support for HTTP Header-Based Authentication Key: GUACAMOLE-195 URL: https://issues.apache.org/jira/browse/GUACAMOLE-195 Project: Guacamole Issue Type: Improvement Components: guacamole, guacamole-client Affects Versions: 0.9.10-incubating Reporter: Nick Couchman Priority: Minor Fix For: 0.9.12-incubating Many SSO solutions and reverse proxies support authenticating users and passing the authentication information via an HTTP header, the most common of which is REMOTE_USER. This authentication extension supports ingesting REMOTE_USER, or a value defined in guacamole.properites, and using that to determine the user. PR is 111, but needs to be rebased and renamed to match this issue. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GUACAMOLE-197) Implement Support for RADIUS Authentication
Nick Couchman created GUACAMOLE-197: --- Summary: Implement Support for RADIUS Authentication Key: GUACAMOLE-197 URL: https://issues.apache.org/jira/browse/GUACAMOLE-197 Project: Guacamole Issue Type: Improvement Components: guacamole, guacamole-client Affects Versions: 0.9.11-incubating Reporter: Nick Couchman Priority: Minor Working on implementing a RADIUS authentication module - guacamole-auth-radius. The basic implementation is completed - with a basic PAP or CHAP RADIUS server, the authentication succeeds and the user is logged in. I'm running into an issue, though, trying to implement Challenge/Response in RADIUS. I have my RADIUS server configured to talk to LinOTP for MFA/2FA, and RADIUS sends the AccessChallenge package back, asking for the second factor. My issue is in my continual failure to grasp the connection between the servlet side and the AngularJS web application. I've copied the Duo authentication code and tried to morph it into something that will present another box for the RADIUS challenge, but I can't get my controller function to actually fire. Once that is working, I'd like to support other RADIUS authentication protocols, like EAP-TLS and EAP-TTLS, so there's a little more work to be done, but right now I'm focusing on the basic protocols and the challenge/response. Will have a repo posted here in a moment for working on this. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-197) Implement Support for RADIUS Authentication
[ https://issues.apache.org/jira/browse/GUACAMOLE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15853339#comment-15853339 ] Nick Couchman commented on GUACAMOLE-197: - My working branch for this issue is here: https://github.com/necouchman/incubator-guacamole-client/tree/GUACAMOLE-197 As stated before, general RADIUS support should work fine for anything that doesn't require a AccessChallenge response, or doesn't require any additional encryption configuration/certificates. Current parameters are as follows: radius-server radius-auth-port radius-acct-port radius-shared-secret radius-auth-protocol I'll take any help getting the following things to work: - AngularJS prompt for the RADIUS Challenge/Response - Additional RADIUS protocols that support encryption,.certificates, and tunneling. > Implement Support for RADIUS Authentication > --- > > Key: GUACAMOLE-197 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-197 > Project: Guacamole > Issue Type: Improvement > Components: guacamole, guacamole-client >Affects Versions: 0.9.11-incubating >Reporter: Nick Couchman >Priority: Minor > Labels: features > > Working on implementing a RADIUS authentication module - > guacamole-auth-radius. The basic implementation is completed - with a basic > PAP or CHAP RADIUS server, the authentication succeeds and the user is logged > in. > I'm running into an issue, though, trying to implement Challenge/Response in > RADIUS. I have my RADIUS server configured to talk to LinOTP for MFA/2FA, > and RADIUS sends the AccessChallenge package back, asking for the second > factor. My issue is in my continual failure to grasp the connection between > the servlet side and the AngularJS web application. I've copied the Duo > authentication code and tried to morph it into something that will present > another box for the RADIUS challenge, but I can't get my controller function > to actually fire. > Once that is working, I'd like to support other RADIUS authentication > protocols, like EAP-TLS and EAP-TTLS, so there's a little more work to be > done, but right now I'm focusing on the basic protocols and the > challenge/response. > Will have a repo posted here in a moment for working on this. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-197) Implement Support for RADIUS Authentication
[ https://issues.apache.org/jira/browse/GUACAMOLE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15853432#comment-15853432 ] Nick Couchman commented on GUACAMOLE-197: - bq. I see that you're using GuacamoleInsufficientCredentialsException, which is the intended mechanism to report that additional credentials are needed (such as a response to a challenge). What issues are you having specifically? So, as you can see in the source code, I check the response packet, and, when I get the AccessChallenge response, I throw the GuacamoleInsufficientCredentialsException. I set up the field with the same field type specified on the AngularJS side, and pass that through to the insufficient credentials method. I've got the JS stuff set up the way I think it ought to be set up, but the controller method never actually runs, and the challenge field/template is never displayed. I'm sure it's either a simple typo or I haven't fully grasped the integration between the servlet and the Angular stuff, so I'm not sure why it isn't firing and displaying the challenge box. > Implement Support for RADIUS Authentication > --- > > Key: GUACAMOLE-197 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-197 > Project: Guacamole > Issue Type: Improvement > Components: guacamole, guacamole-client >Affects Versions: 0.9.11-incubating >Reporter: Nick Couchman >Priority: Minor > > Working on implementing a RADIUS authentication module - > guacamole-auth-radius. The basic implementation is completed - with a basic > PAP or CHAP RADIUS server, the authentication succeeds and the user is logged > in. > I'm running into an issue, though, trying to implement Challenge/Response in > RADIUS. I have my RADIUS server configured to talk to LinOTP for MFA/2FA, > and RADIUS sends the AccessChallenge package back, asking for the second > factor. My issue is in my continual failure to grasp the connection between > the servlet side and the AngularJS web application. I've copied the Duo > authentication code and tried to morph it into something that will present > another box for the RADIUS challenge, but I can't get my controller function > to actually fire. > Once that is working, I'd like to support other RADIUS authentication > protocols, like EAP-TLS and EAP-TTLS, so there's a little more work to be > done, but right now I'm focusing on the basic protocols and the > challenge/response. > Will have a repo posted here in a moment for working on this. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-197) Implement Support for RADIUS Authentication
[
https://issues.apache.org/jira/browse/GUACAMOLE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15853949#comment-15853949
]
Nick Couchman commented on GUACAMOLE-197:
-
Yeah, so something is not working, there. Here's the response I get back:
{noformat}
{"message":"Invalid login","translatableMessage":{"key":"Invalid
login","variables":null},"statusCode":null,"expected":[{"name":"username","type":"USERNAME"},{"name":"password","type":"PASSWORD"}],"type":"INVALID_CREDENTIALS"}
{noformat}
So, I'm guessing that the end there should be INSUFFICIENT_CREDENTIALS instead
of INVALID_CREDENTIALS? And, in the Tomcat log output, I see the following:
{noformat}
07:55:14.055 [http-nio-8080-exec-251] DEBUG
o.a.g.a.l.AuthenticationProviderService - Unable to determine DN for user
"Andy_Taylor".
07:55:14.058 [http-nio-8080-exec-251] DEBUG o.a.g.a.r.RadiusConnectionService -
Sending authentication request to radius server for user Andy_Taylor.
07:55:14.102 [http-nio-8080-exec-251] DEBUG
o.a.g.a.r.AuthenticationProviderService - RADIUS sent challenge response:
Please enter your otp value:
07:55:14.103 [http-nio-8080-exec-251] DEBUG
o.a.g.a.r.AuthenticationProviderService - RADIUS sent state: [B@3b5376ab
07:55:14.103 [http-nio-8080-exec-251] DEBUG
o.a.g.a.r.f.RadiusChallengeResponseField - Initializing the RADIUS
challenge/response field: Please enter your otp value:
07:55:14.103 [http-nio-8080-exec-251] DEBUG
o.a.g.a.f.FileAuthenticationProvider - User mapping file
"/etc/guacamole/user-mapping.xml" does not exist and will not be read.
07:55:14.103 [http-nio-8080-exec-251] WARN o.a.g.r.auth.AuthenticationService
- Authentication attempt from [10.43.112.36, 0:0:0:0:0:0:0:1] for user
"Andy_Taylor" failed.
{noformat}
I would guess that last part - authentication attempt failed - is what's
causing the JSON response to be INVALID_CREDENTIALS instead of
INSUFFICIENT_CREDENTIALS, just not sure at the moment why it's throwing that.
Maybe I'll unload some of the other authentication modules that are in my
extensions folder and see if that helps.
> Implement Support for RADIUS Authentication
> ---
>
> Key: GUACAMOLE-197
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-197
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole, guacamole-client
>Affects Versions: 0.9.11-incubating
>Reporter: Nick Couchman
>Priority: Minor
>
> Working on implementing a RADIUS authentication module -
> guacamole-auth-radius. The basic implementation is completed - with a basic
> PAP or CHAP RADIUS server, the authentication succeeds and the user is logged
> in.
> I'm running into an issue, though, trying to implement Challenge/Response in
> RADIUS. I have my RADIUS server configured to talk to LinOTP for MFA/2FA,
> and RADIUS sends the AccessChallenge package back, asking for the second
> factor. My issue is in my continual failure to grasp the connection between
> the servlet side and the AngularJS web application. I've copied the Duo
> authentication code and tried to morph it into something that will present
> another box for the RADIUS challenge, but I can't get my controller function
> to actually fire.
> Once that is working, I'd like to support other RADIUS authentication
> protocols, like EAP-TLS and EAP-TTLS, so there's a little more work to be
> done, but right now I'm focusing on the basic protocols and the
> challenge/response.
> Will have a repo posted here in a moment for working on this.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-197) Implement Support for RADIUS Authentication
[ https://issues.apache.org/jira/browse/GUACAMOLE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15854004#comment-15854004 ] Nick Couchman commented on GUACAMOLE-197: - Pulled out the LDAP authentication module and another development one that I'm working on, and I get the same result - somewhere along the way the INSUFFICIENT_CREDENTIALS is getting changed to INVALID_CREDENTIALS... > Implement Support for RADIUS Authentication > --- > > Key: GUACAMOLE-197 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-197 > Project: Guacamole > Issue Type: Improvement > Components: guacamole, guacamole-client >Affects Versions: 0.9.11-incubating >Reporter: Nick Couchman >Priority: Minor > > Working on implementing a RADIUS authentication module - > guacamole-auth-radius. The basic implementation is completed - with a basic > PAP or CHAP RADIUS server, the authentication succeeds and the user is logged > in. > I'm running into an issue, though, trying to implement Challenge/Response in > RADIUS. I have my RADIUS server configured to talk to LinOTP for MFA/2FA, > and RADIUS sends the AccessChallenge package back, asking for the second > factor. My issue is in my continual failure to grasp the connection between > the servlet side and the AngularJS web application. I've copied the Duo > authentication code and tried to morph it into something that will present > another box for the RADIUS challenge, but I can't get my controller function > to actually fire. > Once that is working, I'd like to support other RADIUS authentication > protocols, like EAP-TLS and EAP-TTLS, so there's a little more work to be > done, but right now I'm focusing on the basic protocols and the > challenge/response. > Will have a repo posted here in a moment for working on this. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-197) Implement Support for RADIUS Authentication
[ https://issues.apache.org/jira/browse/GUACAMOLE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15854012#comment-15854012 ] Nick Couchman commented on GUACAMOLE-197: - Loaded the DUO module and verified that it throws INSUFFICIENT_CREDENTIALS correctly, so that works...something I'm doing with the RADIUS module is not quite right... > Implement Support for RADIUS Authentication > --- > > Key: GUACAMOLE-197 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-197 > Project: Guacamole > Issue Type: Improvement > Components: guacamole, guacamole-client >Affects Versions: 0.9.11-incubating >Reporter: Nick Couchman >Priority: Minor > > Working on implementing a RADIUS authentication module - > guacamole-auth-radius. The basic implementation is completed - with a basic > PAP or CHAP RADIUS server, the authentication succeeds and the user is logged > in. > I'm running into an issue, though, trying to implement Challenge/Response in > RADIUS. I have my RADIUS server configured to talk to LinOTP for MFA/2FA, > and RADIUS sends the AccessChallenge package back, asking for the second > factor. My issue is in my continual failure to grasp the connection between > the servlet side and the AngularJS web application. I've copied the Duo > authentication code and tried to morph it into something that will present > another box for the RADIUS challenge, but I can't get my controller function > to actually fire. > Once that is working, I'd like to support other RADIUS authentication > protocols, like EAP-TLS and EAP-TTLS, so there's a little more work to be > done, but right now I'm focusing on the basic protocols and the > challenge/response. > Will have a repo posted here in a moment for working on this. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-197) Implement Support for RADIUS Authentication
[ https://issues.apache.org/jira/browse/GUACAMOLE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15854432#comment-15854432 ] Nick Couchman commented on GUACAMOLE-197: - Aha. Renaming the extension to guacamole-auth-0radius.jar did the trick and presents the box for the additional credentials. It doesn't look pretty or actually work at the moment, but it's progress. Thanks. > Implement Support for RADIUS Authentication > --- > > Key: GUACAMOLE-197 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-197 > Project: Guacamole > Issue Type: Improvement > Components: guacamole, guacamole-client >Affects Versions: 0.9.11-incubating >Reporter: Nick Couchman >Priority: Minor > > Working on implementing a RADIUS authentication module - > guacamole-auth-radius. The basic implementation is completed - with a basic > PAP or CHAP RADIUS server, the authentication succeeds and the user is logged > in. > I'm running into an issue, though, trying to implement Challenge/Response in > RADIUS. I have my RADIUS server configured to talk to LinOTP for MFA/2FA, > and RADIUS sends the AccessChallenge package back, asking for the second > factor. My issue is in my continual failure to grasp the connection between > the servlet side and the AngularJS web application. I've copied the Duo > authentication code and tried to morph it into something that will present > another box for the RADIUS challenge, but I can't get my controller function > to actually fire. > Once that is working, I'd like to support other RADIUS authentication > protocols, like EAP-TLS and EAP-TTLS, so there's a little more work to be > done, but right now I'm focusing on the basic protocols and the > challenge/response. > Will have a repo posted here in a moment for working on this. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-197) Implement Support for RADIUS Authentication
[ https://issues.apache.org/jira/browse/GUACAMOLE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15854575#comment-15854575 ] Nick Couchman commented on GUACAMOLE-197: - Okay, making progress here, but have another question. When the RADIUS server sends back the AccessChallenge packet, it also sents a "State" parameter that needs to be saved and used to process the remainder of the authentication. So, something like this: - Send Username, Password - Receive Challenge, State - Send Username, State, Response - Receive Accept/Reject For the connection state, is the best way to do this to pass the state into the AngularJS form where the user enters the challenge response, and then somehow pass it back, or is there some way to internally add the state to the Java servlet side such that I can pick it back up and use it, again? I'd rather not pass it through the browser front-end if I don't have to - seems more secure if I can keep it all on the servlet side - but I'm not sure the best place to create that storage item. I tried to just add it to the AuthenticationProviderService class that I'm implementing in the module, but it looks like the class gets re-instantiated during the second go-around, so there isn't anything persistent there. I'm not sure if there's another session class I should use or something like that? > Implement Support for RADIUS Authentication > --- > > Key: GUACAMOLE-197 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-197 > Project: Guacamole > Issue Type: Improvement > Components: guacamole, guacamole-client >Affects Versions: 0.9.11-incubating >Reporter: Nick Couchman >Priority: Minor > > Working on implementing a RADIUS authentication module - > guacamole-auth-radius. The basic implementation is completed - with a basic > PAP or CHAP RADIUS server, the authentication succeeds and the user is logged > in. > I'm running into an issue, though, trying to implement Challenge/Response in > RADIUS. I have my RADIUS server configured to talk to LinOTP for MFA/2FA, > and RADIUS sends the AccessChallenge package back, asking for the second > factor. My issue is in my continual failure to grasp the connection between > the servlet side and the AngularJS web application. I've copied the Duo > authentication code and tried to morph it into something that will present > another box for the RADIUS challenge, but I can't get my controller function > to actually fire. > Once that is working, I'd like to support other RADIUS authentication > protocols, like EAP-TLS and EAP-TTLS, so there's a little more work to be > done, but right now I'm focusing on the basic protocols and the > challenge/response. > Will have a repo posted here in a moment for working on this. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-197) Implement Support for RADIUS Authentication
[ https://issues.apache.org/jira/browse/GUACAMOLE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15855255#comment-15855255 ] Nick Couchman commented on GUACAMOLE-197: - Here's the documentation on the attribute itself from the IETF standard: https://tools.ietf.org/html/rfc2865#section-5.24 >From what I can tell reading that and some other Internet sources, the risk of >exposing the state field to the authenticating user should be minimal. My >rationale is as follows: - The state field appears to be just a session marker in the RADIUS conversation, used specifically when the authenticating system needs to provide additional information to the server, or when the RADIUS server needs to do something at termination of a connection. - There hasn't been a lot done to obfuscate or encrypt the field itself. The RADIUS protocol as a whole has developed several security measures to protect the overall transmission, but there hasn't been any focus on the state protocol specifically. - Obviously a third-party attacker being able to read the state field could use it to try to impersonate the user or intercept the connection; however, there's equally (more?) sensitive data in the payload than the state - like username and password. So, I don't think there's any harm in the person who's doing the authentication seeing the state value. > Implement Support for RADIUS Authentication > --- > > Key: GUACAMOLE-197 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-197 > Project: Guacamole > Issue Type: Improvement > Components: guacamole, guacamole-client >Affects Versions: 0.9.11-incubating >Reporter: Nick Couchman >Priority: Minor > > Working on implementing a RADIUS authentication module - > guacamole-auth-radius. The basic implementation is completed - with a basic > PAP or CHAP RADIUS server, the authentication succeeds and the user is logged > in. > I'm running into an issue, though, trying to implement Challenge/Response in > RADIUS. I have my RADIUS server configured to talk to LinOTP for MFA/2FA, > and RADIUS sends the AccessChallenge package back, asking for the second > factor. My issue is in my continual failure to grasp the connection between > the servlet side and the AngularJS web application. I've copied the Duo > authentication code and tried to morph it into something that will present > another box for the RADIUS challenge, but I can't get my controller function > to actually fire. > Once that is working, I'd like to support other RADIUS authentication > protocols, like EAP-TLS and EAP-TTLS, so there's a little more work to be > done, but right now I'm focusing on the basic protocols and the > challenge/response. > Will have a repo posted here in a moment for working on this. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-197) Implement Support for RADIUS Authentication
[ https://issues.apache.org/jira/browse/GUACAMOLE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15856087#comment-15856087 ] Nick Couchman commented on GUACAMOLE-197: - Got it...will just pass it through as a hidden field in the challenge/response process, unless there's a better way to do it. Having cleared that hurdle, I'm on to the next one - how to deal with the value of the state parameter in a safe way. When I look at the debug output from FreeRADIUS, the state shows up as a hexadecimal value. When I deal with it as a String in Java, it almost looks like a binary value. Tried a few rounds of converting it to an integer and dealing with it that way, but that didn't seem to work, so going to try a byte array, now, and see what happens. Only concern is trying to pass a binary value through to AngularJS and then get it back safely...fun times! > Implement Support for RADIUS Authentication > --- > > Key: GUACAMOLE-197 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-197 > Project: Guacamole > Issue Type: Improvement > Components: guacamole, guacamole-client >Affects Versions: 0.9.11-incubating >Reporter: Nick Couchman >Priority: Minor > > Working on implementing a RADIUS authentication module - > guacamole-auth-radius. The basic implementation is completed - with a basic > PAP or CHAP RADIUS server, the authentication succeeds and the user is logged > in. > I'm running into an issue, though, trying to implement Challenge/Response in > RADIUS. I have my RADIUS server configured to talk to LinOTP for MFA/2FA, > and RADIUS sends the AccessChallenge package back, asking for the second > factor. My issue is in my continual failure to grasp the connection between > the servlet side and the AngularJS web application. I've copied the Duo > authentication code and tried to morph it into something that will present > another box for the RADIUS challenge, but I can't get my controller function > to actually fire. > Once that is working, I'd like to support other RADIUS authentication > protocols, like EAP-TLS and EAP-TTLS, so there's a little more work to be > done, but right now I'm focusing on the basic protocols and the > challenge/response. > Will have a repo posted here in a moment for working on this. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-197) Implement Support for RADIUS Authentication
[ https://issues.apache.org/jira/browse/GUACAMOLE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15856728#comment-15856728 ] Nick Couchman commented on GUACAMOLE-197: - Finally, figured out the right incantation of JRadius methods to get the state out in a sane fashion. Will have updated code committed here, shortly. This particular module should be functional now for PAP, CHAP, and several MS-CHAP RADIUS protocols - basically anything that doesn't require extra security like TLS. I need to fix some display issues with the Challenge/Response prompt, as well. > Implement Support for RADIUS Authentication > --- > > Key: GUACAMOLE-197 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-197 > Project: Guacamole > Issue Type: Improvement > Components: guacamole, guacamole-client >Affects Versions: 0.9.11-incubating >Reporter: Nick Couchman >Priority: Minor > > Working on implementing a RADIUS authentication module - > guacamole-auth-radius. The basic implementation is completed - with a basic > PAP or CHAP RADIUS server, the authentication succeeds and the user is logged > in. > I'm running into an issue, though, trying to implement Challenge/Response in > RADIUS. I have my RADIUS server configured to talk to LinOTP for MFA/2FA, > and RADIUS sends the AccessChallenge package back, asking for the second > factor. My issue is in my continual failure to grasp the connection between > the servlet side and the AngularJS web application. I've copied the Duo > authentication code and tried to morph it into something that will present > another box for the RADIUS challenge, but I can't get my controller function > to actually fire. > Once that is working, I'd like to support other RADIUS authentication > protocols, like EAP-TLS and EAP-TTLS, so there's a little more work to be > done, but right now I'm focusing on the basic protocols and the > challenge/response. > Will have a repo posted here in a moment for working on this. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-197) Implement Support for RADIUS Authentication
[ https://issues.apache.org/jira/browse/GUACAMOLE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15857290#comment-15857290 ] Nick Couchman commented on GUACAMOLE-197: - Okay, working module, and the prompt for the additional response looks much better, and should be relatively translation-friendly. Now I need to work on steps necessary to support the additional RADIUS authentication protocols, which will probably mean reorganizing some of the code in the RadiusConnectionService class. > Implement Support for RADIUS Authentication > --- > > Key: GUACAMOLE-197 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-197 > Project: Guacamole > Issue Type: Improvement > Components: guacamole, guacamole-client >Affects Versions: 0.9.11-incubating >Reporter: Nick Couchman >Priority: Minor > > Working on implementing a RADIUS authentication module - > guacamole-auth-radius. The basic implementation is completed - with a basic > PAP or CHAP RADIUS server, the authentication succeeds and the user is logged > in. > I'm running into an issue, though, trying to implement Challenge/Response in > RADIUS. I have my RADIUS server configured to talk to LinOTP for MFA/2FA, > and RADIUS sends the AccessChallenge package back, asking for the second > factor. My issue is in my continual failure to grasp the connection between > the servlet side and the AngularJS web application. I've copied the Duo > authentication code and tried to morph it into something that will present > another box for the RADIUS challenge, but I can't get my controller function > to actually fire. > Once that is working, I'd like to support other RADIUS authentication > protocols, like EAP-TLS and EAP-TTLS, so there's a little more work to be > done, but right now I'm focusing on the basic protocols and the > challenge/response. > Will have a repo posted here in a moment for working on this. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-197) Implement Support for RADIUS Authentication
[ https://issues.apache.org/jira/browse/GUACAMOLE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15859591#comment-15859591 ] Nick Couchman commented on GUACAMOLE-197: - Reorganized the code a bit. Need to get a RADIUS server set up to test out some of the TLS protocols and make sure those work, but so far so good. I am having trouble with MAVEN and signed modules. The jradius-extended dependency pulls in another one called BouncyCastle, which is a SSL/TLS implementation for Java. One of those modules is signed, and it's causing all sorts of trouble getting the RADIUS Authentication module to load. I tried several incantations for a couple hours yesterday to get MAVEN to filter out the signing files when building the RADIUS jar file, to no avail. I can post more info, if needed, but any suggestions there would be appreciated. For the time being I've resorted to manually using the zip command to remove the signatures from the resulting JAR...obviously that's a poor long-term solution. > Implement Support for RADIUS Authentication > --- > > Key: GUACAMOLE-197 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-197 > Project: Guacamole > Issue Type: Improvement > Components: guacamole, guacamole-client >Affects Versions: 0.9.11-incubating >Reporter: Nick Couchman >Priority: Minor > > Working on implementing a RADIUS authentication module - > guacamole-auth-radius. The basic implementation is completed - with a basic > PAP or CHAP RADIUS server, the authentication succeeds and the user is logged > in. > I'm running into an issue, though, trying to implement Challenge/Response in > RADIUS. I have my RADIUS server configured to talk to LinOTP for MFA/2FA, > and RADIUS sends the AccessChallenge package back, asking for the second > factor. My issue is in my continual failure to grasp the connection between > the servlet side and the AngularJS web application. I've copied the Duo > authentication code and tried to morph it into something that will present > another box for the RADIUS challenge, but I can't get my controller function > to actually fire. > Once that is working, I'd like to support other RADIUS authentication > protocols, like EAP-TLS and EAP-TTLS, so there's a little more work to be > done, but right now I'm focusing on the basic protocols and the > challenge/response. > Will have a repo posted here in a moment for working on this. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-197) Implement Support for RADIUS Authentication
[ https://issues.apache.org/jira/browse/GUACAMOLE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15860128#comment-15860128 ] Nick Couchman commented on GUACAMOLE-197: - Latest commit to my branch results in working PAP, CHAP, and EAP-MD5 authentication protocols via RADIUS. Next stop: TLS varieties - PEAP, EAP-TLS, and EAP-TTLS. > Implement Support for RADIUS Authentication > --- > > Key: GUACAMOLE-197 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-197 > Project: Guacamole > Issue Type: Improvement > Components: guacamole, guacamole-client >Affects Versions: 0.9.11-incubating >Reporter: Nick Couchman >Priority: Minor > > Working on implementing a RADIUS authentication module - > guacamole-auth-radius. The basic implementation is completed - with a basic > PAP or CHAP RADIUS server, the authentication succeeds and the user is logged > in. > I'm running into an issue, though, trying to implement Challenge/Response in > RADIUS. I have my RADIUS server configured to talk to LinOTP for MFA/2FA, > and RADIUS sends the AccessChallenge package back, asking for the second > factor. My issue is in my continual failure to grasp the connection between > the servlet side and the AngularJS web application. I've copied the Duo > authentication code and tried to morph it into something that will present > another box for the RADIUS challenge, but I can't get my controller function > to actually fire. > Once that is working, I'd like to support other RADIUS authentication > protocols, like EAP-TLS and EAP-TTLS, so there's a little more work to be > done, but right now I'm focusing on the basic protocols and the > challenge/response. > Will have a repo posted here in a moment for working on this. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GUACAMOLE-204) Support CAS Single Sign On
Nick Couchman created GUACAMOLE-204: --- Summary: Support CAS Single Sign On Key: GUACAMOLE-204 URL: https://issues.apache.org/jira/browse/GUACAMOLE-204 Project: Guacamole Issue Type: Improvement Components: guacamole-client Affects Versions: 0.9.11-incubating Reporter: Nick Couchman Priority: Minor Implement authentication module to support Apereo CAS Single Sign On (SSO) integration. Pull request to follow shortly. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-204) Support CAS Single Sign On
[ https://issues.apache.org/jira/browse/GUACAMOLE-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15861310#comment-15861310 ] Nick Couchman commented on GUACAMOLE-204: - Pull request 121: https://github.com/apache/incubator-guacamole-client/pull/121 > Support CAS Single Sign On > -- > > Key: GUACAMOLE-204 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-204 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-client >Affects Versions: 0.9.11-incubating >Reporter: Nick Couchman >Priority: Minor > > Implement authentication module to support Apereo CAS Single Sign On (SSO) > integration. Pull request to follow shortly. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-197) Implement Support for RADIUS Authentication
[ https://issues.apache.org/jira/browse/GUACAMOLE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15861880#comment-15861880 ] Nick Couchman commented on GUACAMOLE-197: - Okay, confirmed that the following RADIUS protocols work correctly: PAP, CHAP, EAP-MD5, EAP-TLS, and EAP-TTLS. I cannot get PEAP to work at the moment - there's an issue opened on the JRadius github project with another user having a similar issue, and I'm uncertain if it's an implementation issue in my code or in the JRadius code. I'm tempted to go ahead and submit a PR for this as-is with the caveat that PEAP does not work, and address PEAP later, but will definitely continue to hammer on PEAP and see if I can figure out what I'm not doing quite right. > Implement Support for RADIUS Authentication > --- > > Key: GUACAMOLE-197 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-197 > Project: Guacamole > Issue Type: Improvement > Components: guacamole, guacamole-client >Affects Versions: 0.9.11-incubating >Reporter: Nick Couchman >Priority: Minor > > Working on implementing a RADIUS authentication module - > guacamole-auth-radius. The basic implementation is completed - with a basic > PAP or CHAP RADIUS server, the authentication succeeds and the user is logged > in. > I'm running into an issue, though, trying to implement Challenge/Response in > RADIUS. I have my RADIUS server configured to talk to LinOTP for MFA/2FA, > and RADIUS sends the AccessChallenge package back, asking for the second > factor. My issue is in my continual failure to grasp the connection between > the servlet side and the AngularJS web application. I've copied the Duo > authentication code and tried to morph it into something that will present > another box for the RADIUS challenge, but I can't get my controller function > to actually fire. > Once that is working, I'd like to support other RADIUS authentication > protocols, like EAP-TLS and EAP-TTLS, so there's a little more work to be > done, but right now I'm focusing on the basic protocols and the > challenge/response. > Will have a repo posted here in a moment for working on this. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-197) Implement Support for RADIUS Authentication
[ https://issues.apache.org/jira/browse/GUACAMOLE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15861944#comment-15861944 ] Nick Couchman commented on GUACAMOLE-197: - MS-CHAP varieties should also be working. I found that the JRadius simulator behaves identically with PEAP as the current implementation for the Guacamole module, so I'm fairly confident it's either my configuration of FreeRADIUS or something internal to the JRadius implementation. Pull request coming soon. > Implement Support for RADIUS Authentication > --- > > Key: GUACAMOLE-197 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-197 > Project: Guacamole > Issue Type: Improvement > Components: guacamole, guacamole-client >Affects Versions: 0.9.11-incubating >Reporter: Nick Couchman >Priority: Minor > > Working on implementing a RADIUS authentication module - > guacamole-auth-radius. The basic implementation is completed - with a basic > PAP or CHAP RADIUS server, the authentication succeeds and the user is logged > in. > I'm running into an issue, though, trying to implement Challenge/Response in > RADIUS. I have my RADIUS server configured to talk to LinOTP for MFA/2FA, > and RADIUS sends the AccessChallenge package back, asking for the second > factor. My issue is in my continual failure to grasp the connection between > the servlet side and the AngularJS web application. I've copied the Duo > authentication code and tried to morph it into something that will present > another box for the RADIUS challenge, but I can't get my controller function > to actually fire. > Once that is working, I'd like to support other RADIUS authentication > protocols, like EAP-TLS and EAP-TTLS, so there's a little more work to be > done, but right now I'm focusing on the basic protocols and the > challenge/response. > Will have a repo posted here in a moment for working on this. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-102) Loadbalancing based on resource
[ https://issues.apache.org/jira/browse/GUACAMOLE-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15895446#comment-15895446 ] Nick Couchman commented on GUACAMOLE-102: - So, I was looking at the history of this as well as the commit request that was originally opened for this and was thinking about a potential approach. It seems like the changes to the Guacamole Client code could remain pretty minimal: - Implement a connection weight field for individual connections, but only reference it when the connection is part of a Connection Group of type BALANCING. I haven't dug into the parameter vs. attribute vs. arbitrary data issue mentioned in the commit request, but a simple connection weight field that is a positive integer should do the trick. - Tweak the Guacamole balancer algorithm from round-robin to weighted round-robin, where the default weight of each connection is 1 if not defined, can be set manually for the connection, or can be externally manipulated. The part that I think bears further discussion is the "some other means" of manipulating the weight. Is that something that really belongs in the Guacamole Client code, or is it something that, if hooks are provided, might belong to some other component or external application? When you start talking about an agent that goes on a remote server to monitor the server and adjust the weight, the scope of the "guacamole client" expands a little bit. Also, if we decide load monitoring/balancing is within the scope of the guacamole client, there might be some other existing ways to monitor load that don't require reinventing the wheel. SNMP comes to mind, since agents are readily available and easily configurable on most platforms, and there are also things like WinRM and WMI that might also provide the required information for Windows hosts. However, if you use existing technologies like SNMP that would require something else - either code inside Guacamole or another daemon/job/script - to periodically poll the servers in the connection group and adjust the weight. Thoughts? > Loadbalancing based on resource > --- > > Key: GUACAMOLE-102 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-102 > Project: Guacamole > Issue Type: New Feature > Components: guacamole, guacamole-auth-jdbc, > guacamole-auth-jdbc-mysql, guacamole-auth-jdbc-postgresql, guacamole-client, > RDP >Affects Versions: 0.9.10-incubating > Environment: CentOS Linux 7 (Core) > Linux 3.10.0-327.10.1.el7.x86_64 >Reporter: Werner Novak >Priority: Minor > > Implementation of an resource based (CPU, Memory, I/O, Loggedin User) > balancing in opposite to the current implemented guacamole connections round > robin. This is needed because of an large RDP infrastructure (300+ TS), where > the terminal server been accessed via multiple RDP load balancers during > migration. > A prototype has been developed in a guacamole fork > https://github.com/wnovak/incubator-guacamole-client.git -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-243) ldap auth fails when search results include an LDAP referral
[ https://issues.apache.org/jira/browse/GUACAMOLE-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15930099#comment-15930099 ] Nick Couchman commented on GUACAMOLE-243: - So, I guess my first question here is this: is simply ignoring the error the right thing to do? I understand the problem, particularly with AD (and it helps me understand why I had to point my Guacamole instance at the GC port :-), but it seems like it would probably be a more proper LDAP client implementation if it did something with the failure to follow the referral. For one thing, perhaps we should add a configuration item to the guacamole.properties file that controls whether or not referrals are followed at all, and then, based on whether that is configured or not and if this error gets received, do something with the error. Ignoring it might be one possible route to go (e.g. if you explicitly disabled following referrals), but you also might want to do something else with the error if you expect the referral to be followed and it isn't. -Nick > ldap auth fails when search results include an LDAP referral > > > Key: GUACAMOLE-243 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-243 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-ldap >Reporter: Adam Thorn > > The ldap search in > extensions/guacamole-auth-ldap/src/main/java/org/apache/guacamole/auth/ldap/user/UserService.java > to find the DN of the user who is logging in (i.e. inside getUserDNs() ) > fails if the LDAPSearchResults include an LDAP referral, because > LDAPSearchResults.next() throws an LDAPReferralException: > https://www.novell.com/documentation/developer/jldap/jldapenu/api/com/novell/ldap/LDAPSearchResults.html#next() > This particularly affects Active Directory, where typically the LDAP > implementation has separate partitions for DNS zones and Configuration (see > e.g. > http://stackoverflow.com/questions/32989159/ldapsearch-entire-active-directory-without-refldap-returns > for an example of the three LDAP referrals that AD returns). Empirically, > against my AD, even when an ldap search for (sAMAccountName=$USERNAME) > correctly returns the dn for the searched-for $USERNAME , I still also get > the three ldap referrals mentioned in that stackoverflow post. Thus, even > though the first result in the LDAPSearchResults has the correct dn for the > user logging in, results.next() then throws an exception when it encounters > the referral and the login fails. > This only happens when ldap-user-base-dn is set to the base dn of my AD (i.e. > with dc=example,dc=com I get referrals, but with ou=Users,dc=example,dc=com > as the search base I do not). The structure of my AD requires me to set the > base dn as the search base, though. > N.B. A possible workaround is to explicitly query the Global Catalog (by > setting ldap-port: 3268). However, that performs a forest-wide search rather > than just a domain-wide search, which might not be desired. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-243) ldap auth fails when search results include an LDAP referral
[ https://issues.apache.org/jira/browse/GUACAMOLE-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15930123#comment-15930123 ] Nick Couchman commented on GUACAMOLE-243: - Looking at the following Novell (MicroFocus/HPE) documentation: https://www.novell.com/documentation/developer/jldap/jldapenu/data/aaf0eaa.html#aap9xg2 Looks like you can use the LDAPConstraints.setReferralFollowing option to set the referral following of the connection. So, some slight tweaks to the LDAP client code would at least allow us to add an option that controls this behavior and enable it. It is disabled by default, which is probably why as soon as you point it at an AD LDAP connection of the non-GC variety you get exceptions. Here's the page on using constraints: https://www.novell.com/documentation/developer/jldap/jldapenu/data/a903509.html#aap9881 > ldap auth fails when search results include an LDAP referral > > > Key: GUACAMOLE-243 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-243 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-ldap >Reporter: Adam Thorn > > The ldap search in > extensions/guacamole-auth-ldap/src/main/java/org/apache/guacamole/auth/ldap/user/UserService.java > to find the DN of the user who is logging in (i.e. inside getUserDNs() ) > fails if the LDAPSearchResults include an LDAP referral, because > LDAPSearchResults.next() throws an LDAPReferralException: > https://www.novell.com/documentation/developer/jldap/jldapenu/api/com/novell/ldap/LDAPSearchResults.html#next() > This particularly affects Active Directory, where typically the LDAP > implementation has separate partitions for DNS zones and Configuration (see > e.g. > http://stackoverflow.com/questions/32989159/ldapsearch-entire-active-directory-without-refldap-returns > for an example of the three LDAP referrals that AD returns). Empirically, > against my AD, even when an ldap search for (sAMAccountName=$USERNAME) > correctly returns the dn for the searched-for $USERNAME , I still also get > the three ldap referrals mentioned in that stackoverflow post. Thus, even > though the first result in the LDAPSearchResults has the correct dn for the > user logging in, results.next() then throws an exception when it encounters > the referral and the login fails. > This only happens when ldap-user-base-dn is set to the base dn of my AD (i.e. > with dc=example,dc=com I get referrals, but with ou=Users,dc=example,dc=com > as the search base I do not). The structure of my AD requires me to set the > base dn as the search base, though. > N.B. A possible workaround is to explicitly query the Global Catalog (by > setting ldap-port: 3268). However, that performs a forest-wide search rather > than just a domain-wide search, which might not be desired. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-243) ldap auth fails when search results include an LDAP referral
[ https://issues.apache.org/jira/browse/GUACAMOLE-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15930148#comment-15930148 ] Nick Couchman commented on GUACAMOLE-243: - And, on top of the LDAPConstraints (that apply to the connection as a whole), there's also LDAPSearchConstraints, which apply to a particular search operation... > ldap auth fails when search results include an LDAP referral > > > Key: GUACAMOLE-243 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-243 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-ldap >Reporter: Adam Thorn > > The ldap search in > extensions/guacamole-auth-ldap/src/main/java/org/apache/guacamole/auth/ldap/user/UserService.java > to find the DN of the user who is logging in (i.e. inside getUserDNs() ) > fails if the LDAPSearchResults include an LDAP referral, because > LDAPSearchResults.next() throws an LDAPReferralException: > https://www.novell.com/documentation/developer/jldap/jldapenu/api/com/novell/ldap/LDAPSearchResults.html#next() > This particularly affects Active Directory, where typically the LDAP > implementation has separate partitions for DNS zones and Configuration (see > e.g. > http://stackoverflow.com/questions/32989159/ldapsearch-entire-active-directory-without-refldap-returns > for an example of the three LDAP referrals that AD returns). Empirically, > against my AD, even when an ldap search for (sAMAccountName=$USERNAME) > correctly returns the dn for the searched-for $USERNAME , I still also get > the three ldap referrals mentioned in that stackoverflow post. Thus, even > though the first result in the LDAPSearchResults has the correct dn for the > user logging in, results.next() then throws an exception when it encounters > the referral and the login fails. > This only happens when ldap-user-base-dn is set to the base dn of my AD (i.e. > with dc=example,dc=com I get referrals, but with ou=Users,dc=example,dc=com > as the search base I do not). The structure of my AD requires me to set the > base dn as the search base, though. > N.B. A possible workaround is to explicitly query the Global Catalog (by > setting ldap-port: 3268). However, that performs a forest-wide search rather > than just a domain-wide search, which might not be desired. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-243) ldap auth fails when search results include an LDAP referral
[ https://issues.apache.org/jira/browse/GUACAMOLE-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15930315#comment-15930315 ] Nick Couchman commented on GUACAMOLE-243: - Just to follow up a little more on the Novell LDAP implementation...if you want to follow referrals, in addition to setting up the aforementioned option, you also have to set the setReferralHandler() option and implement one of the two possible LDAPReferralHandler options: LDAPAuthHandler or LDAPBindHandler. If you do not, the Novell LDAP java class defaults to anonymous binds in order to follow the referrals, and, particularly if you're using AD (or any other LDAP directory server configured to disallow anonymous binds), you're going to run into problems. So, for this particular extension, it means implementing the configuration options for following LDAP referrals, and also a class or two that implement one or both of the above abstract referral handler classes. Here are some links to documentation that will help with this: https://www.novell.com/documentation/developer/jldap/jldapenu/api/com/novell/ldap/LDAPReferralHandler.html (Comments at the top of the following document are most helpful as it describes the behavior of the class and the various ways to handle referrals): https://www.novell.com/documentation/developer/samplecode/jldap_sample/SearchUtil.java.html It'd be nice if the Novell LDAP class referral following defaults to using your existing configuration rather than just anonymous - that is, if you've configured it to bind as a certain user, it'll bind as that user, if you're using anonymous, it'll do anonymous, etc. But, no such luck...at least the LDAPBindHandler class will have to be implemented, if not both that and LDAPAuthHandler. > ldap auth fails when search results include an LDAP referral > > > Key: GUACAMOLE-243 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-243 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-ldap >Reporter: Adam Thorn > > The ldap search in > extensions/guacamole-auth-ldap/src/main/java/org/apache/guacamole/auth/ldap/user/UserService.java > to find the DN of the user who is logging in (i.e. inside getUserDNs() ) > fails if the LDAPSearchResults include an LDAP referral, because > LDAPSearchResults.next() throws an LDAPReferralException: > https://www.novell.com/documentation/developer/jldap/jldapenu/api/com/novell/ldap/LDAPSearchResults.html#next() > This particularly affects Active Directory, where typically the LDAP > implementation has separate partitions for DNS zones and Configuration (see > e.g. > http://stackoverflow.com/questions/32989159/ldapsearch-entire-active-directory-without-refldap-returns > for an example of the three LDAP referrals that AD returns). Empirically, > against my AD, even when an ldap search for (sAMAccountName=$USERNAME) > correctly returns the dn for the searched-for $USERNAME , I still also get > the three ldap referrals mentioned in that stackoverflow post. Thus, even > though the first result in the LDAPSearchResults has the correct dn for the > user logging in, results.next() then throws an exception when it encounters > the referral and the login fails. > This only happens when ldap-user-base-dn is set to the base dn of my AD (i.e. > with dc=example,dc=com I get referrals, but with ou=Users,dc=example,dc=com > as the search base I do not). The structure of my AD requires me to set the > base dn as the search base, though. > N.B. A possible workaround is to explicitly query the Global Catalog (by > setting ldap-port: 3268). However, that performs a forest-wide search rather > than just a domain-wide search, which might not be desired. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-243) LDAP auth fails when search results include an LDAP referral
[ https://issues.apache.org/jira/browse/GUACAMOLE-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15931242#comment-15931242 ] Nick Couchman commented on GUACAMOLE-243: - Adam, I believe your logic here was sound for 1/2 the picture - if you don't want to follow LDAP referrals (the default behavior of the Novell LDAP library), and the LDAP server sends you one, you should ignore it (rather than trying to follow it) and continue with the next result. I took this and ran with it, adding the following things to it: - New parameters which enable referral following in the LDAP connection. - If referral following is enabled, and we get an LDAPReferralException, then we throw a GuacamoleServerException, rather than just ignoring it. - Your code, which, if referral following is enabled, logs the error but continues processing results. - Added the same logic to the ConnectionService class, since it also deals with LDAP results and could encounter referral following exceptions, as well. With the current code I can authenticate against the rather large AD system in my organization with referral following either enabled or disabled. Mike, I'm not sure what the "proper" way to go about this is - I'm going to open a new pull request from my copy of the repo with the combination of Adam's code and mine. If there's a different way I should handle this, let me know. > LDAP auth fails when search results include an LDAP referral > > > Key: GUACAMOLE-243 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-243 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-ldap >Reporter: Adam Thorn > > The ldap search in > extensions/guacamole-auth-ldap/src/main/java/org/apache/guacamole/auth/ldap/user/UserService.java > to find the DN of the user who is logging in (i.e. inside getUserDNs() ) > fails if the LDAPSearchResults include an LDAP referral, because > LDAPSearchResults.next() throws an LDAPReferralException: > https://www.novell.com/documentation/developer/jldap/jldapenu/api/com/novell/ldap/LDAPSearchResults.html#next() > This particularly affects Active Directory, where typically the LDAP > implementation has separate partitions for DNS zones and Configuration (see > e.g. > http://stackoverflow.com/questions/32989159/ldapsearch-entire-active-directory-without-refldap-returns > for an example of the three LDAP referrals that AD returns). Empirically, > against my AD, even when an ldap search for (sAMAccountName=$USERNAME) > correctly returns the dn for the searched-for $USERNAME , I still also get > the three ldap referrals mentioned in that stackoverflow post. Thus, even > though the first result in the LDAPSearchResults has the correct dn for the > user logging in, results.next() then throws an exception when it encounters > the referral and the login fails. > This only happens when ldap-user-base-dn is set to the base dn of my AD (i.e. > with dc=example,dc=com I get referrals, but with ou=Users,dc=example,dc=com > as the search base I do not). The structure of my AD requires me to set the > base dn as the search base, though. > N.B. A possible workaround is to explicitly query the Global Catalog (by > setting ldap-port: 3268). However, that performs a forest-wide search rather > than just a domain-wide search, which might not be desired. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GUACAMOLE-244) Allow Configuration of Alias Dereferencing
Nick Couchman created GUACAMOLE-244: --- Summary: Allow Configuration of Alias Dereferencing Key: GUACAMOLE-244 URL: https://issues.apache.org/jira/browse/GUACAMOLE-244 Project: Guacamole Issue Type: Improvement Components: guacamole-auth-ldap Affects Versions: 0.9.11-incubating Reporter: Nick Couchman Assignee: Nick Couchman Priority: Minor Fix For: 0.9.13-incubating Allow Alias Dereferencing Behavior to be Configured by User -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-244) Allow Configuration of Alias Dereferencing
[ https://issues.apache.org/jira/browse/GUACAMOLE-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15931250#comment-15931250 ] Nick Couchman commented on GUACAMOLE-244: - Similar to referral following, it is useful in certain situations to allow the user to decide if aliases should be dereferenced or not: - An admin may want to create a separate area for users or connections and just alias the users rather than moving or creating them there. - Such areas in the LDAP tree might already exist, and might cause problems (e.g. duplicate users) if someone is querying an entire tree and dereferencing aliases. I'll have a pull request sometime this weekend... > Allow Configuration of Alias Dereferencing > -- > > Key: GUACAMOLE-244 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-244 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-auth-ldap >Affects Versions: 0.9.11-incubating >Reporter: Nick Couchman >Assignee: Nick Couchman >Priority: Minor > Fix For: 0.9.13-incubating > > > Allow Alias Dereferencing Behavior to be Configured by User -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-243) LDAP auth fails when search results include an LDAP referral
[ https://issues.apache.org/jira/browse/GUACAMOLE-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15931291#comment-15931291 ] Nick Couchman commented on GUACAMOLE-243: - That makes sense. Adam, please accept my apologies - I'm pretty new to this and just figuring out my way around contributions to an open source project, so I'm still figuring out some of the etiquette. I closed my pull request. Forgive another n00b question, but what's the best way to go about collaborating on these changes? Should I fork Adam's code? Or just make suggestions on the pull request itself? > LDAP auth fails when search results include an LDAP referral > > > Key: GUACAMOLE-243 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-243 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-ldap >Reporter: Adam Thorn > > The ldap search in > extensions/guacamole-auth-ldap/src/main/java/org/apache/guacamole/auth/ldap/user/UserService.java > to find the DN of the user who is logging in (i.e. inside getUserDNs() ) > fails if the LDAPSearchResults include an LDAP referral, because > LDAPSearchResults.next() throws an LDAPReferralException: > https://www.novell.com/documentation/developer/jldap/jldapenu/api/com/novell/ldap/LDAPSearchResults.html#next() > This particularly affects Active Directory, where typically the LDAP > implementation has separate partitions for DNS zones and Configuration (see > e.g. > http://stackoverflow.com/questions/32989159/ldapsearch-entire-active-directory-without-refldap-returns > for an example of the three LDAP referrals that AD returns). Empirically, > against my AD, even when an ldap search for (sAMAccountName=$USERNAME) > correctly returns the dn for the searched-for $USERNAME , I still also get > the three ldap referrals mentioned in that stackoverflow post. Thus, even > though the first result in the LDAPSearchResults has the correct dn for the > user logging in, results.next() then throws an exception when it encounters > the referral and the login fails. > This only happens when ldap-user-base-dn is set to the base dn of my AD (i.e. > with dc=example,dc=com I get referrals, but with ou=Users,dc=example,dc=com > as the search base I do not). The structure of my AD requires me to set the > base dn as the search base, though. > N.B. A possible workaround is to explicitly query the Global Catalog (by > setting ldap-port: 3268). However, that performs a forest-wide search rather > than just a domain-wide search, which might not be desired. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-243) LDAP auth fails when search results include an LDAP referral
[ https://issues.apache.org/jira/browse/GUACAMOLE-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15931335#comment-15931335 ] Nick Couchman commented on GUACAMOLE-243: - Thanks, Adam, but the other part of this is making sure I'm learning how to collaborate on a project like this. So, I forked your ignore-ldap-referrals branch (I think I did this the proper way??) and then made some modifications to that branch for enabling referrals and then dealing with cases where they fail when they should succeed. This route should preserve the previous commit history, as Mike suggested. My branch is here: https://github.com/necouchman/incubator-guacamole-client/tree/GUACAMOLE-243 If you want to take a look at that and see if it makes sense, maybe you can incorporate those changes into your branch, improve upon it if you see something that could use tweaking, and then we can merge the original PR? Mike and James, if you have other suggestions here, let us know. Sorry, again, everyone, for the mess made here - I definitely don't want to discourage others from contributing to this project, and am certainly not out to take credit for work others have done. > LDAP auth fails when search results include an LDAP referral > > > Key: GUACAMOLE-243 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-243 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-ldap >Reporter: Adam Thorn > > The ldap search in > extensions/guacamole-auth-ldap/src/main/java/org/apache/guacamole/auth/ldap/user/UserService.java > to find the DN of the user who is logging in (i.e. inside getUserDNs() ) > fails if the LDAPSearchResults include an LDAP referral, because > LDAPSearchResults.next() throws an LDAPReferralException: > https://www.novell.com/documentation/developer/jldap/jldapenu/api/com/novell/ldap/LDAPSearchResults.html#next() > This particularly affects Active Directory, where typically the LDAP > implementation has separate partitions for DNS zones and Configuration (see > e.g. > http://stackoverflow.com/questions/32989159/ldapsearch-entire-active-directory-without-refldap-returns > for an example of the three LDAP referrals that AD returns). Empirically, > against my AD, even when an ldap search for (sAMAccountName=$USERNAME) > correctly returns the dn for the searched-for $USERNAME , I still also get > the three ldap referrals mentioned in that stackoverflow post. Thus, even > though the first result in the LDAPSearchResults has the correct dn for the > user logging in, results.next() then throws an exception when it encounters > the referral and the login fails. > This only happens when ldap-user-base-dn is set to the base dn of my AD (i.e. > with dc=example,dc=com I get referrals, but with ou=Users,dc=example,dc=com > as the search base I do not). The structure of my AD requires me to set the > base dn as the search base, though. > N.B. A possible workaround is to explicitly query the Global Catalog (by > setting ldap-port: 3268). However, that performs a forest-wide search rather > than just a domain-wide search, which might not be desired. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-102) Load balancing based on resource
[
https://issues.apache.org/jira/browse/GUACAMOLE-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15931966#comment-15931966
]
Nick Couchman commented on GUACAMOLE-102:
-
So, I started working on implementing this within the JDBC authentication
module. Here's my current working tree:
https://github.com/necouchman/incubator-guacamole-client/tree/GUACAMOLE-102
My current progress just involves adding the weight field to the DB schema and
then getting it to show up in the connection settings interface. Have not done
the actual WRR algorithm, yet. Also, the current
Here are some notes and follow-up questions...
{quote}
Pretty much anything of the form "add a ___ which is ignored for all but ___"
makes me squirm.
{quote}
Okay, I get this...but this particular attribute is really only applicable if
you have a connection that is part of a balancing group. It won't be used on
individual connections, and won't be used in organizational groups. Maybe
"ignore" is the wrong word - it seems like adding this field to the JDBC module
and schema, but hiding it from admins when the current connection is not part
of a group of type BALANCING seems to be the least confusing to the user/admin.
{quote}
Connection attributes are the current mechanism for exposing arbitrary data.
That said, if this balancing mechanism will remain internal to the database
auth (as it is currently), then there is no need to expose the weight at all.
It could easily just exist within the database schema and the internal objects,
rather than at the API level.
{quote}
I went ahead and implemented this as a connection attribute. It currently
shows up in the "Concurrency Attributes" section...which kind of fits, although
I'm not sure that's a good long-term place. As far as exposing it or not, it
seems like you probably want this to be accessible via manual configuration
(which is what I've done thus far) - some people might want to manually set up
the weight used for given servers, while others will employ an automated method
of adjusting it.
{quote}
...Rearchitecting the webapp in that way would naturally involve exposing the
creation and balancing of connections at the REST level.
{quote}
I'm going to proceed with just trying to get this implemented in the JDBC
connection at this point. I'm just getting comfortable with the webapp and
REST stuff, and that seems like biting off a little more than I can chew at the
moment. If we go this route, eventually, maybe my work won't be a total waste
of time, but, if nothing else, it gets me a little more familiar with the code
and the relationship between the servlet and the AngularJS app...which is
something I've had an oddly hard time wrapping my mind around.
{quote}
A default of 1 seems wonky to me for a couple reasons...
{quote}
Definitely good points, here. Here's what I propose:
- Weight should be done with higher values equaling more preference - so, 1 is
less preferred than 100 which is less than 1000. The scale should be fairly
arbitrary to Guacamole - we don't care of the admin wants to use a scale of
1-100 or 1-1000 or 1000 to 2000, etc. - we just use higher numbers to indicate
preference. This should build in scalability - 5 nodes can be on a scale of
1-10, while 1000 can use a larger scale.
- Negative values should indicate problems with the server that cause it to be
ignored in scheduling. This would be valuable both for automated balancers,
that could fill in a negative value if the server is down, and also for
administrative purposes - you could use a negative number to manually disable a
server for maintenance. Furthermore, integrating this with an automated load
checking mechanism, you could use a couple of possible values to avoid admins
stepping on the balancer and vice-versa - so -1 can indicate the balancer
mechanism cannot reach the server and has disabled it; -2 can be
administratively disabled (and the load balancer will ignore that server), etc.
- 0 should be a server that is part of an automated load monitoring mechanism,
but has not been polled yet, and should not be used for connections, yet.
- null should be a server that's not part of a weighted connection and just
gets scheduled in a least-connection-first, which is essentially what the
current balancing mechanism does.
- Null or zero can be the default.
As far as monitoring goes, a few questions/comments here:
- Should the automated monitoring be something inside the Guacamole client, on
the servlet side? Maybe something similar to the way the check for expired
sessions currently works where there's an implementation of Runnable that polls
every so often? This would probably be fairly easy as I'm sure there's a Java
SNMP implementation available, and it would have pretty easy access via the
Java code to alter the database fields.
- Or, should the automated load
[jira] [Commented] (GUACAMOLE-102) Load balancing based on resource
[ https://issues.apache.org/jira/browse/GUACAMOLE-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932605#comment-15932605 ] Nick Couchman commented on GUACAMOLE-102: - Next up, let's talk algorithms Currently, looks like Guacamole uses a Least Connection algorithm in the balancing groups, despite my earlier assumptions and assertions that it was Round Robin. Moving from Least Connection to Weighted Least Connection is relatively easy from an implementation perspective and should be a good initial step in resource-based load balancing. So, a couple of larger questions open up here: - As we think about implementing load balancing, do we want to stick with a single algorithm, or implement several of them and allow them to be selected? The following common ones come to mind: Least Connection, Weighted Least Connection, Round Robin, Weighted Round Robin, Least Recently Used, and Weighted Least Recently Used. - At a higher level in dealing with load balancing, I believe active connections are currently not stored in the database (or wherever they are configured) and are completely in memory inside the Guacamole servlet. This definitely works at this point; however, as you think about scaling out a load balancer, and the possibility of HA or balanced Guacamole instances, it may be worthwhile to implement tracking of active connections inside the DB itself. This would allow you to point multiple instances of Guacamaole at a single database, but still be able to track how many total active connections you have to a given connection or connection group. - I believe currently in the JDBC connection, the connection history only gets updated when a connection ends. If we implement algorithms like LRU and WLRU, we'd need to have the initial population of the connection history happen upon connection, and then an update at the end of the connection, so that the (W)LRU algorithms work correctly. Obviously if we don't want to implement (W)LRU, this really isn't much of an issue. > Load balancing based on resource > > > Key: GUACAMOLE-102 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-102 > Project: Guacamole > Issue Type: New Feature > Components: guacamole, guacamole-auth-jdbc, > guacamole-auth-jdbc-mysql, guacamole-auth-jdbc-postgresql, guacamole-client, > RDP >Affects Versions: 0.9.10-incubating > Environment: CentOS Linux 7 (Core) > Linux 3.10.0-327.10.1.el7.x86_64 >Reporter: Werner Novak >Priority: Minor > > Implementation of an resource based (CPU, Memory, I/O, Loggedin User) > balancing in opposite to the current implemented guacamole connections round > robin. This is needed because of an large RDP infrastructure (300+ TS), where > the terminal server been accessed via multiple RDP load balancers during > migration. > A prototype has been developed in a guacamole fork > https://github.com/wnovak/incubator-guacamole-client.git -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-221) Parameter prompting within client interface
[
https://issues.apache.org/jira/browse/GUACAMOLE-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15935216#comment-15935216
]
Nick Couchman commented on GUACAMOLE-221:
-
Well, I'm taking a stab at implementing some form of parameter prompting. In
the past, in one of the duplicate issues, I had suggested using some sort of
token to handle this - something like ${GUAC_PROMPT} that would trigger a
prompt (maybe via a certain kind of exception?) to get these values. But...I'm
running into a couple of issues with that.
The simplest/obvious issue is that the parameter for port number is represented
on the web side as a numeric field and you cannot type "${GUAC_PROMPT}" into
that field. So, it might work for hostname/username/password, but probably
would not work for the port - and, while port might be the one you're least
likely to want to prompt for, someone is going to want it, and I can foresee
situations where it'd be useful (VNC connections are the most obvious, as VNC
lacks multi-user session control on a single port).
Next, I explored the option of adding a boolean field for prompting. From a
schema perspective this would be pretty easy to do:
- In the JDBC extension, add a field in the guacamole_connection_parameter
table called parameter_prompt, which defaults to false.
- In the simple file configuration, add a "prompt" attribute to the "param" tag
- In LDAP, add another multi-valued attribute called guacConfigPromptParameter
that could be used to find attributes that would be prompted for.
Unfortunately there are a couple of issues with this route. Probably the
biggest roadblock is that in a lot of places in the current code the parameters
are stored in some Map-type object with a key/value pair, and adding a second
value (boolean prompt) isn't necessarily trivial. In the file configuration
and LDAP cases this can be worked around by checking for the prompt attribute
and then setting the actual value to ${GUAC_PROMPT}, sort of combining this
method and the previous one; however, in the JDBC module it looks like values
are actually retrieved from the database in the Map way, so, again,
adding a third column to that to see whether or not to prompt for it isn't
necessarily the most straight-forward. I guess I could do something similar to
the way I was doing the LDAP code and have a separate query to the DB for
promptable columns that grabs the parameter name and the boolean prompt value,
and then loops through those and prompts, but that's a decent amount of work.
So, any thoughts/opinions/directions on where to go with this, from the
perspective of how to key parameters for prompting? I'm happy to (attempt to)
do the legwork, just don't want to do a ton of work and then end up going a
completely different direction.
Beyond that, I'm still struggling with how to inject the prompt into the stream
of making the connection. My thought was to kind of follow how the initial
Guacamole authentication handles challenges - throw a new exception of some
sort that triggers a form to be displayed with the field being prompted for. I
suppose I could do this and loop through until the ${GUAC_PROMPT} value isn't
found in any of the connection parameters, but is that even viable? Or is
there a simpler route to go to throw a prompt at the user, grab the info, and
then re-attempt the connection?
> Parameter prompting within client interface
> ---
>
> Key: GUACAMOLE-221
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-221
> Project: Guacamole
> Issue Type: New Feature
> Components: guacamole
>Reporter: Michael Jumper
>
> {panel:bgColor=#EE}
> *The description of this issue was copied from
> [GUAC-335|https://glyptodon.org/jira/browse/GUAC-335], an issue in the JIRA
> instance used by the Guacamole project prior to its acceptance into the
> Apache Incubator.*
> Comments, attachments, related issues, and history from prior to acceptance
> *have not been copied* and can be found instead at the original issue.
> {panel}
> Some parameters, such as the username/password for VNC or RDP, are better
> entered manually within the client when connecting rather than stored on the
> server in MySQL or {{user-mapping.xml}}.
> Storing secure data within parameters on the server side has security
> implications that don't fit well with all use cases.
> Further, some connections would benefit if their settings can be modified
> locally before connecting. A user could change the color depth or screen size
> of their RDP session, for example, for the sake of a slower connection.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-221) Parameter prompting within client interface
[
https://issues.apache.org/jira/browse/GUACAMOLE-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15935275#comment-15935275
]
Nick Couchman commented on GUACAMOLE-221:
-
Oh, and the other thing I forgot about that I'm running into with the
prompting, particularly trying to use ${GUAC_PROMPT} in the current token
setup. There's not really a good way to tell what type of data you're
prompting for. So, presumably if you're going to be prompting for a password
you want to use the password field (especially the part where it hides what
you're typing), and if you're going to be prompting for the port you want a
numeric field that enforces that the selection/input be numeric. Without
significant changes to the current token setup, this isn't really possible -
some minor changes would allow us to pass through the field name that's being
prompted for and make some determination based on that (if field name ==
password, use password field, if field name == port, use numeric field, else
use text field), but I'm not sure that's the cleanest way to go.
> Parameter prompting within client interface
> ---
>
> Key: GUACAMOLE-221
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-221
> Project: Guacamole
> Issue Type: New Feature
> Components: guacamole
>Reporter: Michael Jumper
>
> {panel:bgColor=#EE}
> *The description of this issue was copied from
> [GUAC-335|https://glyptodon.org/jira/browse/GUAC-335], an issue in the JIRA
> instance used by the Guacamole project prior to its acceptance into the
> Apache Incubator.*
> Comments, attachments, related issues, and history from prior to acceptance
> *have not been copied* and can be found instead at the original issue.
> {panel}
> Some parameters, such as the username/password for VNC or RDP, are better
> entered manually within the client when connecting rather than stored on the
> server in MySQL or {{user-mapping.xml}}.
> Storing secure data within parameters on the server side has security
> implications that don't fit well with all use cases.
> Further, some connections would benefit if their settings can be modified
> locally before connecting. A user could change the color depth or screen size
> of their RDP session, for example, for the sake of a slower connection.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (GUACAMOLE-248) Support for Inheriting Connection Parameters from Group
Nick Couchman created GUACAMOLE-248:
---
Summary: Support for Inheriting Connection Parameters from Group
Key: GUACAMOLE-248
URL: https://issues.apache.org/jira/browse/GUACAMOLE-248
Project: Guacamole
Issue Type: Improvement
Components: guacamole-client
Reporter: Nick Couchman
Priority: Minor
One of the things that might be nice to implement is the ability to define
certain parts of a connection at the group level and then have those be
inherited by the connections. The main scenario that comes to mind is that you
want to create a balancing group of (for example) 100 RDP servers. You'd like
all of the servers to use 3389 for the port and ${GUAC_USERNAME} and
${GUAC_PASSWORD} tokens for pass-through authentication from guacamole, and the
only thing that will be different about each of the connections is the hostname
or IP address to which they connect. The ability to define most of the
settings on the connection group (or, perhaps, a "template connection" of some
sort) and then allow child connections to inherit properties from either the
parent group or template would drastically reduce the administration in
creating at least 99 of those 100 connections.
Seems like this involves either defining parameters at the connection group
level, or creating a new "template" connection type that then connections could
link to. This also seems to be fairly strictly limited to the JDBC
authentication extension - probably not something you're going to try to do in
either LDAP or a simple file mechanism, and JDBC is the only area where
connection groups are supported, anyway.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-221) Parameter prompting within client interface
[
https://issues.apache.org/jira/browse/GUACAMOLE-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15936357#comment-15936357
]
Nick Couchman commented on GUACAMOLE-221:
-
{quote}
There may be user interface improvements that could solve that issue.
{quote}
I'm happy to try stuff out if there are suggestions...
{quote}
Parameter key/value pairs are exactly how parameters need to be represented, at
least at the core API level. Within strictly the web application and extension
subsystem, it's possible to augment this, but I'm not convinced it's necessary.
Making API changes should be the absolute last resort.
{quote}
Yeah, I didn't think changing this was the correct route to go, and seems like
a lot of work, anyway.
{quote}
The answer is: don't. You don't want to inject the prompt into the stream -
that would break the connection handling, muck with the 15 second timeout, etc.
It would be disastrous.
...
Yes! That's my thinking exactly. It's not possible (and shouldn't even be
attempted) to inject such prompting into the connection stream, but it can be
done by adding a step to the connection process.
{quote}
Sorry, I think I used the term "stream" in a way that made you think I was
saying something I wasn't saying. I wasn't saying to do the prompting after
the connection had been initiated, I just meant, when the user clicks on the
connection they want to launch, you check for the GUAC_PROMPT token, throw
exceptions when you need information, triggering forms to be displayed on the
Angular side, then substitute those values back in and *then* start the
connection stream (the actual stream) with the full parameter set.
{quote}
Currently, the tunnel is established immediately, and it's the tunnel which
receives additional connection information used by the handshake (screen size,
supported mimetypes, etc.).
{quote}
Kind of, although I think the current TokenFilter code runs before the actual
connnection starts, right? This is where other tokens are replaced with their
actual values, and I'm fairly certain that code runs on the servlet side before
the connection stream is actually established?
{quote}
Ah, but there is! See the JSON files in:
https://github.com/apache/incubator-guacamole-client/tree/3407586642f08cc9ffbe682fc8aa30a111fa0a66/guacamole-ext/src/main/resources/org/apache/guacamole/protocols
Those describe the structure and data types of the various parameters accepted
by each known protocol. These are all exposed via a REST service, and are used
by the interface when generating the connection parameter admin screen. The
same thing could be done for the parameter prompting - it would just be a
subset of those parameters.
...
You would definitely need to expose the field names being prompted, just as the
initial auth failure contains information describing the parameters required
for login. You should definitley not make assumptions based solely on parameter
name - the Guacamole protocol stipulates that these names are arbitrary. With
the parameter schema JSON, however, the meaning of each parameter for each
known protocol is available, and no assumptions need be made.
{quote}
Yeah, I had already figured out a way to expose the field names, so no issue
there, but, as you point out, I don't really want to key on the field name to
pick out the field type. However, with the JSON files and REST service, what's
the best way to link field being prompted for on the servlet side with what
gets picked up on the Angular side? I'm currently focusing my efforts on the
TokenFilter.filter() method. I've modified the function slightly to take the
field name as input (in addition to the field value/token name), and this
allows me to pass the field name in to the prompt, but the filter method is
called my the filterValues() method, and this only has K/V pairs that don't
necessarily have any real link back to the type of field being represented.
Or maybe I need to go somewhere else besides the TokenFilter code??
Thanks for the hints.
> Parameter prompting within client interface
> ---
>
> Key: GUACAMOLE-221
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-221
> Project: Guacamole
> Issue Type: New Feature
> Components: guacamole
>Reporter: Michael Jumper
>
> {panel:bgColor=#EE}
> *The description of this issue was copied from
> [GUAC-335|https://glyptodon.org/jira/browse/GUAC-335], an issue in the JIRA
> instance used by the Guacamole project prior to its acceptance into the
> Apache Incubator.*
> Comments, attachments, related issues, and history from prior to acceptance
> *have not been copied* and can be found instead at the original issue.
> {panel}
> Some parameters, such as the username/password for VNC or RDP, are better
> entered manually wi
[jira] [Commented] (GUACAMOLE-248) Support for Inheriting Connection Parameters from Group
[
https://issues.apache.org/jira/browse/GUACAMOLE-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15936416#comment-15936416
]
Nick Couchman commented on GUACAMOLE-248:
-
Sounds good. So, maybe similar to selecting the connection group into which a
connection goes, we could have a drop-down box for selecting a template
connection?
I'm guessing we want the batch administration discussion on the mailing lists,
and not just here in JIRA - user list, dev list, or both?
> Support for Inheriting Connection Parameters from Group
> ---
>
> Key: GUACAMOLE-248
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-248
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole-client
>Reporter: Nick Couchman
>Priority: Minor
>
> One of the things that might be nice to implement is the ability to define
> certain parts of a connection at the group level and then have those be
> inherited by the connections. The main scenario that comes to mind is that
> you want to create a balancing group of (for example) 100 RDP servers. You'd
> like all of the servers to use 3389 for the port and ${GUAC_USERNAME} and
> ${GUAC_PASSWORD} tokens for pass-through authentication from guacamole, and
> the only thing that will be different about each of the connections is the
> hostname or IP address to which they connect. The ability to define most of
> the settings on the connection group (or, perhaps, a "template connection" of
> some sort) and then allow child connections to inherit properties from either
> the parent group or template would drastically reduce the administration in
> creating at least 99 of those 100 connections.
> Seems like this involves either defining parameters at the connection group
> level, or creating a new "template" connection type that then connections
> could link to. This also seems to be fairly strictly limited to the JDBC
> authentication extension - probably not something you're going to try to do
> in either LDAP or a simple file mechanism, and JDBC is the only area where
> connection groups are supported, anyway.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (GUACAMOLE-102) Load balancing based on resource
[
https://issues.apache.org/jira/browse/GUACAMOLE-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15931966#comment-15931966
]
Nick Couchman edited comment on GUACAMOLE-102 at 3/23/17 3:52 PM:
--
So, I started working on implementing this within the JDBC authentication
module. Here's my current working tree:
https://github.com/necouchman/incubator-guacamole-client/tree/GUACAMOLE-102
My current progress just involves adding the weight field to the DB schema and
then getting it to show up in the connection settings interface. Have not done
the actual WRR algorithm, yet.
Here are some notes and follow-up questions...
{quote}
Pretty much anything of the form "add a ___ which is ignored for all but ___"
makes me squirm.
{quote}
Okay, I get this...but this particular attribute is really only applicable if
you have a connection that is part of a balancing group. It won't be used on
individual connections, and won't be used in organizational groups. Maybe
"ignore" is the wrong word - it seems like adding this field to the JDBC module
and schema, but hiding it from admins when the current connection is not part
of a group of type BALANCING seems to be the least confusing to the user/admin.
{quote}
Connection attributes are the current mechanism for exposing arbitrary data.
That said, if this balancing mechanism will remain internal to the database
auth (as it is currently), then there is no need to expose the weight at all.
It could easily just exist within the database schema and the internal objects,
rather than at the API level.
{quote}
I went ahead and implemented this as a connection attribute. It currently
shows up in the "Concurrency Attributes" section...which kind of fits, although
I'm not sure that's a good long-term place. As far as exposing it or not, it
seems like you probably want this to be accessible via manual configuration
(which is what I've done thus far) - some people might want to manually set up
the weight used for given servers, while others will employ an automated method
of adjusting it.
{quote}
...Rearchitecting the webapp in that way would naturally involve exposing the
creation and balancing of connections at the REST level.
{quote}
I'm going to proceed with just trying to get this implemented in the JDBC
connection at this point. I'm just getting comfortable with the webapp and
REST stuff, and that seems like biting off a little more than I can chew at the
moment. If we go this route, eventually, maybe my work won't be a total waste
of time, but, if nothing else, it gets me a little more familiar with the code
and the relationship between the servlet and the AngularJS app...which is
something I've had an oddly hard time wrapping my mind around.
{quote}
A default of 1 seems wonky to me for a couple reasons...
{quote}
Definitely good points, here. Here's what I propose:
- Weight should be done with higher values equaling more preference - so, 1 is
less preferred than 100 which is less than 1000. The scale should be fairly
arbitrary to Guacamole - we don't care of the admin wants to use a scale of
1-100 or 1-1000 or 1000 to 2000, etc. - we just use higher numbers to indicate
preference. This should build in scalability - 5 nodes can be on a scale of
1-10, while 1000 can use a larger scale.
- Negative values should indicate problems with the server that cause it to be
ignored in scheduling. This would be valuable both for automated balancers,
that could fill in a negative value if the server is down, and also for
administrative purposes - you could use a negative number to manually disable a
server for maintenance. Furthermore, integrating this with an automated load
checking mechanism, you could use a couple of possible values to avoid admins
stepping on the balancer and vice-versa - so -1 can indicate the balancer
mechanism cannot reach the server and has disabled it; -2 can be
administratively disabled (and the load balancer will ignore that server), etc.
- 0 should be a server that is part of an automated load monitoring mechanism,
but has not been polled yet, and should not be used for connections, yet.
- null should be a server that's not part of a weighted connection and just
gets scheduled in a least-connection-first, which is essentially what the
current balancing mechanism does.
- Null or zero can be the default.
As far as monitoring goes, a few questions/comments here:
- Should the automated monitoring be something inside the Guacamole client, on
the servlet side? Maybe something similar to the way the check for expired
sessions currently works where there's an implementation of Runnable that polls
every so often? This would probably be fairly easy as I'm sure there's a Java
SNMP implementation available, and it would have pretty easy access via the
Java code to alter the database fields.
- O
[jira] [Created] (GUACAMOLE-255) Support Ability to Auto-Start Connection
Nick Couchman created GUACAMOLE-255: --- Summary: Support Ability to Auto-Start Connection Key: GUACAMOLE-255 URL: https://issues.apache.org/jira/browse/GUACAMOLE-255 Project: Guacamole Issue Type: Bug Components: guacamole-client Affects Versions: 0.9.11-incubating Reporter: Nick Couchman Priority: Minor Currently the Guacamole client only automatically starts a connection when a single connection is defined for a user/login. It would be useful to set a connection to automatically start when a user logs in, even if multiple connections are available. The user should still be able to disconnect and return to the home screen, but there are certainly situations where it is desirable to have an automatic connection happen at login. As I see it there are two possible routes for implementing this: - Set up a connection parameter or attribute for auto-starting and have the client check connections at login time for the attribute and start them. - Set up a user-specific field for a connection to auto-start, and store the connection id (hash of datasource + id + type) in that field, and have the client check for that property at login and locate/start the specified connection. My preference would be to do this at the user level, for the following reasons: - You could then limit it to 1 auto-start per user, and avoid confusion of having multiple connections available to a user marked for auto-start and having to determine which one(s) you actually start. - The user can be in control of whether or not a connection is automatically started, and, if so, which one. There doesn't seem to be any security-relevant implications for allowing the user to control this - the necessary checks should still be in place to make sure the user is only starting a connection he has access to, and not injecting something bad into the field, but whether or not it starts automatically is more of an experience topic. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-255) Support Ability to Auto-Start Connection
[ https://issues.apache.org/jira/browse/GUACAMOLE-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15942103#comment-15942103 ] Nick Couchman commented on GUACAMOLE-255: - It's mostly a user experience sort of thing. I can think of a few situations - perhaps not overly concrete examples, but they work in my mind: - I use Guacamole every day, and 99% of the time I use one connection. I have 3-4 others defined, and use them occasionally, but my Windows VDI connection is by far the most-used connection. Auto-start seems perfect for that (even though it would only save me 1 click per login). - In a previous place of employment where we used Guacamole, we'd be pointing users (and not the sort with a high level of technical skill) toward a Guacamole web page and have them log in. We would tell them specifically to use a certain connection, and most of them would most of the time, but there would be that small few who couldn't follow instructions. There were other connections that some of them needed access to, but still would have been nice to just have it auto-start on the connection we wanted them to use most of the time, with the option that other folks could disconnection and choose a new connection if they needed to. - Lack of availability of a particular resource also seems like a valid use-case - you have a connection to which users are automatically connected, but, if that resource is unavailable for some reason, there are others they have permissions to that they could activate. I know those are a little on the weak side, and this definitely isn't a must-have, just seems like there could be scenarios where it's useful for a more seamless user experience. > Support Ability to Auto-Start Connection > > > Key: GUACAMOLE-255 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-255 > Project: Guacamole > Issue Type: Wish > Components: guacamole >Reporter: Nick Couchman >Priority: Trivial > > Currently the Guacamole client only automatically starts a connection when a > single connection is defined for a user/login. It would be useful to set a > connection to automatically start when a user logs in, even if multiple > connections are available. The user should still be able to disconnect and > return to the home screen, but there are certainly situations where it is > desirable to have an automatic connection happen at login. > As I see it there are two possible routes for implementing this: > - Set up a connection parameter or attribute for auto-starting and have the > client check connections at login time for the attribute and start them. > - Set up a user-specific field for a connection to auto-start, and store the > connection id (hash of datasource + id + type) in that field, and have the > client check for that property at login and locate/start the specified > connection. > My preference would be to do this at the user level, for the following > reasons: > - You could then limit it to 1 auto-start per user, and avoid confusion of > having multiple connections available to a user marked for auto-start and > having to determine which one(s) you actually start. > - The user can be in control of whether or not a connection is automatically > started, and, if so, which one. There doesn't seem to be any > security-relevant implications for allowing the user to control this - the > necessary checks should still be in place to make sure the user is only > starting a connection he has access to, and not injecting something bad into > the field, but whether or not it starts automatically is more of an > experience topic. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-255) Support Ability to Auto-Start Connection
[
https://issues.apache.org/jira/browse/GUACAMOLE-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15942245#comment-15942245
]
Nick Couchman commented on GUACAMOLE-255:
-
{quote}
E... Honestly, this feels more like feature creep to me.
Part of the idea behind ensuring connection URLs were deterministic was to
ensure they would be bookmarkable for this sort of case - where you
consistently want to access a specific connection, despite legitimately having
access to several others. Beyond that, if users are generally not supposed to
access a set of connections, then they really shouldn't be given such access.
{quote}
{quote}
I'd have to say that I agree with Michael Jumper on this one. If you want to
always access a certain connection, but still have access to others,
bookmarking (or sharing) the link for the desired connection seems to work just
fine. Adding another feature to do essentially the same thing does feel like
feature creep.
{quote}
Fair enough...I'll close the issue.
> Support Ability to Auto-Start Connection
>
>
> Key: GUACAMOLE-255
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-255
> Project: Guacamole
> Issue Type: Wish
> Components: guacamole
>Reporter: Nick Couchman
>Priority: Trivial
>
> Currently the Guacamole client only automatically starts a connection when a
> single connection is defined for a user/login. It would be useful to set a
> connection to automatically start when a user logs in, even if multiple
> connections are available. The user should still be able to disconnect and
> return to the home screen, but there are certainly situations where it is
> desirable to have an automatic connection happen at login.
> As I see it there are two possible routes for implementing this:
> - Set up a connection parameter or attribute for auto-starting and have the
> client check connections at login time for the attribute and start them.
> - Set up a user-specific field for a connection to auto-start, and store the
> connection id (hash of datasource + id + type) in that field, and have the
> client check for that property at login and locate/start the specified
> connection.
> My preference would be to do this at the user level, for the following
> reasons:
> - You could then limit it to 1 auto-start per user, and avoid confusion of
> having multiple connections available to a user marked for auto-start and
> having to determine which one(s) you actually start.
> - The user can be in control of whether or not a connection is automatically
> started, and, if so, which one. There doesn't seem to be any
> security-relevant implications for allowing the user to control this - the
> necessary checks should still be in place to make sure the user is only
> starting a connection he has access to, and not injecting something bad into
> the field, but whether or not it starts automatically is more of an
> experience topic.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (GUACAMOLE-255) Support Ability to Auto-Start Connection
[ https://issues.apache.org/jira/browse/GUACAMOLE-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman closed GUACAMOLE-255. --- Resolution: Won't Do Bookmarking seems to supplant the need for something like this. Closing out this request. > Support Ability to Auto-Start Connection > > > Key: GUACAMOLE-255 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-255 > Project: Guacamole > Issue Type: Wish > Components: guacamole >Reporter: Nick Couchman >Priority: Trivial > > Currently the Guacamole client only automatically starts a connection when a > single connection is defined for a user/login. It would be useful to set a > connection to automatically start when a user logs in, even if multiple > connections are available. The user should still be able to disconnect and > return to the home screen, but there are certainly situations where it is > desirable to have an automatic connection happen at login. > As I see it there are two possible routes for implementing this: > - Set up a connection parameter or attribute for auto-starting and have the > client check connections at login time for the attribute and start them. > - Set up a user-specific field for a connection to auto-start, and store the > connection id (hash of datasource + id + type) in that field, and have the > client check for that property at login and locate/start the specified > connection. > My preference would be to do this at the user level, for the following > reasons: > - You could then limit it to 1 auto-start per user, and avoid confusion of > having multiple connections available to a user marked for auto-start and > having to determine which one(s) you actually start. > - The user can be in control of whether or not a connection is automatically > started, and, if so, which one. There doesn't seem to be any > security-relevant implications for allowing the user to control this - the > necessary checks should still be in place to make sure the user is only > starting a connection he has access to, and not injecting something bad into > the field, but whether or not it starts automatically is more of an > experience topic. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-189) Add support for per-connection guacd
[ https://issues.apache.org/jira/browse/GUACAMOLE-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15953840#comment-15953840 ] Nick Couchman commented on GUACAMOLE-189: - This particular ticket doesn't necessarily deal with high availability or failing from one guacd server to another, just being able to assign a connection to a particular guacd instance, as might be necessary to overcome firewall issues and deal with distributed networks, and as is necessary for implementing the X.org driver. You're asking about two other things, which are probably good things to implement, but separate from this particular ticket and probably separate from each other: - Ability to load-balance or at least fail over from one guacd instance to another. guacd doesn't really care about where the client is getting its connection information (MySQL, PostgreSQL, LDAP, etc.), it just receives the Guacamole protocol information from the client and processes the translation of the Guacamole protocol to whatever back-end you're connecting to (SSH, RDP, etc.). - Ability to load-balance the Guacamole client and share sessions and configuration information between multiple instances of the client. This is likely already possible to some degree, although I'm not entirely sure how safe it is. There are some things that probably wouldn't work correctly - like tracking active connections - and some others that might be unsafe - like multiple admins editing the same connections. Anyway, probably worth opening a couple of separate tickets for these issues. > Add support for per-connection guacd > > > Key: GUACAMOLE-189 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-189 > Project: Guacamole > Issue Type: Improvement > Components: guacamole, guacamole-ext >Reporter: Michael Jumper >Assignee: Michael Jumper > Fix For: 0.9.13-incubating > > > The web application currently assumes that one guacd will be used to provide > access to all connections. This assumption fails if: > * Multiple guacd instances are spread out across different networks > * Another component implementing the Guacamole protocol is being used instead > of guacd on a per-connection basis (like the X.Org driver of GUACAMOLE-168) > Though no change is needed to the core APIs, as no such assumption is made at > that level, the web application and extension API should be modified such > that the guacd (or other Guacamole proxy) applicable to a connection can be > specified explicitly for that connection. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-263) Guacamole is not returning paged results of complete ldap user base DN
[ https://issues.apache.org/jira/browse/GUACAMOLE-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15961184#comment-15961184 ] Nick Couchman commented on GUACAMOLE-263: - Have you adjusted the ldap-max-search-results property in your guacamole.properties file to a value that pulls in all of your users? Also, if you clone from the github repo, the current development version has an ldap-user-search-filter property that allows you to filter out users in the LDAP query, so if your entire user base didn't need access to Guacamole you could limit the number of results returned. Does either of these address the issue you're running into? > Guacamole is not returning paged results of complete ldap user base DN > -- > > Key: GUACAMOLE-263 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-263 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-ldap >Affects Versions: 0.9.11-incubating > Environment: CentOS 7 > MariaDB 5.5.44 > Windows Server 2012 R2 Active Directory Domain Services >Reporter: M Goya > > My guacamole instance is integrated with Windows 2012 AD Domain Services. > LDAP authentication is working fine for all users. But I am unable to > administer the system properly because I am unable to query all users and > assign appropriate permissions in the web UI. My user base base DN is >1000 > objects. The application is not returning paged results of all objects and > is only showing the first 1000 objects. Any advice on a fix is much > appreciated. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-263) Guacamole is not returning paged results of complete ldap user base DN
[ https://issues.apache.org/jira/browse/GUACAMOLE-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15961423#comment-15961423 ] Nick Couchman commented on GUACAMOLE-263: - If you check out the master branch of https://github.com/apache/incubator-guacamole-client you should get the version that has the ldap-user-search-filter option. > Guacamole is not returning paged results of complete ldap user base DN > -- > > Key: GUACAMOLE-263 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-263 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-ldap >Affects Versions: 0.9.11-incubating > Environment: CentOS 7 > MariaDB 5.5.44 > Windows Server 2012 R2 Active Directory Domain Services >Reporter: M Goya > > My guacamole instance is integrated with Windows 2012 AD Domain Services. > LDAP authentication is working fine for all users. But I am unable to > administer the system properly because I am unable to query all users and > assign appropriate permissions in the web UI. My user base base DN is >1000 > objects. The application is not returning paged results of all objects and > is only showing the first 1000 objects. Any advice on a fix is much > appreciated. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-197) Implement Support for RADIUS Authentication
[
https://issues.apache.org/jira/browse/GUACAMOLE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15963267#comment-15963267
]
Nick Couchman commented on GUACAMOLE-197:
-
{quote}
It is possible to use this now? I just installed 0.9.12, and I have a RADIUS
server that I'd like to try using guac against. I'm a newb though, and don't
know how to install this. I have guac 0.9.12 running on Ubuntu.
{quote}
You're certainly welcome to check out the source code from my fork of the repo
and try it out:
https://github.com/necouchman/incubator-guacamole-client/tree/GUACAMOLE-197
There are some things to know about it:
-You have to build it yourself, there are no pre-compiled WARs/JARs for it,
and, actually, for this extension, probably never will be (due to some
licensing issues). Building is pretty easy - you need a Java compiler (Oracle
JDK, for example) and Maven, and then you just do "mvn package" - instructions
are in the main readme file.
- This particular branch of the incubator-guacamole-client tree lags behind the
Apache master by several commits (51), so there are probably some fixes and
functionality changes that you'd be missing.
- There's currently a bug that I need to fix for the build process to exclude
some JAR signatures. You currently have to work around it by removing two
files from the resulting JAR file: META-INF/BCKEY.SF and META-INF/BCKEY.DSA.
Also, since it hasn't been merged into the main code, yet, the documentation
also hasn't been updated. The config parameters are as follows:
radius-server
radius-auth-port
radius-acct-port
radius-shared-secret
radius-auth-protocol
radius-key-file
radius-key-type
radius-ca-file
radius-ca-type
radius-eap-ttls-inner-protocol
Feel free to let me know if you encounter any bugs.
> Implement Support for RADIUS Authentication
> ---
>
> Key: GUACAMOLE-197
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-197
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole, guacamole-client
>Reporter: Nick Couchman
>Priority: Minor
> Fix For: 0.9.13-incubating
>
>
> Working on implementing a RADIUS authentication module -
> guacamole-auth-radius. The basic implementation is completed - with a basic
> PAP or CHAP RADIUS server, the authentication succeeds and the user is logged
> in.
> I'm running into an issue, though, trying to implement Challenge/Response in
> RADIUS. I have my RADIUS server configured to talk to LinOTP for MFA/2FA,
> and RADIUS sends the AccessChallenge package back, asking for the second
> factor. My issue is in my continual failure to grasp the connection between
> the servlet side and the AngularJS web application. I've copied the Duo
> authentication code and tried to morph it into something that will present
> another box for the RADIUS challenge, but I can't get my controller function
> to actually fire.
> Once that is working, I'd like to support other RADIUS authentication
> protocols, like EAP-TLS and EAP-TTLS, so there's a little more work to be
> done, but right now I'm focusing on the basic protocols and the
> challenge/response.
> Will have a repo posted here in a moment for working on this.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-197) Implement Support for RADIUS Authentication
[
https://issues.apache.org/jira/browse/GUACAMOLE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15963273#comment-15963273
]
Nick Couchman commented on GUACAMOLE-197:
-
{quote}
There's currently a bug that I need to fix for the build process to exclude
some JAR signatures. You currently have to work around it by removing two files
from the resulting JAR file: META-INF/BCKEY.SF and META-INF/BCKEY.DSA.
{quote}
Just committed a change to fix this issue, so you should just be able to build
and use the resulting JAR file in your /etc/guacamole/extensions directory.
> Implement Support for RADIUS Authentication
> ---
>
> Key: GUACAMOLE-197
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-197
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole, guacamole-client
>Reporter: Nick Couchman
>Priority: Minor
> Fix For: 0.9.13-incubating
>
>
> Working on implementing a RADIUS authentication module -
> guacamole-auth-radius. The basic implementation is completed - with a basic
> PAP or CHAP RADIUS server, the authentication succeeds and the user is logged
> in.
> I'm running into an issue, though, trying to implement Challenge/Response in
> RADIUS. I have my RADIUS server configured to talk to LinOTP for MFA/2FA,
> and RADIUS sends the AccessChallenge package back, asking for the second
> factor. My issue is in my continual failure to grasp the connection between
> the servlet side and the AngularJS web application. I've copied the Duo
> authentication code and tried to morph it into something that will present
> another box for the RADIUS challenge, but I can't get my controller function
> to actually fire.
> Once that is working, I'd like to support other RADIUS authentication
> protocols, like EAP-TLS and EAP-TTLS, so there's a little more work to be
> done, but right now I'm focusing on the basic protocols and the
> challenge/response.
> Will have a repo posted here in a moment for working on this.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-197) Implement Support for RADIUS Authentication
[ https://issues.apache.org/jira/browse/GUACAMOLE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15967866#comment-15967866 ] Nick Couchman commented on GUACAMOLE-197: - Opened up LEGAL-299 to ask for legal guidance on including the source for this in the main Guacamole code. We'll see what they say... > Implement Support for RADIUS Authentication > --- > > Key: GUACAMOLE-197 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-197 > Project: Guacamole > Issue Type: Improvement > Components: guacamole, guacamole-client >Reporter: Nick Couchman >Priority: Minor > Fix For: 0.9.13-incubating > > > Working on implementing a RADIUS authentication module - > guacamole-auth-radius. The basic implementation is completed - with a basic > PAP or CHAP RADIUS server, the authentication succeeds and the user is logged > in. > I'm running into an issue, though, trying to implement Challenge/Response in > RADIUS. I have my RADIUS server configured to talk to LinOTP for MFA/2FA, > and RADIUS sends the AccessChallenge package back, asking for the second > factor. My issue is in my continual failure to grasp the connection between > the servlet side and the AngularJS web application. I've copied the Duo > authentication code and tried to morph it into something that will present > another box for the RADIUS challenge, but I can't get my controller function > to actually fire. > Once that is working, I'd like to support other RADIUS authentication > protocols, like EAP-TLS and EAP-TTLS, so there's a little more work to be > done, but right now I'm focusing on the basic protocols and the > challenge/response. > Will have a repo posted here in a moment for working on this. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-284) When using ldap with MySQL backend "Account Restrictions" doesn't work
[ https://issues.apache.org/jira/browse/GUACAMOLE-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16019817#comment-16019817 ] Nick Couchman commented on GUACAMOLE-284: - It sounds like maybe there's some confusion or missing information with how you have authentication set up. Do you have MySQL authentication only, or are you layering MySQL with LDAP? Based on your description it sounds like you're doing the later, and, the way authentication layering currently works in Guacamole, disabling the account will only disable authentication of the account via the database module, it won't actually block a login, as authentication will succeed via the LDAP module. When authentication succeeds, the user will be logged in, and then the user's permissions will be aggregated from other authentication sources that contain the same username. So, disabled, time restrictions, and account expiration settings inside the database modules will not impact logins that happen via another module when multiple modules are layered. > When using ldap with MySQL backend "Account Restrictions" doesn't work > -- > > Key: GUACAMOLE-284 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-284 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-jdbc-mysql, guacamole-auth-ldap, > guacamole-client >Affects Versions: 0.9.12-incubating >Reporter: Mark van den Boogaard > > When using LDAP authentication and a MySQL backend the options under "Account > Restrictions" are not working. > When we set the option "Disabled" or "Enable/Disable account after" this has > no effect. > For us the users who managing Guacamole (users and connections) do not have > access to LDAP to enable/disable accounts. So it would be nice to do have > these options working when using LDAP authentication with MySQL -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-284) When using ldap with MySQL backend "Account Restrictions" doesn't work
[ https://issues.apache.org/jira/browse/GUACAMOLE-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16021156#comment-16021156 ] Nick Couchman commented on GUACAMOLE-284: - > While it's true that account restrictions defined within the database auth > shouldn't affect whether another authentication mechanism succeeds/fails, I'd > say those restrictions should still take effect when it comes to providing > access to the data actually defined within the database. I agree. I was commenting on how it currently works, not, necessarily, on how it should work :-). However, the flip-side of this is making sure that it's understood how to properly secure database accounts in the above scenario, if necessary, to prevent accounts that may not have a password set on them from being exploited. That may already be taken care of in the Guacamole code - I did try to create a database user without a password and log in with it and it did not work, so this may not be a concern at all? Anyway, I agree that disabling the account in the DB module should result in the connection information for that user being inaccessible, even if another module succeeds. > When using ldap with MySQL backend "Account Restrictions" doesn't work > -- > > Key: GUACAMOLE-284 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-284 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-jdbc-mysql, guacamole-auth-ldap, > guacamole-client >Affects Versions: 0.9.12-incubating >Reporter: Mark van den Boogaard > > When using LDAP authentication and a MySQL backend the options under "Account > Restrictions" are not working. > When we set the option "Disabled" or "Enable/Disable account after" this has > no effect. > For us the users who managing Guacamole (users and connections) do not have > access to LDAP to enable/disable accounts. So it would be nice to do have > these options working when using LDAP authentication with MySQL -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (GUACAMOLE-284) When using ldap with MySQL backend "Account Restrictions" doesn't work
[
https://issues.apache.org/jira/browse/GUACAMOLE-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16021156#comment-16021156
]
Nick Couchman edited comment on GUACAMOLE-284 at 5/23/17 12:58 PM:
---
{quote}
While it's true that account restrictions defined within the database auth
shouldn't affect whether another authentication mechanism succeeds/fails, I'd
say those restrictions should still take effect when it comes to providing
access to the data actually defined within the database.
{quote}
I agree. I was commenting on how it currently works, not, necessarily, on how
it should work :-). However, the flip-side of this is making sure that it's
understood how to properly secure database accounts in the above scenario, if
necessary, to prevent accounts that may not have a password set on them from
being exploited. That may already be taken care of in the Guacamole code - I
did try to create a database user without a password and log in with it and it
did not work, so this may not be a concern at all? Anyway, I agree that
disabling the account in the DB module should result in the connection
information for that user being inaccessible, even if another module succeeds.
was (Author: nick.couch...@yahoo.com):
> While it's true that account restrictions defined within the database auth
> shouldn't affect whether another authentication mechanism succeeds/fails, I'd
> say those restrictions should still take effect when it comes to providing
> access to the data actually defined within the database.
I agree. I was commenting on how it currently works, not, necessarily, on how
it should work :-). However, the flip-side of this is making sure that it's
understood how to properly secure database accounts in the above scenario, if
necessary, to prevent accounts that may not have a password set on them from
being exploited. That may already be taken care of in the Guacamole code - I
did try to create a database user without a password and log in with it and it
did not work, so this may not be a concern at all? Anyway, I agree that
disabling the account in the DB module should result in the connection
information for that user being inaccessible, even if another module succeeds.
> When using ldap with MySQL backend "Account Restrictions" doesn't work
> --
>
> Key: GUACAMOLE-284
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-284
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-auth-jdbc-mysql, guacamole-auth-ldap,
> guacamole-client
>Affects Versions: 0.9.12-incubating
>Reporter: Mark van den Boogaard
>
> When using LDAP authentication and a MySQL backend the options under "Account
> Restrictions" are not working.
> When we set the option "Disabled" or "Enable/Disable account after" this has
> no effect.
> For us the users who managing Guacamole (users and connections) do not have
> access to LDAP to enable/disable accounts. So it would be nice to do have
> these options working when using LDAP authentication with MySQL
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-263) Guacamole is not returning paged results of complete ldap user base DN
[ https://issues.apache.org/jira/browse/GUACAMOLE-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16022826#comment-16022826 ] Nick Couchman commented on GUACAMOLE-263: - Any LDAP standard search filter should do - the syntax is exactly like on the page you mentioned. So, filtering for inetOrgPerson objects would be: (objectClass=inetOrgPerson) You can also do things like filter for objects with a certain attribute: (&(objectClass=inetOrgPerson)(mail=*)) The above would filter for any objects that have inetOrgPerson as the class and have any value present for the mail attribute. Probably more common things would be to filter on a group membership. In AD, that would look something like this: (|(memberOf=CN=Group1,OU=Groups,DC=example,DC=com)(memberOf=CN=Group2,OU=Groups,DC=example,DC=com)) The above would search for objects that are a member of either Group1 or Group2. Hope this helps. > Guacamole is not returning paged results of complete ldap user base DN > -- > > Key: GUACAMOLE-263 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-263 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-ldap >Affects Versions: 0.9.11-incubating > Environment: CentOS 7 > MariaDB 5.5.44 > Windows Server 2012 R2 Active Directory Domain Services >Reporter: M Goya > > My guacamole instance is integrated with Windows 2012 AD Domain Services. > LDAP authentication is working fine for all users. But I am unable to > administer the system properly because I am unable to query all users and > assign appropriate permissions in the web UI. My user base base DN is >1000 > objects. The application is not returning paged results of all objects and > is only showing the first 1000 objects. Any advice on a fix is much > appreciated. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-284) When using ldap with MySQL backend "Account Restrictions" doesn't work
[ https://issues.apache.org/jira/browse/GUACAMOLE-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16023109#comment-16023109 ] Nick Couchman commented on GUACAMOLE-284: - Cool. So simple solution to this seems to be to check for disabled/expired accounts in the methods that return configurations for the accounts, and just return empty or null if that's the case. Is that the route to go, or is there a more proper/elegant way you'd go about it? > When using ldap with MySQL backend "Account Restrictions" doesn't work > -- > > Key: GUACAMOLE-284 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-284 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-jdbc-mysql, guacamole-auth-ldap, > guacamole-client >Affects Versions: 0.9.12-incubating >Reporter: Mark van den Boogaard > > When using LDAP authentication and a MySQL backend the options under "Account > Restrictions" are not working. > When we set the option "Disabled" or "Enable/Disable account after" this has > no effect. > For us the users who managing Guacamole (users and connections) do not have > access to LDAP to enable/disable accounts. So it would be nice to do have > these options working when using LDAP authentication with MySQL -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-299) ldap paged results limited to 1000
[ https://issues.apache.org/jira/browse/GUACAMOLE-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16029572#comment-16029572 ] Nick Couchman commented on GUACAMOLE-299: - Isaac, Can you confirm that you've tried setting the ldap-max-search-results parameter in your guacamole.properties file to something larger than 1000? 1000 is the default limit for that parameter, so you need to increase it if you want to see all of the results. -Nick > ldap paged results limited to 1000 > -- > > Key: GUACAMOLE-299 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-299 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-ldap >Affects Versions: 0.9.12-incubating >Reporter: Isaac Marco Blancas > Attachments: Selección568.png > > > The guacamole/#/settings/users just find the first 1000 ldap people. When an > existing user is not located I can create a new user with his uid and he can > authenticate with no problems but this message captured in logs. > guacamole[16369]: 08:39:57.685 [http-nio-8080-exec-6] WARN > o.a.g.auth.ldap.user.UserService - Could not query list of all users for > attribute "uid": Error while querying users. > By other hand if I edit the user I can't see the MySQL and LDAP tabs... he is > not recognized as an LDAP user. See attachment. > Same problem has been reported with AD in the forum: > http://apache-guacamole-incubating-users.2363388.n4.nabble.com/Guacamole-and-Active-Directory-Paged-Results-td684.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-203) Implementing ServerAliveInterval to keep SSH session alive
[ https://issues.apache.org/jira/browse/GUACAMOLE-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031084#comment-16031084 ] Nick Couchman commented on GUACAMOLE-203: - I've taken a stab at an implementation of this. I'll have a PR open as soon as Github allows me to - it seems to be in a bit of a funk this morning. > Implementing ServerAliveInterval to keep SSH session alive > -- > > Key: GUACAMOLE-203 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-203 > Project: Guacamole > Issue Type: New Feature >Reporter: Mark van den Boogaard > > We connect to servers of customers to support an application. After about 30 > minutes of inactivity the session disconnects due to SSH configuration on the > remote host. As we don't have root access most of the time we cannot change > this behavior on the remote server. > On client-side it is possible to use the option "ServerAliveInterval" with a > "normal" SSH client to send every x seconds a "alive" packet. It would be > very helpful to implement this in Guacamole in case you don't have access to > change this on server-side. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-312) VNC over SSH
[
https://issues.apache.org/jira/browse/GUACAMOLE-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031324#comment-16031324
]
Nick Couchman commented on GUACAMOLE-312:
-
I guess one question/comment would be: is there any reason to keep this
specific to VNC, or does it make sense to allow any/all protocols to be
tunneled over SSH? VNC is definitely one that comes up commonly, as it lacks
built-in encryption, but I think it isn't too terribly uncommon that people
tunnel RDP over SSH, and with X.org support coming, I'm sure that will be one
that people also want to tunnel over SSH. Seems like making it available for
all protocols could be useful??
> VNC over SSH
>
>
> Key: GUACAMOLE-312
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-312
> Project: Guacamole
> Issue Type: New Feature
> Components: VNC
>Reporter: Michael Jumper
>Priority: Minor
>
> {panel:bgColor=#EE}
> *The description of this issue was copied from
> [GUAC-223|https://glyptodon.org/jira/browse/GUAC-223], an issue in the JIRA
> instance used by the Guacamole project prior to its acceptance into the
> Apache Incubator.*
> Comments, attachments, related issues, and history from prior to acceptance
> *have not been copied* and can be found instead at the original issue.
> {panel}
> It would be useful to provide access to VNC over SSH as an option.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-102) Load balancing based on resource
[ https://issues.apache.org/jira/browse/GUACAMOLE-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16032330#comment-16032330 ] Nick Couchman commented on GUACAMOLE-102: - Well, I went ahead and took a stab at an implementation of a WLC algorithm, here. PR 161 has been opened up in the incubator-guacamole-client repo for this change. I expect there are a LOT of things that need tweaking before that code actually gets merged, but it's a start. Maybe :-). Anyway, looking forward past the basic WLC implementation, there are a few things I'd like to do: - Implement multiple load balancing algorithms, as described earlier in this issue, and give the user control over which ones gets used. Should be able to basically pull out that compare() method into a separate class and then call whichever method is appropriate for the selected algorithm. - Still have to figure out the best way to dynamically update the connection weight and implement some default methods for that. At the moment the only real way to do this is to have something update the database directly...which may end up being an acceptable long-term route, but probably want some other options, too. > Load balancing based on resource > > > Key: GUACAMOLE-102 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-102 > Project: Guacamole > Issue Type: New Feature > Components: guacamole, guacamole-auth-jdbc, > guacamole-auth-jdbc-mysql, guacamole-auth-jdbc-postgresql, guacamole-client, > RDP >Affects Versions: 0.9.10-incubating > Environment: CentOS Linux 7 (Core) > Linux 3.10.0-327.10.1.el7.x86_64 >Reporter: Werner Novak >Priority: Minor > > Implementation of an resource based (CPU, Memory, I/O, Loggedin User) > balancing in opposite to the current implemented guacamole connections round > robin. This is needed because of an large RDP infrastructure (300+ TS), where > the terminal server been accessed via multiple RDP load balancers during > migration. > A prototype has been developed in a guacamole fork > https://github.com/wnovak/incubator-guacamole-client.git -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (GUACAMOLE-203) Implementing ServerAliveInterval to keep SSH session alive
[ https://issues.apache.org/jira/browse/GUACAMOLE-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman reassigned GUACAMOLE-203: --- Assignee: Nick Couchman > Implementing ServerAliveInterval to keep SSH session alive > -- > > Key: GUACAMOLE-203 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-203 > Project: Guacamole > Issue Type: New Feature >Reporter: Mark van den Boogaard >Assignee: Nick Couchman > > We connect to servers of customers to support an application. After about 30 > minutes of inactivity the session disconnects due to SSH configuration on the > remote host. As we don't have root access most of the time we cannot change > this behavior on the remote server. > On client-side it is possible to use the option "ServerAliveInterval" with a > "normal" SSH client to send every x seconds a "alive" packet. It would be > very helpful to implement this in Guacamole in case you don't have access to > change this on server-side. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (GUACAMOLE-102) Load balancing based on resource
[ https://issues.apache.org/jira/browse/GUACAMOLE-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman reassigned GUACAMOLE-102: --- Assignee: Nick Couchman > Load balancing based on resource > > > Key: GUACAMOLE-102 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-102 > Project: Guacamole > Issue Type: New Feature > Components: guacamole, guacamole-auth-jdbc, > guacamole-auth-jdbc-mysql, guacamole-auth-jdbc-postgresql, guacamole-client, > RDP >Affects Versions: 0.9.10-incubating > Environment: CentOS Linux 7 (Core) > Linux 3.10.0-327.10.1.el7.x86_64 >Reporter: Werner Novak >Assignee: Nick Couchman >Priority: Minor > > Implementation of an resource based (CPU, Memory, I/O, Loggedin User) > balancing in opposite to the current implemented guacamole connections round > robin. This is needed because of an large RDP infrastructure (300+ TS), where > the terminal server been accessed via multiple RDP load balancers during > migration. > A prototype has been developed in a guacamole fork > https://github.com/wnovak/incubator-guacamole-client.git -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (GUACAMOLE-197) Implement Support for RADIUS Authentication
[ https://issues.apache.org/jira/browse/GUACAMOLE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman reassigned GUACAMOLE-197: --- Assignee: Nick Couchman > Implement Support for RADIUS Authentication > --- > > Key: GUACAMOLE-197 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-197 > Project: Guacamole > Issue Type: Improvement > Components: guacamole, guacamole-client >Reporter: Nick Couchman >Assignee: Nick Couchman >Priority: Minor > Fix For: 0.9.14-incubating > > > Working on implementing a RADIUS authentication module - > guacamole-auth-radius. The basic implementation is completed - with a basic > PAP or CHAP RADIUS server, the authentication succeeds and the user is logged > in. > I'm running into an issue, though, trying to implement Challenge/Response in > RADIUS. I have my RADIUS server configured to talk to LinOTP for MFA/2FA, > and RADIUS sends the AccessChallenge package back, asking for the second > factor. My issue is in my continual failure to grasp the connection between > the servlet side and the AngularJS web application. I've copied the Duo > authentication code and tried to morph it into something that will present > another box for the RADIUS challenge, but I can't get my controller function > to actually fire. > Once that is working, I'd like to support other RADIUS authentication > protocols, like EAP-TLS and EAP-TTLS, so there's a little more work to be > done, but right now I'm focusing on the basic protocols and the > challenge/response. > Will have a repo posted here in a moment for working on this. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-234) Migrate from JLDAP to Apache Directory LDAP API
[ https://issues.apache.org/jira/browse/GUACAMOLE-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16035708#comment-16035708 ] Nick Couchman commented on GUACAMOLE-234: - Was glancing at this, and the Apache Directory LDAP API says it requires Java 7 or later. IIRC, Guacamole is built against JRE 6 compatibility - is this going to cause any problems trying to move to the this API? > Migrate from JLDAP to Apache Directory LDAP API > --- > > Key: GUACAMOLE-234 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-234 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-auth-ldap >Reporter: Michael Jumper >Priority: Minor > > The LDAP support currently uses [JLDAP|http://www.openldap.org/jldap/], but > that library has been unmaintained for several years now (no changes > whatsoever since 2009). Migrating away from such a library might be a good > idea. The Apache Directory project has produced an LDAP client API which > could serve as a replacement: > http://directory.apache.org/api/ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-314) Bump version numbers to 0.9.13-incubating
[ https://issues.apache.org/jira/browse/GUACAMOLE-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16036155#comment-16036155 ] Nick Couchman commented on GUACAMOLE-314: - Okay, all changes have been merged to staging, and staging has been merged to master. > Bump version numbers to 0.9.13-incubating > - > > Key: GUACAMOLE-314 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-314 > Project: Guacamole > Issue Type: Task > Components: Documentation, guacamole-client, guacamole-server >Reporter: Michael Jumper >Assignee: Michael Jumper > Fix For: 0.9.13-incubating > > > As [the scope of 0.9.13-incubating has been > finalized|https://lists.apache.org/thread.html/4dcdce2c5c7e60ac9d86257c83c8e787ab02d8c78a9b2a8f20994403@%3Cdev.guacamole.apache.org%3E], > and the release branches have been created, the version numbers of all > modified components need to be bumped to 0.9.13-incubating. > Only things which have actually changed should be bumped. This includes > component versions and, in the case of libguac, the SO version (libtool > version info, which must be incremented only according to [strict > guidelines|https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html]). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-197) Implement Support for RADIUS Authentication
[
https://issues.apache.org/jira/browse/GUACAMOLE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16037421#comment-16037421
]
Nick Couchman commented on GUACAMOLE-197:
-
{quote}
Hello, I love that Guacamole is including RADIUS auth. I routinely use OpenOTP
as a 2factor RADIUS server, and enabling Guacamole as a RADIUS client will make
it eminently more useful for my purposes.
{quote}
Glad to hear I'm not the only one interested in it.
{quote}
One additional feature I hope this project may consider adding is the ability
to filter which configuration a user has access to upon authentication. With
LDAP, Guacamole has the ability to provide a user access to a configuration
based on which LDAP group the user is a member of (see here
https://guacamole.incubator.apache.org/doc/0.9.3/gug/ldap-auth.html). This can
be done with RADIUS as well, but requires the RADIUS client implementation to
"look" at attributes that are returned by the RADIUS server.
{quote}
I have plans (in my head, anyway) to expand RADIUS support in Guacamole later
on for both authorization and accounting features, which I think would cover
what you're talking about, here. At the moment, this extension only does
authentication and relies on other stacked authentication modules to provide
the actual connection information. The feature that you're referencing in the
LDAP Authentication module works when the connections are stored in LDAP, and
the LDAP directory is used for both authentication and connection information.
If you layer LDAP with DB, you're left with the same challenge - the
connections in the DB layer must be managed apart from the directory tree.
I think there's also a JIRA issue opened at the moment to add group support to
the Guacamole client, which would also probably address the challenges, here -
I would image that would also resolve the challenge you're facing of having to
administer user/connection permissions on an individual basis. The combination
of the two - groups in Guacamole and an improved RADIUS module - is certainly
an ideal place to get.
If you're able to contribute code to the effort I'd welcome the contribution!
> Implement Support for RADIUS Authentication
> ---
>
> Key: GUACAMOLE-197
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-197
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole, guacamole-client
>Reporter: Nick Couchman
>Assignee: Nick Couchman
>Priority: Minor
> Fix For: 0.9.14-incubating
>
>
> Working on implementing a RADIUS authentication module -
> guacamole-auth-radius. The basic implementation is completed - with a basic
> PAP or CHAP RADIUS server, the authentication succeeds and the user is logged
> in.
> I'm running into an issue, though, trying to implement Challenge/Response in
> RADIUS. I have my RADIUS server configured to talk to LinOTP for MFA/2FA,
> and RADIUS sends the AccessChallenge package back, asking for the second
> factor. My issue is in my continual failure to grasp the connection between
> the servlet side and the AngularJS web application. I've copied the Duo
> authentication code and tried to morph it into something that will present
> another box for the RADIUS challenge, but I can't get my controller function
> to actually fire.
> Once that is working, I'd like to support other RADIUS authentication
> protocols, like EAP-TLS and EAP-TTLS, so there's a little more work to be
> done, but right now I'm focusing on the basic protocols and the
> challenge/response.
> Will have a repo posted here in a moment for working on this.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-272) Alternative to Duo
[ https://issues.apache.org/jira/browse/GUACAMOLE-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16038896#comment-16038896 ] Nick Couchman commented on GUACAMOLE-272: - So, my gut feeling here is that we could do a native 2FA authentication system, but I'd suggest *not* an e-mail- (or SMS-) based one. I would be more tempted to go with something like Google Authenticator with a rotating token. If you really want to do 2FA with e-mail or SMS, there's a RADIUS extension that should be available, soon, and you can use that plus RADIUS plus your favorite OTP implementation (LinOTP, OpenOTP) to do the e-mail or SMS-based authentication. There are a couple of Java libraries available for generating OTPs, we would just need to figure out the best place to implement it (bolt on to JDBC modules, separate module, etc.) and do the work. If you have any experience coding Java and want to jump in and help, we welcome the contributions! > Alternative to Duo > -- > > Key: GUACAMOLE-272 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-272 > Project: Guacamole > Issue Type: Improvement >Reporter: Chris Wheeler > > I love the fact that you support 2 factor authentication, but I am > disappointed it costs money when you have more than 10 users. I would like to > propose that you implement a simple native 2FA option. All you would need to > do is add a configurable email field for each user, and configurable SMTP > settings. When the user logs in, it would prompt for a pin, then send that > pin to their email address. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-210) OAuth2 authentication plugin
[
https://issues.apache.org/jira/browse/GUACAMOLE-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16038900#comment-16038900
]
Nick Couchman commented on GUACAMOLE-210:
-
I'll throw a suggestion out there - maybe it makes sense to combine all of
these requests into a single "SSO" module (guacamole-auth-sso)? SAML and
OAuth2 have been requested, and I implemented a CAS module, and I would guess
that there is going to be enough overlap that we could probably have a single
module responsible for all SSO-type functionality that then implements a
handful of different classes for the specific protocols. It would also allow
for easy expansion later on.
Thoughts?
> OAuth2 authentication plugin
>
>
> Key: GUACAMOLE-210
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-210
> Project: Guacamole
> Issue Type: New Feature
> Components: guacamole-client
>Reporter: Michael Jumper
>Assignee: Michael Jumper
>
> {panel:bgColor=#EE}
> *The description of this issue was copied from
> [GUAC-1485|https://glyptodon.org/jira/browse/GUAC-1485], an issue in the JIRA
> instance used by the Guacamole project prior to its acceptance into the
> Apache Incubator.*
> Comments, attachments, related issues, and history from prior to acceptance
> *have not been copied* and can be found instead at the original issue.
> {panel}
> It would be nice if Guacamole had OAuth2 authentication plugin.
> OAuth2 is wide spread in web technologies and Guacamole deserves to have its
> implementation of the protocol.
> My company had this use case and for now we are using a custom authentication
> plugin because implementing a generic OAuth2 compatible Guacamole
> authentication plugin presents some difficulties.
> h1. RedirectURI doesn't work because of Angular anchor system
> OAuth2 requires clients (Guacamole in our case) to register a redirect URI so
> that the OAuth2 server could callback the application when the user has been
> identify (or rejected) on its side. It also passes along some informations
> like tokens or reason of failure as part of the URL. If we set the Guacamole
> index URL as the redirect URI then this data never get passed along to the
> authenticate plugin.
> Such redirect URI cannot contain any pound sign (#) because this sign in a
> URI is a delimiter after which data are not sent to the server on HTTP
> request. In the case of Guacamole, the Angular frontend uses those local URI
> data to determine which page to display.
> Angular behavior cannot be easilly turned off and would lead to heaver code
> changes and uncompatibility with older browser.
> h1. Retrieve to connection list on authentication
> Connection list is retrieved at user login. It doesn't make sense to expect
> the OAuth server to give such list as it would not be generic enough.
> Fortunatly, connection lists get merged between authentication plugins and
> this OAuth plugin could be paired with another one which goal would just be
> to provide the connection list.
> h1. Token invalidation
> Upon a successful authentication, the OAuth2 server will issued an auth token.
> First, this token needs to be invalidated by Guacamole when user explicitly
> disconnects.
> Second, there is no way for Guacamole to know if a stored auth token is still
> valid. Leaving the user to freely keep on using its Guacamole session even
> thought the token has expired.
> I am just leaving these though here so the Guacamole community could start an
> discussion on this matter.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-210) OAuth2 authentication plugin
[
https://issues.apache.org/jira/browse/GUACAMOLE-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16039929#comment-16039929
]
Nick Couchman commented on GUACAMOLE-210:
-
That's fine - single extensions it is. Just thought I'd throw that out there
for discussion - I definitely see your points.
> OAuth2 authentication plugin
>
>
> Key: GUACAMOLE-210
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-210
> Project: Guacamole
> Issue Type: New Feature
> Components: guacamole-client
>Reporter: Michael Jumper
>Assignee: Michael Jumper
>
> {panel:bgColor=#EE}
> *The description of this issue was copied from
> [GUAC-1485|https://glyptodon.org/jira/browse/GUAC-1485], an issue in the JIRA
> instance used by the Guacamole project prior to its acceptance into the
> Apache Incubator.*
> Comments, attachments, related issues, and history from prior to acceptance
> *have not been copied* and can be found instead at the original issue.
> {panel}
> It would be nice if Guacamole had OAuth2 authentication plugin.
> OAuth2 is wide spread in web technologies and Guacamole deserves to have its
> implementation of the protocol.
> My company had this use case and for now we are using a custom authentication
> plugin because implementing a generic OAuth2 compatible Guacamole
> authentication plugin presents some difficulties.
> h1. RedirectURI doesn't work because of Angular anchor system
> OAuth2 requires clients (Guacamole in our case) to register a redirect URI so
> that the OAuth2 server could callback the application when the user has been
> identify (or rejected) on its side. It also passes along some informations
> like tokens or reason of failure as part of the URL. If we set the Guacamole
> index URL as the redirect URI then this data never get passed along to the
> authenticate plugin.
> Such redirect URI cannot contain any pound sign (#) because this sign in a
> URI is a delimiter after which data are not sent to the server on HTTP
> request. In the case of Guacamole, the Angular frontend uses those local URI
> data to determine which page to display.
> Angular behavior cannot be easilly turned off and would lead to heaver code
> changes and uncompatibility with older browser.
> h1. Retrieve to connection list on authentication
> Connection list is retrieved at user login. It doesn't make sense to expect
> the OAuth server to give such list as it would not be generic enough.
> Fortunatly, connection lists get merged between authentication plugins and
> this OAuth plugin could be paired with another one which goal would just be
> to provide the connection list.
> h1. Token invalidation
> Upon a successful authentication, the OAuth2 server will issued an auth token.
> First, this token needs to be invalidated by Guacamole when user explicitly
> disconnects.
> Second, there is no way for Guacamole to know if a stored auth token is still
> valid. Leaving the user to freely keep on using its Guacamole session even
> thought the token has expired.
> I am just leaving these though here so the Guacamole community could start an
> discussion on this matter.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-102) Load balancing based on resource
[ https://issues.apache.org/jira/browse/GUACAMOLE-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16039934#comment-16039934 ] Nick Couchman commented on GUACAMOLE-102: - So, initial commit has been made that at least begins the goal of this particular issue. Connections can now have a weight assigned to them, and, rather than being chosen via a Least Connection algorithm, are now chosen via a Weighted Least Connection algorithm. Next steps, I think, are: - Look at implementing additional algorithms - Round Robin and Weighted Round Robin shouldn't be too hard to do. I'm not entirely sure where the proper place is to start to break out the code for different LB algorithms - any thoughts? - Still have not settled on the best way for dynamically updating the weights of the individual connections. Does this live within the Guacamole Client code? Or is it a separate daemon or piece of code? Or maybe provide REST endpoints in the Guacamole Client code for updating the weights, but leave it up to the end user to implement the load checking/updating? Any opinions here? > Load balancing based on resource > > > Key: GUACAMOLE-102 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-102 > Project: Guacamole > Issue Type: New Feature > Components: guacamole, guacamole-auth-jdbc, > guacamole-auth-jdbc-mysql, guacamole-auth-jdbc-postgresql, guacamole-client, > RDP >Affects Versions: 0.9.10-incubating > Environment: CentOS Linux 7 (Core) > Linux 3.10.0-327.10.1.el7.x86_64 >Reporter: Werner Novak >Assignee: Nick Couchman >Priority: Minor > > Implementation of an resource based (CPU, Memory, I/O, Loggedin User) > balancing in opposite to the current implemented guacamole connections round > robin. This is needed because of an large RDP infrastructure (300+ TS), where > the terminal server been accessed via multiple RDP load balancers during > migration. > A prototype has been developed in a guacamole fork > https://github.com/wnovak/incubator-guacamole-client.git -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-102) Load balancing based on resource
[
https://issues.apache.org/jira/browse/GUACAMOLE-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16040926#comment-16040926
]
Nick Couchman commented on GUACAMOLE-102:
-
{quote}
I would say, as far as this issue is concerned, scope is satisfied. RR and WRR
sound like great ideas, but that should probably be a separate issue.
{quote}
Okay - I wasn't sure, since the original request was "implementation of
resource-based balancing" - which isn't entirely satisfied. The framework has
been created for this to happen with the addition of the weight field, but it
doesn't totally satisfy the request to implement resource-based balancing. If
the rest of the request is out of scope of the Guacamole Client, that's fine.
I'll submit a new issue and PR once I have RR AND WRR algorithms implemented so
we can add those.
{quote}
I think the only thing remaining here before this issue can be reasonably
closed is the documentation for the new column in the manual
(http://guacamole.incubator.apache.org/doc/gug/jdbc-auth.html#jdbc-auth-schema).
{quote}
Done, and PR submitted on the manual for that.
{quote}
I think the only way would be for the service measurement component to live
separately, in this case updating the connection weights in the database based
on some measurement of load.
{quote}
That makes the most sense to me, too - seems like adding it to the client
itself, though possible, is a little out of scope of the client.
{quote}
REST endpoints sound like a good option (and is possible now as of
GUACAMOLE-289), but that would need to be done carefully. You wouldn't want
unauthorized services/users to be able to update things.
{quote}
Yes, definitely need to make sure security is addressed. With the current API
is it possible to authenticate individual requests - like passing either
username/password in a header, or passing a digest or authorization header? Or
would that have to be implemented? Also, I was thinking about some sort of
additional permission added for updating the connection weight field such that
you could have a specific user identified inside the JDBC authentication
extension, that would authenticate directly to the API and then would have
permission to update that field and only that field?
> Load balancing based on resource
>
>
> Key: GUACAMOLE-102
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-102
> Project: Guacamole
> Issue Type: New Feature
> Components: guacamole, guacamole-auth-jdbc,
> guacamole-auth-jdbc-mysql, guacamole-auth-jdbc-postgresql, guacamole-client,
> RDP
>Affects Versions: 0.9.10-incubating
> Environment: CentOS Linux 7 (Core)
> Linux 3.10.0-327.10.1.el7.x86_64
>Reporter: Werner Novak
>Assignee: Nick Couchman
>Priority: Minor
>
> Implementation of an resource based (CPU, Memory, I/O, Loggedin User)
> balancing in opposite to the current implemented guacamole connections round
> robin. This is needed because of an large RDP infrastructure (300+ TS), where
> the terminal server been accessed via multiple RDP load balancers during
> migration.
> A prototype has been developed in a guacamole fork
> https://github.com/wnovak/incubator-guacamole-client.git
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-102) Load balancing based on resource
[
https://issues.apache.org/jira/browse/GUACAMOLE-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16041126#comment-16041126
]
Nick Couchman commented on GUACAMOLE-102:
-
The original request started out with:
{quote}
Implementation of an resource based (CPU, Memory, I/O, Loggedin User)...
{quote}
My take on this is that Werner was looking for the full resource-based load
balancing, which means, not only the ability to weight a connection, but also
the functionality for actually monitoring resources and dynamically updating
the weight of the connection based on the resource utilization. That's just my
ASS/U/M(E)ption based on the original request - Werner would have to jump in
and say exactly what he was looking for - maybe it does satisfy his request?
Werner, any input?
{quote}
Yes, REST resources will inherently require an authenticated Guacamole session
if they are exposed via UserContext.getResource().
{quote}
So, this, plus a permission specifically for updating connection weight should
do the trick, right?
> Load balancing based on resource
>
>
> Key: GUACAMOLE-102
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-102
> Project: Guacamole
> Issue Type: New Feature
> Components: guacamole, guacamole-auth-jdbc,
> guacamole-auth-jdbc-mysql, guacamole-auth-jdbc-postgresql, guacamole-client,
> RDP
>Affects Versions: 0.9.10-incubating
> Environment: CentOS Linux 7 (Core)
> Linux 3.10.0-327.10.1.el7.x86_64
>Reporter: Werner Novak
>Assignee: Nick Couchman
>Priority: Minor
>
> Implementation of an resource based (CPU, Memory, I/O, Loggedin User)
> balancing in opposite to the current implemented guacamole connections round
> robin. This is needed because of an large RDP infrastructure (300+ TS), where
> the terminal server been accessed via multiple RDP load balancers during
> migration.
> A prototype has been developed in a guacamole fork
> https://github.com/wnovak/incubator-guacamole-client.git
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (GUACAMOLE-102) Load balancing based on resource
[ https://issues.apache.org/jira/browse/GUACAMOLE-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16046797#comment-16046797 ] Nick Couchman commented on GUACAMOLE-102: - Werner, Thank you for the update. Are you good closing this issue? > Load balancing based on resource > > > Key: GUACAMOLE-102 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-102 > Project: Guacamole > Issue Type: New Feature > Components: guacamole, guacamole-auth-jdbc, > guacamole-auth-jdbc-mysql, guacamole-auth-jdbc-postgresql, guacamole-client, > RDP >Affects Versions: 0.9.10-incubating > Environment: CentOS Linux 7 (Core) > Linux 3.10.0-327.10.1.el7.x86_64 >Reporter: Werner Novak >Assignee: Nick Couchman >Priority: Minor > > Implementation of an resource based (CPU, Memory, I/O, Loggedin User) > balancing in opposite to the current implemented guacamole connections round > robin. This is needed because of an large RDP infrastructure (300+ TS), where > the terminal server been accessed via multiple RDP load balancers during > migration. > A prototype has been developed in a guacamole fork > https://github.com/wnovak/incubator-guacamole-client.git -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GUACAMOLE-102) Load balancing based on resource
[ https://issues.apache.org/jira/browse/GUACAMOLE-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16047943#comment-16047943 ] Nick Couchman commented on GUACAMOLE-102: - It did not make the 0.9.13 release in time, which should be out here, soon, but should be in the 0.9.14 release. > Load balancing based on resource > > > Key: GUACAMOLE-102 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-102 > Project: Guacamole > Issue Type: New Feature > Components: guacamole, guacamole-auth-jdbc, > guacamole-auth-jdbc-mysql, guacamole-auth-jdbc-postgresql, guacamole-client, > RDP >Affects Versions: 0.9.10-incubating > Environment: CentOS Linux 7 (Core) > Linux 3.10.0-327.10.1.el7.x86_64 >Reporter: Werner Novak >Assignee: Nick Couchman >Priority: Minor > > Implementation of an resource based (CPU, Memory, I/O, Loggedin User) > balancing in opposite to the current implemented guacamole connections round > robin. This is needed because of an large RDP infrastructure (300+ TS), where > the terminal server been accessed via multiple RDP load balancers during > migration. > A prototype has been developed in a guacamole fork > https://github.com/wnovak/incubator-guacamole-client.git -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (GUACAMOLE-322) Implement Additional Load Balancing Algorithms
Nick Couchman created GUACAMOLE-322: --- Summary: Implement Additional Load Balancing Algorithms Key: GUACAMOLE-322 URL: https://issues.apache.org/jira/browse/GUACAMOLE-322 Project: Guacamole Issue Type: Improvement Components: guacamole-client Affects Versions: 0.9.12-incubating Reporter: Nick Couchman Assignee: Nick Couchman Priority: Minor Now that the connection_weight field has been added, it makes sense to build out support for additional load balancing algorithms for the BALANCING connection group and allow users to choose which algorithm to use. Guacamole currently supports Weighted Least Connection (and Least Connection, when weights are undefined or are equal). I propose adding support for the following: - Round Robin - Weighted Round Robin - Least Recently Used - Weighted Least Recently Used For (Weighted) Round Robin, the plan would be to look at all the connections in a group, order them by their id, and then have a DB field keep track of either the last one used or the next one to use (opinions?). For (Weighted) Least Recently Used, it should be relatively easy to look at the connection history table and grab the oldest start_date field for a list of connections in the group, then calculate out from there. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (GUACAMOLE-323) Login screen appears during CAS redirect
[ https://issues.apache.org/jira/browse/GUACAMOLE-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman reassigned GUACAMOLE-323: --- Assignee: Nick Couchman > Login screen appears during CAS redirect > > > Key: GUACAMOLE-323 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-323 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-cas >Affects Versions: 0.9.13-incubating >Reporter: Michael Jumper >Assignee: Nick Couchman >Priority: Blocker > Fix For: 0.9.13-incubating > > > When using the new CAS authentication extension, the Guacamole login dialog > (with no login fields) briefly appears while the browser redirects to CAS > itself. This leads to a confusing user experience - the longer the dialog is > visible, the more the user will feel they should be interacting with > something, even though attempting to do so in this case will not have the > intended effect. > Some sort of feedback needs to be provided during the redirect process, so > the user is aware that they need to wait while they are redirected to CAS. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (GUACAMOLE-328) Documentation omits that libssl is required for ssh support
[
https://issues.apache.org/jira/browse/GUACAMOLE-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Couchman reassigned GUACAMOLE-328:
---
Assignee: Nick Couchman
> Documentation omits that libssl is required for ssh support
> ---
>
> Key: GUACAMOLE-328
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-328
> Project: Guacamole
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 0.9.12-incubating
> Environment: A minimal Ubuntu 16.04 image running in Docker
>Reporter: Anna Winters
>Assignee: Nick Couchman
>Priority: Trivial
> Labels: documentation
>
> Chapter 2 of the documentation, "Installing Guacamole natively", says the
> following with respect to building guacamole-server:
> {quote}SSH support depends on libssh2 and Pango (a font rendering and text
> layout library, used by Guacamole's built-in terminal emulator).{quote}
> However, running the ./configure script with libssh2 and pango installed
> gives the following output i.e. there will be no SSH support:
> {noformat}
>Library status:
> freerdp . no
> pango ... yes
> libavcodec .. no
> libavutil ... yes
> libssh2 . yes
> libssl .. no
> libswscale .. no
> libtelnet ... no
> libVNCServer yes
> libvorbis ... no
> libpulse no
> libwebp . yes
>Protocol support:
> RDP ... no
> SSH ... no
> Telnet no
> VNC ... yes
> {noformat}
> The README file does say that openssl is also required:
> {quote}
>
> Optional dependencies
>
> In addition, the following optional dependencies may be installed in order to
> enable optional features of Guacamole. Note that while the various supported
> protocols are technically optional, you will no doubt wish to install the
> dependencies of at least ONE supported protocol, as Guacamole would be useless
> otherwise.
> RDP:
> * FreeRDP (http://www.freerdp.com/)
> SSH:
> * libssh2 (http://www.libssh2.org/)
> * OpenSSL (https://www.openssl.org/)
> * Pango (http://www.pango.org/){quote}
> And the documentation itself says further down the page (in the libssl
> section)
> {quote}Without SSL support, there will be no option to encrypt communication
> to guacd, and support for SSH cannot be built.{quote}
> And it is correct, SSH support starts working with libssl installed:
> {noformat}
>Library status:
> freerdp . no
> pango ... yes
> libavcodec .. no
> libavutil ... yes
> libssh2 . yes
> libssl .. yes
> libswscale .. no
> libtelnet ... no
> libVNCServer yes
> libvorbis ... no
> libpulse no
> libwebp . yes
>Protocol support:
> RDP ... no
> SSH ... yes
> Telnet no
> VNC ... yes
> {noformat}
> The original text, which appears at the highest point in the page and in a
> bigger font, could be updated to also mention openssl, so others don't end up
> in the situation that I did (installing pango and libssh and wondering why
> SSH support wasn't being built).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GUACAMOLE-328) Documentation omits that libssl is required for ssh support
[
https://issues.apache.org/jira/browse/GUACAMOLE-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16052909#comment-16052909
]
Nick Couchman commented on GUACAMOLE-328:
-
Anna, I have opened a PR that adds OpenSSL to the libssh2 and Pango
requirements for SSH support. It's worth noting that, even in the current
Guacamole manual, if you look under the Optional Dependencies section, and the
OpenSSL item, it does mention there that it is required for SSH support.
> Documentation omits that libssl is required for ssh support
> ---
>
> Key: GUACAMOLE-328
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-328
> Project: Guacamole
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 0.9.12-incubating
> Environment: A minimal Ubuntu 16.04 image running in Docker
>Reporter: Anna Winters
>Assignee: Nick Couchman
>Priority: Trivial
> Labels: documentation
>
> Chapter 2 of the documentation, "Installing Guacamole natively", says the
> following with respect to building guacamole-server:
> {quote}SSH support depends on libssh2 and Pango (a font rendering and text
> layout library, used by Guacamole's built-in terminal emulator).{quote}
> However, running the ./configure script with libssh2 and pango installed
> gives the following output i.e. there will be no SSH support:
> {noformat}
>Library status:
> freerdp . no
> pango ... yes
> libavcodec .. no
> libavutil ... yes
> libssh2 . yes
> libssl .. no
> libswscale .. no
> libtelnet ... no
> libVNCServer yes
> libvorbis ... no
> libpulse no
> libwebp . yes
>Protocol support:
> RDP ... no
> SSH ... no
> Telnet no
> VNC ... yes
> {noformat}
> The README file does say that openssl is also required:
> {quote}
>
> Optional dependencies
>
> In addition, the following optional dependencies may be installed in order to
> enable optional features of Guacamole. Note that while the various supported
> protocols are technically optional, you will no doubt wish to install the
> dependencies of at least ONE supported protocol, as Guacamole would be useless
> otherwise.
> RDP:
> * FreeRDP (http://www.freerdp.com/)
> SSH:
> * libssh2 (http://www.libssh2.org/)
> * OpenSSL (https://www.openssl.org/)
> * Pango (http://www.pango.org/){quote}
> And the documentation itself says further down the page (in the libssl
> section)
> {quote}Without SSL support, there will be no option to encrypt communication
> to guacd, and support for SSH cannot be built.{quote}
> And it is correct, SSH support starts working with libssl installed:
> {noformat}
>Library status:
> freerdp . no
> pango ... yes
> libavcodec .. no
> libavutil ... yes
> libssh2 . yes
> libssl .. yes
> libswscale .. no
> libtelnet ... no
> libVNCServer yes
> libvorbis ... no
> libpulse no
> libwebp . yes
>Protocol support:
> RDP ... no
> SSH ... yes
> Telnet no
> VNC ... yes
> {noformat}
> The original text, which appears at the highest point in the page and in a
> bigger font, could be updated to also mention openssl, so others don't end up
> in the situation that I did (installing pango and libssh and wondering why
> SSH support wasn't being built).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GUACAMOLE-296) RDP audio input cause disconnection on Windows Server 2012 / 2016
[ https://issues.apache.org/jira/browse/GUACAMOLE-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16053970#comment-16053970 ] Nick Couchman commented on GUACAMOLE-296: - Marc, Question for you - could you please do "ldd -r /usr/lib/x86_64-linux-gnu/freerdp/guacai-client.so" and see what the output is? > RDP audio input cause disconnection on Windows Server 2012 / 2016 > - > > Key: GUACAMOLE-296 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-296 > Project: Guacamole > Issue Type: Bug > Components: guacamole >Affects Versions: 0.9.12-incubating >Reporter: Hisham > Labels: audio > > I know this problem was discussed in resolved thread, but it is a bit > different, please help me, I tried every thing I was able to find about the > topic. > On Windows Server 2012 R2: Audio playback works, but the minute I start > Sound settings in the "Recording" tab the connection gets disconnected > immediately. After that it is impossible to connect to the VM with guacamole, > because it keeps disconnecting immediately, the only why is using a RDP > client, and closing the Audio settings. > this are the log info: > May 8 10:19:27 ip-172-31-20-3 guacd[14887]: Loading keymap "base" > May 8 10:19:27 ip-172-31-20-3 guacd[14887]: Loading keymap "de-de-qwertz" > May 8 10:19:27 ip-172-31-20-3 guacd[14887]: guacsnd connected. > May 8 10:19:27 ip-172-31-20-3 guacd[14887]: guacdr connected. > May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Connected to RDPDR 1.12 as > client 0x0002 > May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Ignoring server capability set > type=0x0001, length=44 > May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Ignoring server capability set > type=0x0002, length=8 > May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Ignoring server capability set > type=0x0003, length=8 > May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Ignoring server capability set > type=0x0004, length=8 > May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Ignoring server capability set > type=0x0005, length=8 > May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Sending capabilities... > May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Capabilities sent. > May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Client ID confirmed > May 8 10:19:28 ip-172-31-20-3 guacd[14887]: User logged on > May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Sending filesystem > May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Registered device 0 (Guacamole > Filesystem) > May 8 10:19:28 ip-172-31-20-3 guacd[14887]: All supported devices sent. > May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Device 0 (Guacamole Filesystem) > connected successfully > May 8 10:19:37 ip-172-31-20-3 guacd[1183]: Connection > "$70610038-ba7e-4e1d-9103-1b870c0cb079" removed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GUACAMOLE-296) RDP audio input cause disconnection on Windows Server 2012 / 2016
[
https://issues.apache.org/jira/browse/GUACAMOLE-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054096#comment-16054096
]
Nick Couchman commented on GUACAMOLE-296:
-
Hisham,
{quote}
> What thread (or JIRA issue?) are you referring to?
https://issues.apache.org/jira/browse/GUACAMOLE-228
{quote}
That appears to be a different problem. It's related in that it involves audio
not working in Guacamole over RDP, but the symptoms described there are
different than those you're describing. Issue 228 doesn't say anything about
RDP connections being terminated when you try to click on the recording tab.
{quote}
It is a new installation on a new AWS EC2, I used the following script to
install:
https://www.chasewright.com/guacamole-with-mysql-on-ubuntu/
{quote}
Some more detail might be useful - like what version of FreeRDP is being
installed. And verify you're using it on the same platform as the web page
states (Ubuntu 16.04)? One-shot scripts like this can be useful, but they can
also make it more difficult to track down problems like this.
{quote}
PLEASE solve this problem!!
{quote}
It isn't really considered good etiquette to yell at the people trying to help
you :-). We are trying to help you resolve this issue, it's just not something
we're currently experiencing, so we have to try to gather additional details
(from you) about what's going on. Also, some of us do this as a hobby and
don't get paid for it, so the time we're able to spend on it competes with
other things in our lives - we can't always dedicate the time to it we'd like.
-Nick
> RDP audio input cause disconnection on Windows Server 2012 / 2016
> -
>
> Key: GUACAMOLE-296
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-296
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole
>Affects Versions: 0.9.12-incubating
>Reporter: Hisham
> Labels: audio
>
> I know this problem was discussed in resolved thread, but it is a bit
> different, please help me, I tried every thing I was able to find about the
> topic.
> On Windows Server 2012 R2: Audio playback works, but the minute I start
> Sound settings in the "Recording" tab the connection gets disconnected
> immediately. After that it is impossible to connect to the VM with guacamole,
> because it keeps disconnecting immediately, the only why is using a RDP
> client, and closing the Audio settings.
> this are the log info:
> May 8 10:19:27 ip-172-31-20-3 guacd[14887]: Loading keymap "base"
> May 8 10:19:27 ip-172-31-20-3 guacd[14887]: Loading keymap "de-de-qwertz"
> May 8 10:19:27 ip-172-31-20-3 guacd[14887]: guacsnd connected.
> May 8 10:19:27 ip-172-31-20-3 guacd[14887]: guacdr connected.
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Connected to RDPDR 1.12 as
> client 0x0002
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Ignoring server capability set
> type=0x0001, length=44
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Ignoring server capability set
> type=0x0002, length=8
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Ignoring server capability set
> type=0x0003, length=8
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Ignoring server capability set
> type=0x0004, length=8
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Ignoring server capability set
> type=0x0005, length=8
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Sending capabilities...
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Capabilities sent.
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Client ID confirmed
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: User logged on
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Sending filesystem
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Registered device 0 (Guacamole
> Filesystem)
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: All supported devices sent.
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Device 0 (Guacamole Filesystem)
> connected successfully
> May 8 10:19:37 ip-172-31-20-3 guacd[1183]: Connection
> "$70610038-ba7e-4e1d-9103-1b870c0cb079" removed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GUACAMOLE-296) RDP audio input cause disconnection on Windows Server 2012 / 2016
[
https://issues.apache.org/jira/browse/GUACAMOLE-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054277#comment-16054277
]
Nick Couchman commented on GUACAMOLE-296:
-
Looks like the Stream_New and Stream_Free symbols are exported in FreeRDP 1.1
from the libwinpr-utils file:
root@host:~/guacamole-server-0.9.12-incubating# nm -D
/usr/lib/x86_64-linux-gnu/libwinpr-utils.so.0.1.0 |grep Stream_New
6fb0 T Stream_New
root@host:~/guacamole-server-0.9.12-incubating# nm -D
/usr/lib/x86_64-linux-gnu/libwinpr-utils.so.0.1.0 |grep Stream_Free
7010 T Stream_Free
So maybe the guacai-client.so file needs to link against that file? A quick
change to the src/protocols/rdp/Makefile seems to resolve this issue. Around
line 715 should be guacai_ldflags=, and adding -lwinpr-utils to the end of the
last line (after -lfreerdp-codec) causes that library to be linked against the
libwinpr-utils shared library, which removes the error.
{code}
guacai_ldflags = \
-module -avoid-version -shared \
-lpthread \
-lfreerdp-core -lfreerdp-cache -lfreerdp-client -lfreerdp-utils
-lfreerdp-codec -lwinpr-utils
{code}
{code}
root@ussalxapps179t:~/guacamole-server-0.9.12-incubating# ldd -r
src/protocols/rdp/.libs/guacai-client.so
linux-vdso.so.1 => (0x7fff18b5a000)
libwinpr-utils.so.0.1 =>
/usr/lib/x86_64-linux-gnu/libwinpr-utils.so.0.1 (0x7ffaeb509000)
libguac.so.12 =>
/root/guacamole-server-0.9.12-incubating/src/libguac/.libs/libguac.so.12
(0x7ffaeb2f6000)
libcairo.so.2 => /usr/lib/x86_64-linux-gnu/libcairo.so.2
(0x7ffaeafe1000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7ffaeadc4000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7ffaea9fb000)
libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
(0x7ffaea5b6000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7ffaea2ad000)
libwinpr-synch.so.0.1 =>
/usr/lib/x86_64-linux-gnu/libwinpr-synch.so.0.1 (0x7ffaea0a7000)
libwinpr-sysinfo.so.0.1 =>
/usr/lib/x86_64-linux-gnu/libwinpr-sysinfo.so.0.1 (0x7ffae9ea3000)
libwinpr-crt.so.0.1 => /usr/lib/x86_64-linux-gnu/libwinpr-crt.so.0.1
(0x7ffae9c9e000)
libwinpr-handle.so.0.1 =>
/usr/lib/x86_64-linux-gnu/libwinpr-handle.so.0.1 (0x7ffae9a9c000)
libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8
(0x7ffae9842000)
libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0
(0x7ffae961d000)
libossp-uuid.so.16 => /usr/lib/x86_64-linux-gnu/libossp-uuid.so.16
(0x7ffae9411000)
libwebp.so.5 => /usr/lib/x86_64-linux-gnu/libwebp.so.5
(0x7ffae91b4000)
libpixman-1.so.0 => /usr/lib/x86_64-linux-gnu/libpixman-1.so.0
(0x7ffae8f0c000)
libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1
(0x7ffae8cc9000)
libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6
(0x7ffae8a1e000)
libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0
(0x7ffae881a000)
libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0
(0x7ffae861)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1
(0x7ffae83ed000)
libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1
(0x7ffae81e3000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6
(0x7ffae7ea9000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6
(0x7ffae7c96000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7ffae7a7c000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7ffae7874000)
/lib64/ld-linux-x86-64.so.2 (0x55c72197e000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7ffae766f000)
libwinpr-interlocked.so.0.1 =>
/usr/lib/x86_64-linux-gnu/libwinpr-interlocked.so.0.1 (0x7ffae746c000)
libwinpr-thread.so.0.1 =>
/usr/lib/x86_64-linux-gnu/libwinpr-thread.so.0.1 (0x7ffae7269000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1
(0x7ffae703f000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6
(0x7ffae6e3b000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6
(0x7ffae6c34000)
undefined symbol: guac_rdp_dvc_list_add
(src/protocols/rdp/.libs/guacai-client.so)
{code}
(Not sure what the other undefined symbol is...guac_rdp_dvc_list_add??).
[~meeheewee]: Can you try this change to the Makefile and then try the sound
input, again, and see if this resolves the issue?
> RDP audio input cause disconnection on Windows Server 2012 / 2016
> -
>
> Key: GUACAMOLE-296
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-296
> Project: Guacamole
> Issue Type: Bug
>
[jira] [Comment Edited] (GUACAMOLE-296) RDP audio input cause disconnection on Windows Server 2012 / 2016
[
https://issues.apache.org/jira/browse/GUACAMOLE-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054277#comment-16054277
]
Nick Couchman edited comment on GUACAMOLE-296 at 6/19/17 4:43 PM:
--
Looks like the Stream_New and Stream_Free symbols are exported in FreeRDP 1.1
from the libwinpr-utils file:
root@host:~/guacamole-server-0.9.12-incubating# nm -D
/usr/lib/x86_64-linux-gnu/libwinpr-utils.so.0.1.0 |grep Stream_New
6fb0 T Stream_New
root@host:~/guacamole-server-0.9.12-incubating# nm -D
/usr/lib/x86_64-linux-gnu/libwinpr-utils.so.0.1.0 |grep Stream_Free
7010 T Stream_Free
So maybe the guacai-client.so file needs to link against that file? A quick
change to the src/protocols/rdp/Makefile seems to resolve this issue. Around
line 715 should be guacai_ldflags=, and adding -lwinpr-utils to the end of the
last line (after -lfreerdp-codec) causes that library to be linked against the
libwinpr-utils shared library, which removes the error.
{code}
guacai_ldflags = \
-module -avoid-version -shared \
-lpthread \
-lfreerdp-core -lfreerdp-cache -lfreerdp-client -lfreerdp-utils
-lfreerdp-codec -lwinpr-utils
{code}
{code}
root@host:~/guacamole-server-0.9.12-incubating# ldd -r
src/protocols/rdp/.libs/guacai-client.so
linux-vdso.so.1 => (0x7fff18b5a000)
libwinpr-utils.so.0.1 =>
/usr/lib/x86_64-linux-gnu/libwinpr-utils.so.0.1 (0x7ffaeb509000)
libguac.so.12 =>
/root/guacamole-server-0.9.12-incubating/src/libguac/.libs/libguac.so.12
(0x7ffaeb2f6000)
libcairo.so.2 => /usr/lib/x86_64-linux-gnu/libcairo.so.2
(0x7ffaeafe1000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7ffaeadc4000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7ffaea9fb000)
libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
(0x7ffaea5b6000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7ffaea2ad000)
libwinpr-synch.so.0.1 =>
/usr/lib/x86_64-linux-gnu/libwinpr-synch.so.0.1 (0x7ffaea0a7000)
libwinpr-sysinfo.so.0.1 =>
/usr/lib/x86_64-linux-gnu/libwinpr-sysinfo.so.0.1 (0x7ffae9ea3000)
libwinpr-crt.so.0.1 => /usr/lib/x86_64-linux-gnu/libwinpr-crt.so.0.1
(0x7ffae9c9e000)
libwinpr-handle.so.0.1 =>
/usr/lib/x86_64-linux-gnu/libwinpr-handle.so.0.1 (0x7ffae9a9c000)
libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8
(0x7ffae9842000)
libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0
(0x7ffae961d000)
libossp-uuid.so.16 => /usr/lib/x86_64-linux-gnu/libossp-uuid.so.16
(0x7ffae9411000)
libwebp.so.5 => /usr/lib/x86_64-linux-gnu/libwebp.so.5
(0x7ffae91b4000)
libpixman-1.so.0 => /usr/lib/x86_64-linux-gnu/libpixman-1.so.0
(0x7ffae8f0c000)
libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1
(0x7ffae8cc9000)
libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6
(0x7ffae8a1e000)
libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0
(0x7ffae881a000)
libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0
(0x7ffae861)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1
(0x7ffae83ed000)
libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1
(0x7ffae81e3000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6
(0x7ffae7ea9000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6
(0x7ffae7c96000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7ffae7a7c000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7ffae7874000)
/lib64/ld-linux-x86-64.so.2 (0x55c72197e000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7ffae766f000)
libwinpr-interlocked.so.0.1 =>
/usr/lib/x86_64-linux-gnu/libwinpr-interlocked.so.0.1 (0x7ffae746c000)
libwinpr-thread.so.0.1 =>
/usr/lib/x86_64-linux-gnu/libwinpr-thread.so.0.1 (0x7ffae7269000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1
(0x7ffae703f000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6
(0x7ffae6e3b000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6
(0x7ffae6c34000)
undefined symbol: guac_rdp_dvc_list_add
(src/protocols/rdp/.libs/guacai-client.so)
{code}
(Not sure what the other undefined symbol is...guac_rdp_dvc_list_add??).
[~meeheewee]: Can you try this change to the Makefile and then try the sound
input, again, and see if this resolves the issue?
was (Author: nick.couch...@yahoo.com):
Looks like the Stream_New and Stream_Free symbols are exported in FreeRDP 1.1
from the libwinpr-utils file:
root@host:~/guacamole-server-0.9.12-incubating# nm -D
/usr/lib/x86_64-linux-gnu/libwinpr-utils.so.0.1.0 |grep Stream_New
[jira] [Resolved] (GUACAMOLE-328) Documentation omits that libssl is required for ssh support
[
https://issues.apache.org/jira/browse/GUACAMOLE-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Couchman resolved GUACAMOLE-328.
-
Resolution: Fixed
Fix Version/s: 0.9.14-incubating
Updated language in manual to reflect this requirement.
> Documentation omits that libssl is required for ssh support
> ---
>
> Key: GUACAMOLE-328
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-328
> Project: Guacamole
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 0.9.12-incubating
> Environment: A minimal Ubuntu 16.04 image running in Docker
>Reporter: Anna Winters
>Assignee: Nick Couchman
>Priority: Trivial
> Labels: documentation
> Fix For: 0.9.14-incubating
>
>
> Chapter 2 of the documentation, "Installing Guacamole natively", says the
> following with respect to building guacamole-server:
> {quote}SSH support depends on libssh2 and Pango (a font rendering and text
> layout library, used by Guacamole's built-in terminal emulator).{quote}
> However, running the ./configure script with libssh2 and pango installed
> gives the following output i.e. there will be no SSH support:
> {noformat}
>Library status:
> freerdp . no
> pango ... yes
> libavcodec .. no
> libavutil ... yes
> libssh2 . yes
> libssl .. no
> libswscale .. no
> libtelnet ... no
> libVNCServer yes
> libvorbis ... no
> libpulse no
> libwebp . yes
>Protocol support:
> RDP ... no
> SSH ... no
> Telnet no
> VNC ... yes
> {noformat}
> The README file does say that openssl is also required:
> {quote}
>
> Optional dependencies
>
> In addition, the following optional dependencies may be installed in order to
> enable optional features of Guacamole. Note that while the various supported
> protocols are technically optional, you will no doubt wish to install the
> dependencies of at least ONE supported protocol, as Guacamole would be useless
> otherwise.
> RDP:
> * FreeRDP (http://www.freerdp.com/)
> SSH:
> * libssh2 (http://www.libssh2.org/)
> * OpenSSL (https://www.openssl.org/)
> * Pango (http://www.pango.org/){quote}
> And the documentation itself says further down the page (in the libssl
> section)
> {quote}Without SSL support, there will be no option to encrypt communication
> to guacd, and support for SSH cannot be built.{quote}
> And it is correct, SSH support starts working with libssl installed:
> {noformat}
>Library status:
> freerdp . no
> pango ... yes
> libavcodec .. no
> libavutil ... yes
> libssh2 . yes
> libssl .. yes
> libswscale .. no
> libtelnet ... no
> libVNCServer yes
> libvorbis ... no
> libpulse no
> libwebp . yes
>Protocol support:
> RDP ... no
> SSH ... yes
> Telnet no
> VNC ... yes
> {noformat}
> The original text, which appears at the highest point in the page and in a
> bigger font, could be updated to also mention openssl, so others don't end up
> in the situation that I did (installing pango and libssh and wondering why
> SSH support wasn't being built).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GUACAMOLE-331) Extremely slow download/upload over http tunnel
[
https://issues.apache.org/jira/browse/GUACAMOLE-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16056317#comment-16056317
]
Nick Couchman commented on GUACAMOLE-331:
-
Okay, a couple of questions for you:
- You say there is no such problem in the official Guacamole client, which
leverages the same guacamole-common and guacamole-common-js code as you're
using for the custom client, so why do you say this is a major bug in the
guacamole-common code? Seems if it's working fine in the official client, the
common code is probably okay??
- Can you provide some further specifications on testing, particularly
differences between the custom code and the official client? You say Ubuntu
16.04 for the custom code, and Fedora 25 for the guacd instances, but were you
running the official guacamole client on Fedora 25? Or did you install that
into Ubuntu 16.04? Were both the custom client and the official client pointed
at the same guacd instances in both cases?
- What browser(s) did you test, on what platforms, and was the slow speed
observation the same across all browsers/platforms you tested on the client?
-Nick
> Extremely slow download/upload over http tunnel
> ---
>
> Key: GUACAMOLE-331
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-331
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-common, guacamole-common-js
>Affects Versions: 0.9.12-incubating
> Environment: Ubuntu 16.04 (custom guacamole client), Fedora 25 (guacd
> instances in lxd containers)
>Reporter: Josef Krahujec
> Labels: documentation-update, http-tunneling, input-stream
>
> Downloading/uploading files over http tunnel is extremely slow (200 kB/s
> maximum), even though we are present in local network. Here is source code
> for downloading files:
> {code:JavaScript}
> $(".management table").on("click", ".fs-file", function(){
> var that = this;
> var filename = $(".management tbody").children().eq(that.rowIndex -
> 1).find(".name").html();
> var requestFile = $("#path").html() + filename;
> if ($.inArray(requestFile, window.downloading) != -1)
> return false;
> $(".management tbody").children().eq(that.rowIndex -
> 1).children().eq(1).addClass("downloading");
> window.downloading.push(requestFile);
> window.fs.obj.requestInputStream(requestFile, function(stream,
> mimetype){
> stream.sendAck("Ready", Guacamole.Status.Code.SUCCESS);
> var reader = new Guacamole.BlobReader(stream, mimetype);
> removeSearch();
> reader.onend = function(){
> var blob = reader.getBlob();
> blobDownload(blob, filename, requestFile);
> }
> });
> });
> {code}
> We have also tried the official guacamole client, however there appeared to
> be no such problem.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GUACAMOLE-296) RDP audio input cause disconnection on Windows Server 2012 / 2016
[
https://issues.apache.org/jira/browse/GUACAMOLE-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060630#comment-16060630
]
Nick Couchman commented on GUACAMOLE-296:
-
{quote}
Is it possible to fix it that the build will have the fix?
{quote}
One of the future builds will. I need to see if I can figure out how to
properly change all of the Makefile infrastructure for that, or if I'll need
[~mike.jumper]'s help for this one. The main thing I'm concerned about is
properly detected when this is required (FreeRDP 1.1 and later) so that it
doesn't cause problems with the build for earlier versions of FreeRDP.
> RDP audio input cause disconnection on Windows Server 2012 / 2016
> -
>
> Key: GUACAMOLE-296
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-296
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole
>Affects Versions: 0.9.12-incubating
>Reporter: Hisham
> Labels: audio
>
> I know this problem was discussed in resolved thread, but it is a bit
> different, please help me, I tried every thing I was able to find about the
> topic.
> On Windows Server 2012 R2: Audio playback works, but the minute I start
> Sound settings in the "Recording" tab the connection gets disconnected
> immediately. After that it is impossible to connect to the VM with guacamole,
> because it keeps disconnecting immediately, the only why is using a RDP
> client, and closing the Audio settings.
> this are the log info:
> May 8 10:19:27 ip-172-31-20-3 guacd[14887]: Loading keymap "base"
> May 8 10:19:27 ip-172-31-20-3 guacd[14887]: Loading keymap "de-de-qwertz"
> May 8 10:19:27 ip-172-31-20-3 guacd[14887]: guacsnd connected.
> May 8 10:19:27 ip-172-31-20-3 guacd[14887]: guacdr connected.
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Connected to RDPDR 1.12 as
> client 0x0002
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Ignoring server capability set
> type=0x0001, length=44
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Ignoring server capability set
> type=0x0002, length=8
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Ignoring server capability set
> type=0x0003, length=8
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Ignoring server capability set
> type=0x0004, length=8
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Ignoring server capability set
> type=0x0005, length=8
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Sending capabilities...
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Capabilities sent.
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Client ID confirmed
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: User logged on
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Sending filesystem
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Registered device 0 (Guacamole
> Filesystem)
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: All supported devices sent.
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Device 0 (Guacamole Filesystem)
> connected successfully
> May 8 10:19:37 ip-172-31-20-3 guacd[1183]: Connection
> "$70610038-ba7e-4e1d-9103-1b870c0cb079" removed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GUACAMOLE-299) ldap paged results limited to 1000
[ https://issues.apache.org/jira/browse/GUACAMOLE-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16062408#comment-16062408 ] Nick Couchman commented on GUACAMOLE-299: - [~isaac.marco]: Any update on this? Have you set the ldap-max-search-results parameter in guacamole.properties? > ldap paged results limited to 1000 > -- > > Key: GUACAMOLE-299 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-299 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-ldap >Affects Versions: 0.9.12-incubating >Reporter: Isaac Marco Blancas > Attachments: Selección568.png > > > The guacamole/#/settings/users just find the first 1000 ldap people. When an > existing user is not located I can create a new user with his uid and he can > authenticate with no problems but this message captured in logs. > guacamole[16369]: 08:39:57.685 [http-nio-8080-exec-6] WARN > o.a.g.auth.ldap.user.UserService - Could not query list of all users for > attribute "uid": Error while querying users. > By other hand if I edit the user I can't see the MySQL and LDAP tabs... he is > not recognized as an LDAP user. See attachment. > Same problem has been reported with AD in the forum: > http://apache-guacamole-incubating-users.2363388.n4.nabble.com/Guacamole-and-Active-Directory-Paged-Results-td684.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GUACAMOLE-263) Guacamole is not returning paged results of complete ldap user base DN
[ https://issues.apache.org/jira/browse/GUACAMOLE-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16062409#comment-16062409 ] Nick Couchman commented on GUACAMOLE-263: - [~mgoya] Were you able to try the development version - build the master branch from the git repo? Also, 0.9.13-incubating should be out, shortly. > Guacamole is not returning paged results of complete ldap user base DN > -- > > Key: GUACAMOLE-263 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-263 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-ldap >Affects Versions: 0.9.11-incubating > Environment: CentOS 7 > MariaDB 5.5.44 > Windows Server 2012 R2 Active Directory Domain Services >Reporter: M Goya > > My guacamole instance is integrated with Windows 2012 AD Domain Services. > LDAP authentication is working fine for all users. But I am unable to > administer the system properly because I am unable to query all users and > assign appropriate permissions in the web UI. My user base base DN is >1000 > objects. The application is not returning paged results of all objects and > is only showing the first 1000 objects. Any advice on a fix is much > appreciated. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GUACAMOLE-102) Load balancing based on resource
[ https://issues.apache.org/jira/browse/GUACAMOLE-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman updated GUACAMOLE-102: Fix Version/s: 0.9.14-incubating > Load balancing based on resource > > > Key: GUACAMOLE-102 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-102 > Project: Guacamole > Issue Type: New Feature > Components: guacamole, guacamole-auth-jdbc, > guacamole-auth-jdbc-mysql, guacamole-auth-jdbc-postgresql, guacamole-client, > RDP >Affects Versions: 0.9.10-incubating > Environment: CentOS Linux 7 (Core) > Linux 3.10.0-327.10.1.el7.x86_64 >Reporter: Werner Novak >Assignee: Nick Couchman >Priority: Minor > Fix For: 0.9.14-incubating > > > Implementation of an resource based (CPU, Memory, I/O, Loggedin User) > balancing in opposite to the current implemented guacamole connections round > robin. This is needed because of an large RDP infrastructure (300+ TS), where > the terminal server been accessed via multiple RDP load balancers during > migration. > A prototype has been developed in a guacamole fork > https://github.com/wnovak/incubator-guacamole-client.git -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GUACAMOLE-203) Implementing ServerAliveInterval to keep SSH session alive
[ https://issues.apache.org/jira/browse/GUACAMOLE-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman updated GUACAMOLE-203: Affects Version/s: 0.9.12-incubating Fix Version/s: 0.9.14-incubating > Implementing ServerAliveInterval to keep SSH session alive > -- > > Key: GUACAMOLE-203 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-203 > Project: Guacamole > Issue Type: New Feature >Affects Versions: 0.9.12-incubating >Reporter: Mark van den Boogaard >Assignee: Nick Couchman > Fix For: 0.9.14-incubating > > > We connect to servers of customers to support an application. After about 30 > minutes of inactivity the session disconnects due to SSH configuration on the > remote host. As we don't have root access most of the time we cannot change > this behavior on the remote server. > On client-side it is possible to use the option "ServerAliveInterval" with a > "normal" SSH client to send every x seconds a "alive" packet. It would be > very helpful to implement this in Guacamole in case you don't have access to > change this on server-side. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
