Re: Guacamole Upgrade from 1.2 to 1.4

[Tushar Jain]

Thanks for the inputs.On 19-May-2022 4:54 am, Michael Jumper  wrote:On Thu, May 12, 2022 at 6:23 AM Tushar Jain  wrote:








Hi,
 
I am planning to upgrade guacamole from 1.2 to 1.4. Is it okay to download the server and client files from
https://guacamole.apache.org/releases/1.4.0/ or should I take the latest for both from github ?It is definitely OK to download the release from the release page.If you want to download via git instead of the release page, you will need to specifically check out the "1.4.0" tag to get the source of the 1.4.0 release. The current contents of git will otherwise be the primary active development branch. Also, I see a staging/1.5.0 branch. Is it around the corner, or will it take some time?It's going to take some time. My optimistic gut says next month is likely, all of our time permitting, but I wouldn't recommend holding off on upgrading when you are two releases behind the latest stable.- Mike

Re: Setting up HTTP header authentication

[Nick Couchman]

On Thu, May 19, 2022 at 10:52 AM Dmitry Katsubo 
wrote:

> On 2022-05-19 01:44, Michael Jumper wrote:
>
> On Mon, May 16, 2022 at 12:23 PM Dmitry Katsubo 
>  wrote:
>
>> Dear Guacamole users,
>> Dear Nick,
>>
>> Sorry I decided to resurrect the 4-years old challenge. I have rebased my
>> changes on the latest codebase. Not so many changes are required to allow
>> the user authenticated via auth-header extension to be provided
>> authentication information / connection settings from user-mapping.xml.
>> Without the changes the settings are not picked up from user-mapping.xml.
>>
>
> Is there a specific reason that you cannot use the database? It's intended
> for what you describe, intended for production use, and will work with
> header auth.
>
> I think that database is overkill for systems that have a couple of users
> (e.g. remote admins). Files are easier to maintain and backup, as all
> Guacamole configuration is basically located in one place. Also imagine the
> situation when database is down and could be fixed with help of Guacamole
> unless it is running on the top of that very database.
>
> Please check my commit b0aa658
>> .
>> If that is OK, then I would provide few unit tests for it. Otherwise let me
>> know what is missing, preferably in terms so that I can implement a test.
>>
>
> Looking at your commit, I see that one of the primary changes here is
> changing the prototype and visibility of the getAuthorizedConfigurations()
> function. This will break API and ABI compatibility, and I do not think we
> should do this.
>
> You mean that there are classes that extend SimpleAuthenticationProvider
> which are outside Guacamole git? Could be of course, however their
> adaptation will be trivial.
>

Yes, but the point is that Guacamole is designed to provide not just a
framework for itself, but one that people can build upon. With that in
mind, API/ABI changes need to be very carefully considered, and also need
to be made to be as backward-compatible as possible. In the past we've done
things like deprecate methods or classes, but they remain available in the
deprecated state for many releases before they are finally removed
completely. The changes need to be made in such a way that they don't
automatically break things for people who may be using/extending these
classes, and that they have the option of continuing to use them in the way
they are written while they change their code to the new way, but are
warned that support for it may be removed/changed at some point in the
future.


> For the built-in support for user-mapping.xml to be able to accept the
> authentication results of other installed extensions, it will need to be
> modified to use the less-simple API and implement AuthenticationProvider
> and UserContext (rather than use SimpleAuthenticationProvider).
>
> I think that should be possible. AuthenticationProvider is already
> implemented, probably not the proper way (if so, what is missing?). As for
> UserContext I am not sure: none of the providers I've checked implement
> this interface. Maybe you mean that SimpleUserContext should implement
> that interface in a proper way (again what exactly is missing)?
>

It is definitely possible, just needs to be done. I would also say it's
worth considering leaving the existing user-mapping.xml authentication
mechanism as-is and just implementing a different file-based one. It could
be XML, or YAML, or JSON (or provide methods for reading any/all of those
file types), and would be another extension in the "extensions/" folder.


> With user-mapping.xml really being intended for testing only, and with
> these changes aimed at allowing user-mapping.xml to be used in a more
> complex configuration aimed at production use, I think these changes really
> would need to be coupled with a move to a user-mapping variant that *is* 
> intended
> for production (proper salted hashes for passwords instead of
> intentionally-simplified-for-testing hashes, the ability to define a
> user/connection association that requires auth from some other extension
> and otherwise has no password, etc.).
>
> I think there are two things here mixed. The password which is used to
> authenticate the user against Guacamole is of course salted hashed and
> stored in guacamole_user SQL table. However in the setup I have the user
> is already authenticated by the front Web server, hence the password is
> null. There is nothing to salt or hash. On the other side the password
> stored in guacamole_connection_attribute table I believe is saved in
> plaintext, right? In this respect I don't see what else can be improved in
> user-mapping.xml which is basically another representation of the data in
> SQL database.
>

What you're asking for is a way to simply store connections in a file and
delegate the authentication elsewhere - the point is that the changes
you've made to the built-in test 

Re: New protocol 'http/https'

[Nick Couchman]

On Thu, May 19, 2022 at 3:48 AM Lionel PRAT  wrote:

> Hi,
>
> I'm looking for a solution to use guacamole to limit access to certain web
> administration interfaces (firewall, vmware, ...).
>
> I had thought of using a chrome in VNC but I find this solution too
> dangerous.
> The best solution would surely be to develop a connector for the
> 'http/https' protocol (perhaps starting from the existing code in the
> connector
> https://github.com/apache/guacamole-server/tree/master/src/protocols/
>  kubernetes).
> Has anyone had this problem before and if so, how did you resolve it?
>
>
This has come up several times, and, to date, we have not really seriously
entertained the idea and have kind of pushed back against it. The
conversation in the past has been that Guacamole has been targeted toward
remote desktop protocols, and HTTP/HTTPS are not remote desktop protocols.
Furthermore, there are plenty of solutions out there to proxy/reverse-proxy
HTTP and HTTPS pages, and those could be used in place of Guacamole. We may
be shifting a bit on this, but, today, it isn't possible to use HTTP/HTTPS
through guacd.

Several alternatives have been offered that continue to use Guacamole - for
example, you can set up a remote server running RDP or VNC and create a
remote connection to that server, and you can even have the remote
connection open only a web browser, and you could even do it in Kiosk mode
with either Firefox or Chrome to prevent users from using it for other web
pages.

Beyond that, adding HTTP/HTTPS support is possible, but I would not say
it's all that straight-forward. We've had some conversations about how it
could be done, and it seems like we would need to use some sort of back-end
rendering engine that guacd could interface with (there are a couple of
good ones out there) and then write the logic to translate between the
rendering engine and the Guacamole protocol. Definitely possible, just not
easy. And I'm not sure the Kubernetes protocol is a great place to start -
it's text-only, similar to Telnet and SSH, whereas the HTTP/HTTPS protocol
is going to need to be graphics-based, more along the lines of VNC or RDP.

-Nick

>

Re: Setting up HTTP header authentication

[Dmitry Katsubo]

On 2022-05-19 01:44, Michael Jumper wrote:
> On Mon, May 16, 2022 at 12:23 PM Dmitry Katsubo  wrote:
>
> Dear Guacamole users,
> Dear Nick,
>
> Sorry I decided to resurrect the 4-years old challenge. I have rebased my 
> changes on the latest codebase. Not so many changes are required to allow the 
> user authenticated via auth-header
> extension to be provided authentication information / connection settings 
> from user-mapping.xml. Without the changes the settings are not picked up 
> from user-mapping.xml.
>
>
> Is there a specific reason that you cannot use the database? It's intended 
> for what you describe, intended for production use, and will work with header 
> auth.
I think that database is overkill for systems that have a couple of users (e.g. 
remote admins). Files are easier to maintain and backup, as all Guacamole 
configuration is basically located in one
place. Also imagine the situation when database is down and could be fixed with 
help of Guacamole unless it is running on the top of that very database.
>
> Please check my commit b0aa658 
> .
>  If that is OK, then I would provide few unit tests for it. Otherwise
> let me know what is missing, preferably in terms so that I can implement 
> a test.
>
>
> Looking at your commit, I see that one of the primary changes here is 
> changing the prototype and visibility of the getAuthorizedConfigurations() 
> function. This will break API and ABI compatibility,
> and I do not think we should do this.
You mean that there are classes that extend SimpleAuthenticationProvider which 
are outside Guacamole git? Could be of course, however their adaptation will be 
trivial.
> For the built-in support for user-mapping.xml to be able to accept the 
> authentication results of other installed extensions, it will need to be 
> modified to use the less-simple API and implement
> AuthenticationProvider and UserContext (rather than use 
> SimpleAuthenticationProvider).
I think that should be possible. AuthenticationProvider is already implemented, 
probably not the proper way (if so, what is missing?). As for UserContext I am 
not sure: none of the providers I've
checked implement this interface. Maybe you mean that SimpleUserContext should 
implement that interface in a proper way (again what exactly is missing)?
> With user-mapping.xml really being intended for testing only, and with these 
> changes aimed at allowing user-mapping.xml to be used in a more complex 
> configuration aimed at production use, I think
> these changes really would need to be coupled with a move to a user-mapping 
> variant that /is/ intended for production (proper salted hashes for passwords 
> instead of
> intentionally-simplified-for-testing hashes, the ability to define a 
> user/connection association that requires auth from some other extension and 
> otherwise has no password, etc.).
I think there are two things here mixed. The password which is used to 
authenticate the user against Guacamole is of course salted hashed and stored 
in guacamole_user SQL table. However in the setup I
have the user is already authenticated by the front Web server, hence the 
password is null. There is nothing to salt or hash. On the other side the 
password stored in guacamole_connection_attribute
table I believe is saved in plaintext, right? In this respect I don't see what 
else can be improved in user-mapping.xml which is basically another 
representation of the data in SQL database.
>From another side if the changes I suggest break some other flow that you have 
>in mind, like proper data flow in conjunction with some other extension – 
>please let me know how can I reproduce the
issue, so that I can improve the code changes I suggested.

Many thanks!

-- 
With best regards,
Dmitry

Re: Update French translations

[Antoine Besnier]

 Hi Nick, 
Will do.Look for it in the coming days after I double and triple check them!
CheersAntoine
Le jeudi 19 mai 2022, 15:13:43 UTC+2, Nick Couchman  a 
écrit :  
 
 On Thu, May 19, 2022 at 5:19 AM Antoine Besnier 
 wrote:

Hi, 
I wanted to update the French translations, as they have not been corrected for 
a long time, and some sections have not been translated at all.Would the issue 
GUACAMOLE-1159 ( 
https://issues.apache.org/jira/browse/GUACAMOLE-1159?jql=project%20%3D%20GUACAMOLE%20AND%20text%20~%20french),
 which is closed, be suitable if I submit a PR, or would I have to open a new 
issue?


Antoine,We always welcome help with making the translations more complete and 
accurate. You'll want to open a new Jira issue and commit against that - don't 
use the closed one.
Thanks, looking forward to seeing the pull request!
-Nick  

Re: Update French translations

[Nick Couchman]

On Thu, May 19, 2022 at 5:19 AM Antoine Besnier
 wrote:

> Hi,
>
> I wanted to update the French translations, as they have not been
> corrected for a long time, and some sections have not been translated at
> all.
> Would the issue GUACAMOLE-1159 (
> https://issues.apache.org/jira/browse/GUACAMOLE-1159?jql=project%20%3D%20GUACAMOLE%20AND%20text%20~%20french),
> which is closed, be suitable if I submit a PR, or would I have to open a
> new issue?
>
>
Antoine,
We always welcome help with making the translations more complete and
accurate. You'll want to open a new Jira issue and commit against that -
don't use the closed one.

Thanks, looking forward to seeing the pull request!

-Nick

Re: Feature idea for guacamole

[Nick Couchman]

On Thu, May 19, 2022 at 6:12 AM Lee Doughty 
wrote:

> I was told this might be a good place to protist a feature idea to gauge
> interest before making a ticket.
>
> Would it be difficult to add a feature/option to fall back to user input
> on connections.. or to disable features that are unavailable if they are
> not available?
>
>
One of the design decisions we have intentionally made, particularly when
soliciting user input, is that user input is _never_ allowed to override
what an administrator has entered for the connection. Doing so could
present security risks that administrators may be intentionally trying to
guard against.


> When our users log in, we set up auto login RDP with file transfer support
> to try and make the users experience more friendly... However, this is
> fragile to users changing their password or, in the case of file transfer,
> modifying their authorized keys.
>
>
Allowing a RDP or VNC connection to continue even if SFTP fails has been
discussed in the past. I guess it doesn't tend to be an issue very often or
for very many people, because it doesn't come up often, but I think there's
already a Jira issue out there for it. The question really becomes, do you
want a half-working connection, where something is broken, or do you want
the connection to fail?

That said, we have some pending changes that allow guacd to deliver
messages back to the client, so maybe we could look into allowing this, but
warning the user that file transfer will not work because of a failure.

-Nick

>

Feature idea for guacamole

[Lee Doughty]

I was told this might be a good place to protist a feature idea to gauge
interest before making a ticket.

Would it be difficult to add a feature/option to fall back to user input on
connections.. or to disable features that are unavailable if they are not
available?

When our users log in, we set up auto login RDP with file transfer support
to try and make the users experience more friendly... However, this is
fragile to users changing their password or, in the case of file transfer,
modifying their authorized keys.

It would be nice if we could allow the connection to continue if the user
breaks these features

-Lee

Update French translations

[Antoine Besnier]

Hi, 
I wanted to update the French translations, as they have not been corrected for 
a long time, and some sections have not been translated at all.Would the issue 
GUACAMOLE-1159 ( 
https://issues.apache.org/jira/browse/GUACAMOLE-1159?jql=project%20%3D%20GUACAMOLE%20AND%20text%20~%20french),
 which is closed, be suitable if I submit a PR, or would I have to open a new 
issue?
Thanks in advance, Antoine 

Problem with expired password and TOTP

[MAURIZI Lorenzo]

Dear all,
I just noticed that in my installation, with TOTP module activated, there is a 
problem when I create a user with the "Password expired" flag to force password 
change at first login.

The workflow is as follows:

1.   The user goes to the login page and enters the username and the first 
provided password

2.   The user gets the password expired form, asking for the new password. 
After writing the new password twice, he presses "Continue"

3.   The user gets the enrollment QR code for TOTP. The user makes the 
enrollment into the OTP application and gives the first OTP to the screen.

After confirming the OTP code, the user gets "Invalid Login" error on top of 
the page and goes back to the login form.
>From now on, if the user tries to login again entering the new password, the 
>answer is "Verification failed. Please try again"
If he enters the old password, he obtains "Invalid login".

Any subsequent try to login (notice: WITHOUT reloading the page) the user 
obtains the same results as above (Invalid login with the old password, 
Verification failed with the new password).

The only resolution is to renew the page with a Ctrl-F5 or closing and 
reopening the browser.
After reloading the login page, if the user makes access with the new password, 
 the QRCode is displayed again on screen for TOTP enrollment, but the OTP 
Application is already enrolled, so it is only necessary to enter another OTP 
generated with the app.

In general, this problem occurs every time the user has to change the password 
for expiration (forced with the Password expired flag, or just expired for 
password enforcing policy in guacamole.properties), but in a subsequent 
password change, with TOTP already enrolled, only the request for a "normal" 
OTP code is shown.
But, after entering the OTP, again the user receives the "Invalid login" error 
and the login page is displayed, and it is necessary to reload the login page 
to make it work.

I think it could be considered a bug?

Best Regards
Lorenzo

New protocol 'http/https'

[Lionel PRAT]

Hi,

I'm looking for a solution to use guacamole to limit access to certain web
administration interfaces (firewall, vmware, ...).

I had thought of using a chrome in VNC but I find this solution too
dangerous.
The best solution would surely be to develop a connector for the
'http/https' protocol (perhaps starting from the existing code in the
connector
https://github.com/apache/guacamole-server/tree/master/src/protocols/
 kubernetes).
Has anyone had this problem before and if so, how did you resolve it?

Thank you

Lionel