Proxies offer a lot of control for providing a means of managing what people in their enterprises can (or can’t) view on the internet, caching files to reduce bandwidth usage, and scan incoming files for viruses before then even end up on an end user machine.
For a desktop system that stays put and is always connected to the corporate network, this is a simple matter of configuring the browsers with the proxy information and you’re all set. However, in the case of a laptop, it’s not quite this easy.
If you configure a laptop in the same way that you configure a desktop, as soon as the employee takes their laptop home, or on a business trip, or to the coffee shop down the street, their internet won’t work. For an IT guy, it’s a simple fix. Just disable the proxy settings in the browser while you’re out, and re-enable them when you’re back in the office. In reality, end users aren’t IT guys. That’s why they hire IT guys instead of doing it themselves. We need an automatic solution for configuring the proxy based on where the user is.
Well, one option would be to install some third party piece of software to manage that for you. I’m not very inclined towards that. That means that each laptop needs to be manually configured each time there is a change, and you’re also adding another puzzle piece to an already complicated puzzle of systems administration.
The second option is what’s known as WPAD. It’s a system designed by Netscape back in 1996 (yes, 15 years ago). That relies on two options. One is that you can use the DHCP server to point a client towards a javascript file that tells the browser how to connect to the proxy. Problems are that not all DHCP servers support this, and not all browsers support this. In some cases, those are some big pitfalls. The second option is via DNS. In this option you create a subdomain of your local network for WPAD. So say your laptop’s hostname was laptop01.dyn.example.org, the system would look for wpad.dyn.example.org/wpad.dat, failing that would search for wpad.example.org/wpad.dat, failing that would search for wpad.org/wpad.dat, failing that would fail. Now I’m sure you can see where the issue is with this, “But wait! We don’t own wpad.org! We own example.org.” My answer to that is “Exactly.” This can and has been exploited. Also, like in the DHCP example, wpad.dat is a javascript file, and is executed EVEN IF JAVASCRIPT IS TURNED OFF IN THE BROWSER. NOT GOOD!
This is where I was stuck. Recently, I was setting up a new macbook for one of my end users, and had to configure the proxy. We discounted the idea of third party software right away, we toyed with the idea of the DNS option, didn’t like it, DHCP might have been an option for us, but our DHCP is served by a windows domain controller, and macs don’t like how they pass the extra information like the bits for WPAD. Hmmm… Then I found this…
It seems that Apple has provided me an out. Automatic proxy configuration lets me put in the address of the server and the filename for our wpad file, as wpad.dat and whatever.pac both do the same thing in the same way, and in the case that the system can’t reach our server, it fails over to running with NO proxy. Sounds perfect!
But wait! There’s more! Macs don’t configure the proxy settings in the browser. Proxy settings are a system wide setting. This way, it’s not only the browsers that automatically work, it’s everything on the system that uses the internet.
Apple may have a garden with some damn high walls around some of its products, but damn do they do a good job of making them easy to use.
