Hi Nick, Thanks for the info and response, just a couple of additional things on this:
“The virtual drive is managed entirely by guacd and forwarded through the RDP session, so there aren't any credentials for this, per se. That is, all of the files on the destination system will be owned by the Linux account that is running guacd, and will need to be accessible by this account. I had thought that the files were only temporarily stored on the linux system running guacd, does that mean files are permanently stored on the linux system and only accessible by the windows OS post authentication? The main concern here is access to files on the OS without having authenticated to the windows system so if its purely stored on the linux system then that makes things a bit easier here . I’d also be able to set up some cleanup scripts for files (unless guacamole has some clean up function for files?) Unsure if I need to raise a separate thread for this but I did try setting up an SFTP server as mentioned however the issue raised surrounding this was storing credentials – I tried to use a generic service account with a key pair to get around storing passwords (password polcies force a change every 30 days) and I’d thought this would only try authenticating for the SFTP account but when trying to access the rdp connection, it would fail authentication and made it seem as though it was trying to use the service account/key pair to authenticate against windows Himat From: Nick Couchman <[email protected]> Sent: 23 November 2020 17:48 To: [email protected] Subject: Re: Apache Guacamole v1.2 - Virtual Drive Questions On Mon, Nov 23, 2020 at 12:23 PM Himat Vekeria <[email protected]<mailto:[email protected]>> wrote: Hello, Apologies if this may not be the correct place to ask this, I’ve not raised a query for Apache Guacamole before and I’ve not been able to find answers to my questions on forums or other posts. You've come to the correct place! Scenario: * Dockerised deployment with 3 containers, one for guacamole, guacd and MySQL respectively. All 3 containers are linked and functional. * Additional mods – TOTP * MySQL and TOTP properties specified in start.sh * Apache reverse proxy with proxy pass in front of the guacamole container. * Local Apache Guacamole accounts stored in MySQL * Connection information stored within MySQL * A connection to connect to a windows server 2016 standard VM (domain joined). Connection is configured with a virtual drive to upload/download files through the browser session. Questions: 1. How is the virtual drive mapped between the Guacamole instance and the windows server it connects to and which credentials are used to handle this? I’ve logged into guacamole using the guacadmin account, clicked on the configured connection and before I’ve even authenticated to the windows server with domain credentials, I’m able to open the menu with ctrl + shift + alt and upload/download files to the windows server without specifying any credentials. The virtual drive is managed entirely by guacd and forwarded through the RDP session, so there aren't any credentials for this, per se. That is, all of the files on the destination system will be owned by the Linux account that is running guacd, and will need to be accessible by this account. 1. 2. Is there any way to restrict upload/download access so that it’s only possible to handle files after authenticating to the windows server? 3. Aside from the information stored in apache httpd logs, is there a better way to handle logging for file transfers? We need this for audit purposes. For what you're trying to do, I'd suggest that, instead of using the Virtual Drive, you use SFTP. You could set up a SFTP server that uses AD credential storage, and then just pass through the Guacamole authentication to that server, which should make the connection process transparent. This way the files will be owned by the user who logs in to SFTP, and you can also use transfer logging on SFTP to audit those uploads and downloads. I also have a second guacamole environment set up which used OpenID connect against Azure AD to provide authentication and MFA – this environment has the same issue with access to virtual drives being granted before authenticating to the backend windows server. Although this may be partly expected, due to authentication tokens being generated with OAuth/OpenID Connect, I do not have credential passthrough configured with parameter tokens (it doesn’t work properly – credentials are passed through when enabled but authentication fails, even though the credentials should be correct) so I would expect that the virtual drive would not be connected before authenticating to the server. A couple of things for this scenario: - Credential pass-through will not work, because Guacamole does not "know" about the password. Since the authentication is abstracted to OpenID, the password does not get sent from OpenID to Guacamole. So, this is going to be problematic for using Credential Pass-through and for NLA (until 1.3.0 is released with password prompting support). CAS has a feature called "ClearPass" that is able to work around this by providing the password used to log in to CAS to the application requesting the SSO login (Guacamole), but I do not believe that OpenID or SAML support this type of feature, and even CAS has significant warnings around it related to password security. - Even with password prompting support in 1.3.0, the virtual drive is still going to behave the same as noted above (it is entirely in gaucd's control and doesn't require AD authentication), and SFTP is not likely to work, either, since the password still won't be known to Guacamole. -Nick This electronic message contains information from CACI International Inc or subsidiary companies, which may be confidential, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify us immediately at [email protected] Viruses: Although we have taken steps to ensure that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. CACI Limited. Registered in England & Wales. Registration No. 1649776. CACI House, Avonmore Road, London, W14 8TS
