Workaround for “Windows AD domain is the same as my company’s primary DNS domain name,” Part 2

Previously I wrote about a Workaround for “Windows AD domain is the same as my company’s primary DNS domain name.” It involved installing a tiny web server on each domain controller. Today I'm going to write about an alternative way...

Let’s say my organization is “sojourners.me” and I use that for my internal Active Directory domain name (yes, not recommended) as well as the public face of my organization. It’s bad because people inside the network don’t resolve “sojourners.me” to the public webserver--they resolve it to the internal domain controllers (which is required for DFS to function properly).

Here’s a workaround... proxy autoconfiguration magic.

function FindProxyForURL(url, host) {
  if (shExpMatch(host, "sojourners.me"))
    return "PROXY proxy.sojourners.me:3128; DIRECT";
  else
    return "DIRECT";
}

If you’re interested in more info on FindProxyForURL, there are good references here and here.

You may say, “We don’t use a proxy server at my company. Our users don’t have proxy settings in their browsers.” For Windows AD-joined machines, a proxy autoconfiguration script can be easily rolled out via Group Policy Object. You can use your favorite search engine to search for “proxy auto configuration script gpo” or words to that effect. In the past, doing this on Firefox was more of a pain, but in the last few years they made the default proxy option to use the system proxy settings. As an alternative to GPO, you can play with DHCP and/or WPAD settings or get creative.

What should that auto configuration script point at? Using Squid, Apache proxy module, NetsScaler (like we have), or another proxy server of your choice, you can easily run a proxy service that won’t have to do much. In fact, with the script above, the only proxy requests it will have to handle are the ones to send it to the public web server, which should then send a HTTP 301 or 302  redirect to “www.sojourners.me.”