Inconsistent Proxy behaviour for chrome web sessions

Published 9 years ago

Your recently added feature, to define a proxy for chrome web sessions, seemed to work at first for me.
But when I let my RDM users test those defined sessions, they failed to connect, receiving sometimes a error message from the embedded chrome component, sometimes the connection simply timed out.

Now for me the same issues occur as well and I cannot figure out the exact reasons.

Some observations:
It is completely irrelevant if or which credentials I supply for the proxy in the Proxy tab of the web session. They are simply not used or ignored.
The proxy always uses the credentials of the user which I use to run RDM, which in our case does not have rights to access the proxy.

Weird though, if I set the Login Authentication Mode of the web session to "Digest" and link the session credentials to an account with proxy rights, accessing the Internet works. And that's the only way that works.

It seems our proxy expects a digest authentication and ignores all other ways of authentication, which is why the proxy credentials account is never accepted. And by default the user of RDM is automatically used for digest authentication unless the web session authentication is set to "Digest" and the session is configured with a user with proxy rights.

So I have a cumbersome workaround to access sites on the internet with the disadvantage of not being able to provide credentials for the actual website I want to access and login to.

The other problem which I cannot work around is, that for some URLs, the proxy is not used even though there is no exception in the Proxy tab for the session.
This is a massive problem since we migrated our previsouly internal Sharepoint sites to the Microsoft Office 365 cloud. So all of our Sharepoint Documents now link to https://<company>.sharepoint.com/sites/<...>
When starting such a session linking to a Sharepoint document, a login process at the SharePoint site is triggered which runs through a few URLs but stops at an URL starting with https://login.microsoftonline.com/<...>. I observed this call with the tool CurrPorts and this website wants to include some content from another site with https://a<RemoteServerIP.deploy.static.akamaitechnologies.com/<...> which seems to be necessary for the login process. This remote address should never come up in the CurrPort list though as all communication for that session should go through the proxy.
And this is where it stops with a Syn-Sent and never proceeds.

-------------------
Remote Desktop Manager Enterprise Edition 12.6.6.0 64 Bit - Data Source: SQL Server
Running on Windows Server 2012R2 VMs with Remote Desktop Services feature, serving as common work environment for 30 Windows Server administrators

All Comments (6)

Hubert Mireault

Published 9 years ago

Hello,

Thank you for the detailed report on the issue. Unfortunately we haven't been able to reproduce the issue in our environment but that might be due to testing with a SOCKS proxy, which works for us. We don't presently have an HTTP proxy setup.
To confirm, is the proxy you're using the HTTP kind? Since we're already using all of what the third party provides us as far as settings go, I'm wondering if either the proxy's exact setup isn't supported or if there's an issue on their end.

Regards,

Hubert Mireault

holger01

Published 9 years ago

Hi Hubert,

yes, I can confirm that it is indeed an HTTP proxy - a Blue Coat Systems ProxySG to be precise, which seems to be an enterprise proxy/security solution which is quite popular among bigger companies.

Regarding the proxy authentication issue:
I guess the third party component is currently missing a digest mode option for proxy authentication even though it can handle/forward digest authentication, which is why it works when the session credentials are equipped with an account that has proxy rights.
Maybe you can bring that issue up with your third party supplier? I'd be happy to assist if they require more information/debugs/network traffic captures.

Regarding the direct connection issue:
The third party component should always use the proxy as long as there are no exceptions defined. Trying to establish a direct connection seems to be a bug to me.
I did some more testing and configured the proxy in "Windows/Internet Options/Connections/LAN settings". Now when starting the RDM web session to a Cloud SharePoint resource, the full login page from Office365 comes up and I am able to enter my account credentials in the form. However, the subsequent access to the resource fails as the Windows system proxy uses my admin account which is not allowed to access that content.
So in conclusion for some URLs the third party component seems to fall back to what's configured in Windows' Internet Options

Hubert Mireault

Published 9 years ago

Hello,

Sorry about the delay, we set up an HTTP proxy in our environment and did some tests. I wasn't able to successfully use the proxy with embedded Chrome and I contacted our third party for more information on the subject. I'll keep this thread updated with news and if I have any questions I can forward to you.

Regards,

Hubert Mireault

Hubert Mireault

Published 9 years ago

Hello,

Is it possible for you to allow access to your proxy for us and the developers of our third party? I would completely understand if you aren't able to due to security reasons. If you are able to, you can send me the information through private message or to hmireault (at) devolutions.net
Our own proxy isn't accessible from the outside but if it's impossible for you to provide us a testing environment, we'll see what we can do on our end to help the developers. The only reason I'm worried is in case the issue isn't the same and it still doesn't work for you down the line.

Regards,

Hubert Mireault

Hubert Mireault

Published 9 years ago

Hello,

Good news, after we contacted them, the third party updated their component with a fix for this issue. It will be available in the next minor RDM update. With the updated component we can't reproduce the issue while using our proxy.

Regards,

Hubert Mireault

holger01

Published 9 years ago

Hubert,

thank you. The update indeed overcame the proxy issue and it's confirmed working now.
Very much appreciated!