Have you ever tried to run an installer that required internet connectivity to pull down files from an external site — and it failed? Sometimes you can find an offline installer and in those cases, it is best to use that. Other times, you can’t.
Why do these stub style installers fail when you are in an environment that requires a proxy for all web access? The reason is because when they are installing, they are running under the LocalSystem authority, which does NOT pick up on whatever proxy you have set in IE! Frustrating right?
Or maybe you have noticed that your local certificate store is not updating because your system event log is complaining about it by throwing Crypt32 or CAPI2 events. For those that don’t know, since Windows Vista, Microsoft has included functionality that will automatically update your trusted certificates. It connects here in order to download a CAB file containing the latest list of commonly trusted public Certificate Authorities.
I have worked in networks that were heavily restricted and any users that needed to reach a website needed to configure a proxy server because the internal portion of the network did not even have routing for those external addresses. While it makes certain administrator tacks tricky, there is usually a solution for those situations. In 2019, that is starting to change as more organizations are making use of SaaS applications that require internet access. Additionally, firewalls like Palo Alto can perform tasks that previously were only handled by commercial (i.e. BlueCoat) or open source (i.e. Squid) proxy products like SSL Decrypt and providing/restricting access based on AD users & security groups.
Anyhow, whether you are trying to install a piece of software that does not have an offline installer – or you are setting up some automated process that has to run as a local account like LocalSystem or NetworkService – you must set up the system-level proxy. In doing so, we will essentially be diverting all OS-initiated traffic (as long as it is coming from a system authority) through a proxy server. This will NOT affect your user-level settings, so you can continue to manage those through group policy. Note: if you installed/configured any applications that run as an AD service account or a local user service account, then these settings won’t help you – you would need to set the proxy settings on those user accounts individually – whether AD or local group policy.
First, let’s check the current settings:
netsh winhttp show proxy
Good, the default is set to Direct Access (meaning no proxy configured).
Simply run:
netsh winhttp set proxy <hostname>:<port>
Note: you could also configure a bypass list if you’d like (although I won’t cover it in this short guide)
Now you can perform whatever actions you need to and then when you are done, if there is a need to restore to default/no proxy, then run:
netsh winhttp reset proxy
If you have a requirement or just want to route all system level traffic through your proxy, then you can actually configure this registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections
Key Name: WinHttpSettings
Key Type: Binary
Key Value: <name of your proxy in HEX format>
Even better, you can export this key and then load it into a GPO to deploy out across your network! No restart of Windows services are necessary.
Now, some of you may be wondering – why is all of this information useful from a security perspective? Because it gives administrators more control over the network.
I have seen countless times where organizations end up abandoning their proxy server system/approach because of how complicated it makes life on both end users and IT staff. Many of those were related to things like users or admins not being able to install software (which is a good reminder that not all orgs recognize the value in centrally packaging and deploying software – whether it is Adobe Acrobat, 7-Zip or Java). So they just back out and then open up their user and/or server networks directly out to the internet. If they’re doing so because they’re making use of and migrating to the NextGen firewall technology then great! But if they’re doing it to reduce hassle, that is not ideal.
By setting a system-level proxy, you can even opt to divert traffic to a different proxy server or service port from your end users, so you can set different policies! Just be careful that you don’t have people running Sysinternals PSEXEC and then using the “-i -s -d” options to get a CMD prompt as LocalSystem to abuse it 😉
Other creative ideas are separating workstation vs. server traffic and user vs. admin traffic, giving you a level of control above and beyond strictly using Windows authentication. Instead, you can do both! Just ensure that your systems and users are broken up into distinct AD security groups and then apply those to your individual service configurations on whatever proxy you’re using.
Another “plus” to this concept this that you can throttle the traffic differently and you can make use of caching on/off depending on the use case. For example, you may choose to enable caching on all user/workstation sourced traffic as well as server sourced traffic related to Windows Updates, but disable it everywhere else in the server environment. You may also want to de-prioritize OS generated traffic coming from systems in remote offices on a slow MPLS link or site-to-site VPN during certain times of the day. The use cases are endless!
I hope you enjoyed my article and I hope to cover how to set up a local Trusted Certificates cache in a future article!
Never A Null Moment 