[jira] [Commented] (GUACAMOLE-1332) Add parameter for specifying known RDP server certificate/fingerprint
[
https://issues.apache.org/jira/browse/GUACAMOLE-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17331835#comment-17331835
]
Bastien commented on GUACAMOLE-1332:
I understand. I don't find documentation on _certificate/fingerprint_ on
upstream project *freerdp*. With some
[tricks|https://gist.github.com/playerla/d6e4ec046029a0e77a0864b116b29016#file-known_hosts2]
I successfully wrote config/freerdp/known_hosts2. I agree it will be better
with RDP connection parameters for finding and specifying the
certificate/fingerprint.
> Add parameter for specifying known RDP server certificate/fingerprint
> -
>
> Key: GUACAMOLE-1332
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1332
> Project: Guacamole
> Issue Type: Wish
> Components: RDP
> Environment: Debian buster guacamole 1.3.0
>Reporter: Bastien
>Priority: Minor
> Attachments: guacamole.log
>
>
> Hello,
> I spend whole day to configure a RDP connection without using "Ignore server
> certificate". I use a xrdp serveur with a self signed certificate (end goal
> is a signed certificate from PKI). I didn't find how to trust the certificate
> fingerprint. I got "Certificate validation failed". "certificate not trusted,
> aborting."
> I discovered that Guacamole use freerdp which is not well documented on the
> subject. I tried to add the pem certificate with {{update-ca-certificates}},
> or in _.config/freerdp/certs_ and get nothing.
> Do I miss some documentation on how to set-up a trusted RDP host on Guacamole
> ?
> On my Guacamole test server, I install xfce and remina, succeed to connect to
> the target. It populates the .config/freerdp/known_hosts2 file, then
> Guacamole connection begin to work. But it is not an option for the
> production server.
>
> Thanks you
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GUACAMOLE-1334) OID Addon translation key is mismatched
Tim Worcester created GUACAMOLE-1334: Summary: OID Addon translation key is mismatched Key: GUACAMOLE-1334 URL: https://issues.apache.org/jira/browse/GUACAMOLE-1334 Project: Guacamole Issue Type: Bug Components: guacamole-auth-openid Affects Versions: 1.3.0 Reporter: Tim Worcester Fix For: 1.4.0 Code is looking for Key 'INFO_OID_PENDING_REDIRECT' Translation json provides: 'INFO_OID_REDIRECT_PENDING' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-1212) Support 2FA Directly in LDAP Extension
[ https://issues.apache.org/jira/browse/GUACAMOLE-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17332063#comment-17332063 ] Jelle de Jong commented on GUACAMOLE-1212: -- Me and Mike already had some discussion on the [u...@guacamole.apache.org|mailto:u...@guacamole.apache.org] mailing-list. What I read here is that somehow the LDAP code is using the users credentials multiple times and not only for password validation? My experience with LDAP integrations is that there is an admin bind that is used for gathering group information and other data validations. I got many other LDAP integration working with the FreeIPA password+otp and I would really like to see Guacamole working as well. In my /etc/guacamole/guacamole.properties I have these two options: ldap-search-bind-dn: uid=externalldapadmin,cn=sysaccounts,cn=etc,dc=bothends,dc=lan ldap-search-bind-password: secret Would it not be an easy fix to change the LDAP binds to the admin bind and only use the user password validation during login, the group and permission escalations should could be done securely with the right username filters, if there are other look-ups later after the user is already logged in then this should also not be an issue. I am also okay with the current password field that can handle password+otp for the LDAP backend and use the new password prompting features of 1.3.0 for the further connection. > Support 2FA Directly in LDAP Extension > -- > > Key: GUACAMOLE-1212 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1212 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-auth-ldap >Reporter: Brett Smith >Priority: Minor > Attachments: user-with-otp-trace-level.log > > > I'm using FreeIPA in my environment. I have guacamole-auth-ldap enabled and > configured and it works fine for users who do not have 2FA enabled. For our > users with 2FA enabled, we are using TOTP tokens provided by FreeIPA. > When investigating a tcpdump between guacamole and the LDAP server, I can see > that guacamole passes the username and password to the LDAP server twice. > This works fine for a traditional username and password, but for a > 2FA-enabled user, the second authentication attempt returns failure since the > TOTP is one-time use. 2FA login attempts result in the guacamole logs > outputting "successfully authenticated" while the web UI shows "Invalid > Login" in a red banner. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-1334) OID Addon translation key is mismatched
[ https://issues.apache.org/jira/browse/GUACAMOLE-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17332064#comment-17332064 ] Tim Worcester commented on GUACAMOLE-1334: -- MR: https://github.com/apache/guacamole-client/pull/605 > OID Addon translation key is mismatched > --- > > Key: GUACAMOLE-1334 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1334 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-openid >Affects Versions: 1.3.0 >Reporter: Tim Worcester >Priority: Trivial > Fix For: 1.4.0 > > > Code is looking for Key 'INFO_OID_PENDING_REDIRECT' > Translation json provides: 'INFO_OID_REDIRECT_PENDING' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GUACAMOLE-1334) OID Addon translation key is mismatched
[ https://issues.apache.org/jira/browse/GUACAMOLE-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Worcester resolved GUACAMOLE-1334. -- Resolution: Fixed MR Merged > OID Addon translation key is mismatched > --- > > Key: GUACAMOLE-1334 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1334 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-openid >Affects Versions: 1.3.0 >Reporter: Tim Worcester >Priority: Trivial > Fix For: 1.4.0 > > > Code is looking for Key 'INFO_OID_PENDING_REDIRECT' > Translation json provides: 'INFO_OID_REDIRECT_PENDING' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-1212) Support 2FA Directly in LDAP Extension
[
https://issues.apache.org/jira/browse/GUACAMOLE-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17332443#comment-17332443
]
Nick Couchman commented on GUACAMOLE-1212:
--
{quote}
Would it not be an easy fix to change the LDAP binds to the admin bind and only
use the user password validation during login, the group and permission
escalations should could be done securely with the right username filters, if
there are other look-ups later after the user is already logged in then this
should also not be an issue.
{quote}
I'm not sure it's an easy fix, but it is doable. That said, while we may look
at making this configurable, it will probably not be the default - the LDAP
extension as it operates today is designed _intentionally_ to operate the way
it does - that is, use the search user _only_ for locating the user that is
logging in, and then use the logged in user for all other binds after that. In
this way, it leverages the security built-in to LDAP in order to provide access
to the resources that the LDAP user should be able to access.
{quote}
I am also okay with the current password field that can handle password+otp for
the LDAP backend and use the new password prompting features of 1.3.0 for the
further connection.
{quote}
I'm not entirely sure what you mean, here - the current password field can
handle password+otp (the LDAP extension just doesn't know how to prompt for the
OTP separate from the password). However, I think making sure that the LDAP
connection(s) are persistent for the life of the Guacamole session is probably
the best way to go.
> Support 2FA Directly in LDAP Extension
> --
>
> Key: GUACAMOLE-1212
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1212
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole-auth-ldap
>Reporter: Brett Smith
>Priority: Minor
> Attachments: user-with-otp-trace-level.log
>
>
> I'm using FreeIPA in my environment. I have guacamole-auth-ldap enabled and
> configured and it works fine for users who do not have 2FA enabled. For our
> users with 2FA enabled, we are using TOTP tokens provided by FreeIPA.
> When investigating a tcpdump between guacamole and the LDAP server, I can see
> that guacamole passes the username and password to the LDAP server twice.
> This works fine for a traditional username and password, but for a
> 2FA-enabled user, the second authentication attempt returns failure since the
> TOTP is one-time use. 2FA login attempts result in the guacamole logs
> outputting "successfully authenticated" while the web UI shows "Invalid
> Login" in a red banner.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-1212) Support 2FA Directly in LDAP Extension
[ https://issues.apache.org/jira/browse/GUACAMOLE-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17332472#comment-17332472 ] Brett Smith commented on GUACAMOLE-1212: If leveraging the sysaccount bind will solve Guac attempting to use the user's OTP multiple times, that seems like the right approach to me. Bind accounts do not degrade the security of LDAP; most LDAP-aware applications use a bind account for searching the directory. Personally, I'm fine with the OTP being placed after the password in the password field. That's the approach our users are used to with other LDAP-aware applications. > Support 2FA Directly in LDAP Extension > -- > > Key: GUACAMOLE-1212 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1212 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-auth-ldap >Reporter: Brett Smith >Priority: Minor > Attachments: user-with-otp-trace-level.log > > > I'm using FreeIPA in my environment. I have guacamole-auth-ldap enabled and > configured and it works fine for users who do not have 2FA enabled. For our > users with 2FA enabled, we are using TOTP tokens provided by FreeIPA. > When investigating a tcpdump between guacamole and the LDAP server, I can see > that guacamole passes the username and password to the LDAP server twice. > This works fine for a traditional username and password, but for a > 2FA-enabled user, the second authentication attempt returns failure since the > TOTP is one-time use. 2FA login attempts result in the guacamole logs > outputting "successfully authenticated" while the web UI shows "Invalid > Login" in a red banner. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-1212) Support 2FA Directly in LDAP Extension
[
https://issues.apache.org/jira/browse/GUACAMOLE-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17332480#comment-17332480
]
Nick Couchman commented on GUACAMOLE-1212:
--
{quote}
If leveraging the sysaccount bind will solve Guac attempting to use the user's
OTP multiple times, that seems like the right approach to me. Bind accounts do
not degrade the security of LDAP; most LDAP-aware applications use a bind
account for searching the directory.
{quote}
I'm not opposed to having that as an option (as mentioned before), but not by
default. I agree that bind accounts do not, in and of themselves, degrade the
security of LDAP - it depends upon how you use them. That has never been my
point - my point is that the Guacamole LDAP extension is _designed_ to leverage
LDAP security. Thus, changing this behavior in the LDAP module *will* impact
the security of the LDAP module in ways that may matter to other users. It may
not impact you and your use-case, but it is relevant to how we've designed the
LDAP module to be deployed, and that has to be factored into this. It is one of
the reasons why we won't make this behavior - using the bind account for all
LDAP operations - the default behavior - it will be something you have to
manually change in the config file.
> Support 2FA Directly in LDAP Extension
> --
>
> Key: GUACAMOLE-1212
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1212
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole-auth-ldap
>Reporter: Brett Smith
>Priority: Minor
> Attachments: user-with-otp-trace-level.log
>
>
> I'm using FreeIPA in my environment. I have guacamole-auth-ldap enabled and
> configured and it works fine for users who do not have 2FA enabled. For our
> users with 2FA enabled, we are using TOTP tokens provided by FreeIPA.
> When investigating a tcpdump between guacamole and the LDAP server, I can see
> that guacamole passes the username and password to the LDAP server twice.
> This works fine for a traditional username and password, but for a
> 2FA-enabled user, the second authentication attempt returns failure since the
> TOTP is one-time use. 2FA login attempts result in the guacamole logs
> outputting "successfully authenticated" while the web UI shows "Invalid
> Login" in a red banner.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GUACAMOLE-1283) Legacy RDP encryption may fail with "ERRINFO_DECRYPT_FAILED"
[
https://issues.apache.org/jira/browse/GUACAMOLE-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17332573#comment-17332573
]
Shaun Tarves edited comment on GUACAMOLE-1283 at 4/26/21, 4:28 PM:
---
[~mjumper] [~vnick] We tried to build off master to test this fix and the
filesystem mounting doesn't appear to be working at all now.
was (Author: shauntarves):
[~mjumper] We tried to build off master to test this fix and the filesystem
mounting doesn't appear to be working at all now.
> Legacy RDP encryption may fail with "ERRINFO_DECRYPT_FAILED"
>
>
> Key: GUACAMOLE-1283
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1283
> Project: Guacamole
> Issue Type: Bug
> Components: RDP
>Affects Versions: 1.2.0
> Environment: guacd 1.2 running in Docker on RHEL 7 deployed in AWS
>Reporter: Shaun Tarves
>Assignee: Mike Jumper
>Priority: Minor
> Fix For: 1.4.0
>
> Attachments: RemoteDesktop.txt, TerminalServices.txt
>
>
> We are experiencing semi-regular disconnects of the guacamole-server (guacd)
> while a user is interacting with a remote machine. Attached are the
> DEBUG-level logs, which we see every time we experience the disconnects. I'm
> not sure how to further debug this issue.
> {code}
> Feb 8 14:46:21 ip-172-16-10-253 journal: guacd[148]: DEBUG:#011Clipboard
> data received. Reporting availability of clipboard data to RDP server.
> Feb 8 14:46:24 ip-172-16-10-253 journal: guacd[84]: DEBUG:#011Clipboard data
> received. Reporting availability of clipboard data to RDP server.
> Feb 8 14:46:41 ip-172-16-10-253 journal: guacd[148]: DEBUG:#011Clipboard
> data received. Reporting availability of clipboard data to RDP server.
> Feb 8 14:47:13 ip-172-16-10-253 journal: guacd[148]: DEBUG:#011Clipboard
> data received. Reporting availability of clipboard data to RDP server.
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: DEBUG:#011Clipboard
> data received. Reporting availability of clipboard data to RDP server.
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]:
> DEBUG:#011ERRINFO_DECRYPT_FAILED (0x1192):(a) Decryption using Standard
> RDP Security mechanisms (section 5.3.6) failed.
> Feb 8 14:47:22 ip-172-16-10-253 journal: (b) Session key creation using
> Standard RDP Security mechanisms (section 5.3.5) failed.
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: DEBUG:#011BIO_read
> returned a system error 104: Connection reset by peer
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: ERROR:#011Connection
> closed.
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: DEBUG:#011Unloading
> device 0 (Remote Access Filesystem)
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: DEBUG:#011SVC "rdpdr"
> disconnected.
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: DEBUG:#011SVC "rdpsnd"
> disconnected.
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: INFO:#011Internal RDP
> client disconnected
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: INFO:#011User
> "@5dd34373-1e17-4091-9670-c00fc2d68684" disconnected (0 users remain)
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: INFO:#011Last user of
> connection "$60bea827-60a1-403b-84b8-3c7358f490ee" disconnected
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: DEBUG:#011Requesting
> termination of client...
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: DEBUG:#011Client
> terminated successfully.
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[8]: INFO:#011Connection
> "$60bea827-60a1-403b-84b8-3c7358f490ee" removed.
> {code}
> Attached are the MS Event Logs for the `RemoteDesktop*` and
> `TerminalServices*` log sources
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-1283) Legacy RDP encryption may fail with "ERRINFO_DECRYPT_FAILED"
[
https://issues.apache.org/jira/browse/GUACAMOLE-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17332573#comment-17332573
]
Shaun Tarves commented on GUACAMOLE-1283:
-
[~mjumper] We tried to build off master to test this fix and the filesystem
mounting doesn't appear to be working at all now.
> Legacy RDP encryption may fail with "ERRINFO_DECRYPT_FAILED"
>
>
> Key: GUACAMOLE-1283
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1283
> Project: Guacamole
> Issue Type: Bug
> Components: RDP
>Affects Versions: 1.2.0
> Environment: guacd 1.2 running in Docker on RHEL 7 deployed in AWS
>Reporter: Shaun Tarves
>Assignee: Mike Jumper
>Priority: Minor
> Fix For: 1.4.0
>
> Attachments: RemoteDesktop.txt, TerminalServices.txt
>
>
> We are experiencing semi-regular disconnects of the guacamole-server (guacd)
> while a user is interacting with a remote machine. Attached are the
> DEBUG-level logs, which we see every time we experience the disconnects. I'm
> not sure how to further debug this issue.
> {code}
> Feb 8 14:46:21 ip-172-16-10-253 journal: guacd[148]: DEBUG:#011Clipboard
> data received. Reporting availability of clipboard data to RDP server.
> Feb 8 14:46:24 ip-172-16-10-253 journal: guacd[84]: DEBUG:#011Clipboard data
> received. Reporting availability of clipboard data to RDP server.
> Feb 8 14:46:41 ip-172-16-10-253 journal: guacd[148]: DEBUG:#011Clipboard
> data received. Reporting availability of clipboard data to RDP server.
> Feb 8 14:47:13 ip-172-16-10-253 journal: guacd[148]: DEBUG:#011Clipboard
> data received. Reporting availability of clipboard data to RDP server.
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: DEBUG:#011Clipboard
> data received. Reporting availability of clipboard data to RDP server.
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]:
> DEBUG:#011ERRINFO_DECRYPT_FAILED (0x1192):(a) Decryption using Standard
> RDP Security mechanisms (section 5.3.6) failed.
> Feb 8 14:47:22 ip-172-16-10-253 journal: (b) Session key creation using
> Standard RDP Security mechanisms (section 5.3.5) failed.
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: DEBUG:#011BIO_read
> returned a system error 104: Connection reset by peer
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: ERROR:#011Connection
> closed.
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: DEBUG:#011Unloading
> device 0 (Remote Access Filesystem)
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: DEBUG:#011SVC "rdpdr"
> disconnected.
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: DEBUG:#011SVC "rdpsnd"
> disconnected.
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: INFO:#011Internal RDP
> client disconnected
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: INFO:#011User
> "@5dd34373-1e17-4091-9670-c00fc2d68684" disconnected (0 users remain)
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: INFO:#011Last user of
> connection "$60bea827-60a1-403b-84b8-3c7358f490ee" disconnected
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: DEBUG:#011Requesting
> termination of client...
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: DEBUG:#011Client
> terminated successfully.
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[8]: INFO:#011Connection
> "$60bea827-60a1-403b-84b8-3c7358f490ee" removed.
> {code}
> Attached are the MS Event Logs for the `RemoteDesktop*` and
> `TerminalServices*` log sources
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-1283) Legacy RDP encryption may fail with "ERRINFO_DECRYPT_FAILED"
[
https://issues.apache.org/jira/browse/GUACAMOLE-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17332709#comment-17332709
]
Mike Jumper commented on GUACAMOLE-1283:
[~shauntarves] - retesting against master, drive support for RDP seems to be
working fine. I see the virtual filesystem within the RDP session, and I'm able
to initiate file downloads. Quickly checking other virtual channels (clipboard,
audio output), no issues encountered there, either. Tested against connections
to Windows 2019 and Windows 2003.
Perhaps FreeRDP plugins, etc. are hanging around from a previous build?
> Legacy RDP encryption may fail with "ERRINFO_DECRYPT_FAILED"
>
>
> Key: GUACAMOLE-1283
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1283
> Project: Guacamole
> Issue Type: Bug
> Components: RDP
>Affects Versions: 1.2.0
> Environment: guacd 1.2 running in Docker on RHEL 7 deployed in AWS
>Reporter: Shaun Tarves
>Assignee: Mike Jumper
>Priority: Minor
> Fix For: 1.4.0
>
> Attachments: RemoteDesktop.txt, TerminalServices.txt
>
>
> We are experiencing semi-regular disconnects of the guacamole-server (guacd)
> while a user is interacting with a remote machine. Attached are the
> DEBUG-level logs, which we see every time we experience the disconnects. I'm
> not sure how to further debug this issue.
> {code}
> Feb 8 14:46:21 ip-172-16-10-253 journal: guacd[148]: DEBUG:#011Clipboard
> data received. Reporting availability of clipboard data to RDP server.
> Feb 8 14:46:24 ip-172-16-10-253 journal: guacd[84]: DEBUG:#011Clipboard data
> received. Reporting availability of clipboard data to RDP server.
> Feb 8 14:46:41 ip-172-16-10-253 journal: guacd[148]: DEBUG:#011Clipboard
> data received. Reporting availability of clipboard data to RDP server.
> Feb 8 14:47:13 ip-172-16-10-253 journal: guacd[148]: DEBUG:#011Clipboard
> data received. Reporting availability of clipboard data to RDP server.
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: DEBUG:#011Clipboard
> data received. Reporting availability of clipboard data to RDP server.
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]:
> DEBUG:#011ERRINFO_DECRYPT_FAILED (0x1192):(a) Decryption using Standard
> RDP Security mechanisms (section 5.3.6) failed.
> Feb 8 14:47:22 ip-172-16-10-253 journal: (b) Session key creation using
> Standard RDP Security mechanisms (section 5.3.5) failed.
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: DEBUG:#011BIO_read
> returned a system error 104: Connection reset by peer
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: ERROR:#011Connection
> closed.
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: DEBUG:#011Unloading
> device 0 (Remote Access Filesystem)
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: DEBUG:#011SVC "rdpdr"
> disconnected.
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: DEBUG:#011SVC "rdpsnd"
> disconnected.
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: INFO:#011Internal RDP
> client disconnected
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: INFO:#011User
> "@5dd34373-1e17-4091-9670-c00fc2d68684" disconnected (0 users remain)
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: INFO:#011Last user of
> connection "$60bea827-60a1-403b-84b8-3c7358f490ee" disconnected
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: DEBUG:#011Requesting
> termination of client...
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[148]: DEBUG:#011Client
> terminated successfully.
> Feb 8 14:47:22 ip-172-16-10-253 journal: guacd[8]: INFO:#011Connection
> "$60bea827-60a1-403b-84b8-3c7358f490ee" removed.
> {code}
> Attached are the MS Event Logs for the `RemoteDesktop*` and
> `TerminalServices*` log sources
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
