Windows Explored

Recently, we were testing a new remote desktop application but I was experiencing problems connecting to the application, and it wasn’t isolated to a single workstation. A few of my other labs were unable to access the application as were other computers as the testing expanded. Admittedly, I should have figured this one out quickly as it was not the first time I encountered an issue trying to access remote desktop applications (i.e. terminal server apps) inside our network. The fact that we were hosting this RDP app internally, though, lead me to dismiss my initial hunch. A quick look with Network Monitor confirmed the problem:

The Windows local security authority processes (lsass.exe) is trying to get out to the cloud to do something, in this case likely some certificate revocation checking (this is usually the case for RDP apps). It keeps on trying by retransmitting until a response is received or it times out, but because we are behind a proxy, lsass.exe will never find a path outside the network. Certificate checking is handled by the Windows crypto API, which relies on WinHttp. Now, by default, Winhttp 5.1 can find a way out of the network if your network is configured to use Web Proxy Autodiscovery (WPAD). We do not, so the fix is to manually configure Winhttp to use some proxy. Since we have this information configured in Internet Explorer (along with proxy exceptions), we just need to import these settings into Winhttp via (elevated command prompt) netsh winhttp import proxy source=ie. Afterwards, the connection problem resolved*.

On the flipside, configuring Winhttp to use a static proxy can also cause connectivity problems for mobile users. I ran into this issue myself today when I was trying to stream a movie from Netflix and kept on encountering the following error: “Whoops. something went wrong… An Internet or home connection network connection problem is preventing playback… Error code: H7111-1101”

To verify my suspicion that the opposite was true—that Winhttp was trying to use a proxy it could not reach to do certificate verification checks—I looked in the Windows event CAPI2 logs and could see that the Netflix certificate check was failing:

The details pane further down revealed the cause as the certificate server was “offline”, which is just a generic term for can’t be found. You can verify your winhttp proxy via netsh winhttp show proxy. To correct, simply set the winhttp proxy to use direct connection via netsh winhttp reset proxy when outside the network.

*Certificate verification does not need to be performed for every session, i.e. the initial check is good enough until the crypto API determines that the information is expired and another check needs to be performed.

I am not sure why yet, but Netmon captures on a Windows 8.1 system did not reveal the lsass.exe process. Instead, the process was listed as unavailable.