OK, our Okta team had to make some changes on their end to send the data back properly. So now I can get in using our smart card authentication. But this leads to 2 questions/issues that I still need help with:
1. How can I by-pass the SAML authentication to be able to log in as the guacadmin user? 2. I had a user try to log in, and he did successfully. But he doesn’t have a user account in the internal MySQL database, so why wouldn’t that be rejected? He has no permissions and can’t assign his user to any connections, but I was thinking that there should’ve been some sort of block. Thanks! Harry From: Devine, Harry (FAA) <[email protected]> Sent: Wednesday, December 18, 2024 1:15 PM To: [email protected] Subject: RE: Question about callback URL with SAML configuration CAUTION: This email originated from outside of the Federal Aviation Administration (FAA). Do not click on links or open attachments unless you recognize the sender and know the content is safe. All of our servers are FIPS-140-2 as this is a mandate for us. Been that way for years. All of our Guacamole servers have the following in /etc/httpd/conf.d/forward.conf: <Location /> Order allow,deny Allow from all ProxyPass http://localhost:8080/guacamole/ flushpackets=on ProxyPassReverse http://localhost:8080/guacamole/ </Location> I changed it on this test server to take out the /guacamole reference as per Jon’s suggestion. We are also not being asked, or directed, so consider SSH sessions to be MFA-challenged for now, as they feel that the Okta MFA is not anti-phishing MFA for SSH. I can provide snippets of any config file you want/need, because I’m obviously missing something. And once I (mainly, we or someone other than I) figure out how to get the callback to work and not do the redirect loop, I will need to know how the data sent back from a successful SAML request can be used to look up the user in the Guacamole database and ensure that the user is valid. Entering a valid PIN from our smart card is great, but we still don’t want any user to just have access. They still need to exist in the Guacamole internal database. That’s how it is for LDAP for us at the moment. They log in with their LDAP, get authenticated, and get let in. So maybe I’m over thinking it. Maybe the SAML authentication will handle that lookup automatically. Thanks, Harry From: Sean Hulbert <[email protected]<mailto:[email protected]>> Sent: Wednesday, December 18, 2024 11:25 AM To: [email protected]<mailto:[email protected]> Subject: Re: Question about callback URL with SAML configuration CAUTION: This email originated from outside of the Federal Aviation Administration (FAA). Do not click on links or open attachments unless you recognize the sender and know the content is safe. Hello Harry, This is more informational than a fix to your SAML issue, hope this helps. Have you tried: # Proxy all requests to the Guacamole server ProxyPass /guacamole http://localhost:8080/guacamole ProxyPassReverse /guacamole http://localhost:8080/guacamole Or # Proxy all requests to the Guacamole server ProxyPass / http://localhost:8080/guacamole ProxyPassReverse / http://localhost:8080/guacamole You can also rename the .war create a slink in the tomcat9 directory WEBAPP will also change the https://url/<here> You will need to take this one step further, as the federal mandates will require FIPS 140-2(3), you can get this done with Openssl 3.x, you will also need to make sure that local SSH is using MFA this can be done with Googles module or PAM TLS: 1.2: This will force AES256 over TCP/IP ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-RSA-CHACHA20-POLY1305 ECDHE-ECDSA-AES128-GCM-SHA256 Phased out in 2030 ECDHE-RSA-AES128-GCM-SHA256 Phased out in 2030 Alternate Ciphers for TLS 1.2: EECDH+AESGCM:EECDH+CHACHA20:EECDH+AES256:EECDH+AES128 TLS: 1.3 No need to specify ciphers explicitly, as they are predefined: Keep in mind that some federal departments only support TLS 1.2 still TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 - Phased out in 2030 Additional Security Measures * Certificate: Use a certificate with at least 2048-bit RSA or an ECDSA certificate with a 256-bit key. * OCSP Stapling: Ensures efficient certificate status verification. * HSTS: Enforces HTTPS across your domain. * Key Exchange: Prefer Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) for forward secrecy. SSH: Strong Ciphers Ciphers [email protected],[email protected],aes256-ctr<mailto:[email protected],[email protected],aes256-ctr> MACs [email protected],[email protected],[email protected]<mailto:[email protected],[email protected],[email protected]> KexAlgorithms curve25519-sha256,[email protected],diffie-hellman-group-exchange-sha256<mailto:[email protected],diffie-hellman-group-exchange-sha256> I only mention this so you have a heads up in your configuration as FIPS can break updates and some functional capabilities in Guacamole. Thank You Sean Hulbert Security Centric Inc. A Cybersecurity Virtualization Enablement Company StormCloud Gov, Protected CUI Environment! [cid:[email protected]] Industry's most secure CMMC/iTAR virtual desktops! FedRAMP MIL4 in process (RAR) System Award Management CAGE: 8AUV4 SAM ID: UMJLJ8A7BMT3 AFCEA San Francisco Chapter President If you have heard of a hacker by name, he/she has failed, fear the hacker you haven’t heard of! CONFIDENTIALITY NOTICE: This communication with its contents may contain confidential and/or legally privileged information. It is solely for the use of the intended recipient(s). Unauthorized interception, review, use or disclosure is prohibited and may violate applicable laws including the Electronic Communications Privacy Act. If you are not the intended recipient, please contact the sender and destroy all copies of the communication. Content within this email communication is not legally binding as a contract and no promises are guaranteed unless in a formal contract outside this email communication. igitur qui desiderat pacem, praeparet bellum!!! Epitoma Rei Militaris On 12/18/2024 6:08 AM, Devine, Harry (FAA) wrote: In the browser’s Debug console, I do see an error for “tokens”, and when I click on it, the Headers show a “403 Forbidden” error for https://<server>/api/tokens<https://%3cserver%3e/api/tokens>. I know I’ve never set that up, so I wonder if that’s something needed? But I can’t find that in the docs anywhere. Thanks, Harry From: Devine, Harry (FAA) <[email protected]><mailto:[email protected]> Sent: Wednesday, December 18, 2024 9:03 AM To: [email protected]<mailto:[email protected]> Subject: RE: Question about callback URL with SAML configuration CAUTION: This email originated from outside of the Federal Aviation Administration (FAA). Do not click on links or open attachments unless you recognize the sender and know the content is safe. Also, I am doing a ProxyPass to proxy the traffic through Apache to the Guacamole backend on 8080: <Location /> Order allow,deny Allow from all ProxyPass http://localhost:8080/guacamole/ flushpackets=on ProxyPassReverse http://localhost:8080/guacamole/ </Location> Not sure how this plays into things. But when I sign into the SAML with my smart card, that works, and the redirect back just keeps sending me back to the Okta MFA page, which detects I’m already logged in, and redirects back to Guacamole, and the cycle continues for a while until the 429 Too Many Requests comes across. Thanks, Harry From: Devine, Harry (FAA) <[email protected]<mailto:[email protected]>> Sent: Tuesday, December 17, 2024 3:26 PM To: [email protected]<mailto:[email protected]> Subject: RE: Question about callback URL with SAML configuration CAUTION: This email originated from outside of the Federal Aviation Administration (FAA). Do not click on links or open attachments unless you recognize the sender and know the content is safe. I’m not really getting any errors in the Tomcat logs or /var/log/messages. I eventually just get a 429 Too Many Redirects error. And the callback I’m referring too is what we need to put into the saml-callback-url propery in /etc/guacamole/guacamole.properties. Currently, we have the server name itself (https://<server<https://%3cserver>>). I’m assuming that needs to be something different. Thanks, Harry From: Nick Couchman <[email protected]<mailto:[email protected]>> Sent: Tuesday, December 17, 2024 3:20 PM To: [email protected]<mailto:[email protected]> Subject: Re: Question about callback URL with SAML configuration CAUTION: This email originated from outside of the Federal Aviation Administration (FAA). Do not click on links or open attachments unless you recognize the sender and know the content is safe. On Tue, Dec 17, 2024 at 3:13 PM Devine, Harry (FAA) <[email protected]<mailto:[email protected]>> wrote: We are on Guacamole 1.5.4 at the moment, and we have a mandate to implement MFA. We have been working with our IT department and using a test Guacamole server for the configuration testing. We were initially trying OpenID but we kept getting an invalid response_type value. So they suggested SAML, which we implemented and proved that we could log in. However, we do get an error from Guacamole because the MFA doesn’t seem to know how to return the response back to our Guacamole server. What error are you seeing? And what messages are you getting in the logs? So, my question is: how to I implement or configure the Callback URL on our Guacamole server so the response that comes back can be retrieved? Are you talking about the callback URL in the Guacamole configuration, or one specific to the SAML IdP? -Nick
