Home > Forefront TMG 2010, Threat Management Gateway > WPAD Considerations for Kerberos Authentication with NLB VIP on Forefront TMG 2010

WPAD Considerations for Kerberos Authentication with NLB VIP on Forefront TMG 2010

February 13, 2012

As I outlined in a recent article on ISAserver.org, Service Pack 2 (SP2) for Forefront TMG 2010 supports Kerberos authentication in load-balanced scenarios when web proxy clients are configured to use the virtual IP address (VIP) of the array. However, using Web Proxy Automatic Discovery (WPAD) with either DNS or DHCP poses a challenge for organizations that choose to take advantage of this new feature. When using WPAD, the web proxy client retrieves the automatic configuration script from the Forefront TMG firewall. The script provides the web proxy client with the IP addresses (or hostnames, if configured) of the individual array members. In this configuration, the web proxy client will send its request to one of the array members returned by function MakeProxies() and not to the VIP, as desired.

To work around this issue you can configure a separate web server to host the automatic configuration script. You can use any web server you wish, just make sure that it is highly available and don’t forget to configure the MIME type application/x-ns-proxy-autoconfig for the file extension you choose (typically .DAT or .PAC). Full details about how to do this can be found here. You can create your own Proxy Automatic Configuration (PAC) file from scratch, or you can simply retrieve the automatic configuration script from TMG, modify it to use the IP address (or preferably the hostname or FQDN) of the Forefront TMG array’s VIP, and place that on the web server for clients to retrieve. This means that the automatic configuration script will have to be updated manually, as required. This could be automated by writing a script that periodically retrieves the automatic configuration script from the Forefront TMG firewall, modifies it appropriately, and then saves it on the web server if you were really clever! Another alternative is to configure the Forefront TMG 2010 firewall to return a customized automatic configuration script. You can find details about this configuration here.

  1. February 16, 2012 at 2:54 pm

    Didn’t the behavior for the MakeProxies function change with ISA Server 2006 at some point to where it changed it from the FQDN to the IP address? This was to avoid certain issues if I recall correctly.

    What reason or reasons would there be to change the MakeProxy function to return a FQDN as opposed to an IP address?

    If you are utilizing the new Kerberos feature provided to us in TMG SP2, I assume the original connection to the NLB VIP uses Kerberos but how are subsequent connections to each array member made? I’m referring to the subsequent connections made after receiving the array list from the MakeProxies function. Is that made using Kerberos or NTLM?

  2. February 17, 2012 at 8:13 am

    I found the article that discusses the change from fpcNameSystem_DNS to fpcNameSystem_IP for ISA 2004/2006.

    The following script must be run in order to change the behavior to return the FQDN instead of the IP address in the wpad.dat file:

    Const fpcCarpNameSystem_DNS = 0
    Const fpcCarpNameSystem_WINS = 1
    Const fpcCarpNameSystem_IP = 2

    Dim oISA: Set oISA = CreateObject( “FPC.Root” )
    Dim oArray: Set oArray = oISA.GetContainingArray
    Dim oWebProxy: Set oWebProxy = oArray.ArrayPolicy.WebProxy

    If fpcCarpNameSystem_DNS = oWebProxy.CarpNameSystem Then
    WScript.Echo “ISA is already configured to provide DNS names in the WPAD script”
    End If

    oWebProxy.CarpNameSystem = fpcCarpNameSystem_DNS
    oWebProxy.Save true

    WScript.Echo “ISA was configured to provide DNS names in the WPAD script…”

    My question is this applicable to and will it function in TMG 2010 as well?

    Also, will you be required to issue the SETSPN statement for each of your proxies in the array?

    So, for example, using your above screenshot did you have to enter the following?

    setSPN -U -A http/tmg.richardhicks.com
    setSPN -U -A http/tmg2.richardhicks.com

    I guess I’m wondering is it still possible to allow for WPAD autodiscovery and allow for Kerberos by doing the following:

    1) Using the FQDN’s instead of IP’s in the MakeProxies function by running the above script,
    2) Issuing the SETSPN statement for each of the FQDN’s in the MakeProxies list.
    3) Somehow make the MakeProxies function return only the FQDN NLB VIP address so that Kerberos will work.

  3. February 17, 2012 at 9:45 am

    The script returns IP addresses as opposed to FQDNs or single-label hostnames by default to reduce errors associated with name resolution. For Kerberos authentication to work properly, the request must be made using FQDN in order to build the correct SPN, hence the requirement for the script to return hostname/FQDN. This changes, however, if you wish to use the NLB VIP to handle web proxy requests. If you configure Forefront TMG 2010 to support Kerberos authentication with NLB, using WPAD produces unexpected results because the script returns the IP or name of individual array members, to which (as you deduced) the client sends its requests to directly. If you want to use WPAD and NLB together, you’ll have to follow the steps in this article to configure a custom script file that only provides the VIP or a name/FQDN that resolves to the VIP.

  4. February 17, 2012 at 9:49 am

    Yes, this script works with Forefront TMG 2010 in addition to ISA 2006. There is no requirement to configure SPNs for array members, as they are already registered in the Kerberos database. The only time you need to configure SPNs is when you are using a name that is not the hostname of an array member (for example, the array DNS name). If you want to use WPAD *and* have all requests delivered to the VIP, you will have to use a custom script file.

  5. February 17, 2012 at 12:48 pm

    In your experience, do you typically see most clients using GPO’s to distribute the proxy name to web browsers?

    Since this would not use WPAD this would then allow them to utilize Kerberos (I’m assuming that they would just run that script to change the MakeProxies behavior to return FQDN’s instead of IP’s).

    My next question is, if you indeed do see clients using GPO’s to point to the proxy server, how do you handle it when a laptop user leaves the office? Won’t the web browser continue to try to hit the proxy server as served-up by the GPO if the web browser is launched outside of the office?

  6. February 17, 2012 at 4:47 pm

    I wouldn’t say “most” clients, but I’ve worked with quite a few customers to enable group policy to configure their web proxy client settings. Using GPOs does workaround the WPAD issue we’re discussing here, but as you correctly observed, this is a potential sticking point for mobile devices that need to connect to the Internet outside of the office. In cases like this I’ve actually seen organizations deploy a PAC file on the local file system which is configured to use a direct connection if the proxy server is unavailable. The PAC file is distributed via logon script or any other file replication mechanism.

  7. February 17, 2012 at 5:12 pm

    Does the login script deploy a manually configured PAC file? If so, how is it kept updated as changes are made to the ISA/TMG array?

  8. February 17, 2012 at 7:07 pm

    Yes, it is a statically updated file. You could probably update it using some type of file replication I would guess…

  9. Artem
    March 22, 2012 at 2:05 am

    Hello Richard.
    I dont understand,if i enable kerberos, without changing the WPAD file will kerberos auth works well? Or it will be fall back to NTLM?

  10. April 2, 2012 at 4:30 pm

    If the automatic configuration script returned by the Forefront TMG 2010 firewall returns IP addresses for array nodes instead of FQDNs, Kerberos authentication will fail and it will fall back to NTLM. If you want to ensure that Kerberos authentication is used, run the script on your TMG firewall to configure it to return FQDNs instead of IP addresses.

  11. December 4, 2012 at 2:30 pm

    Richard, following back around to see if there has been any change to this behavior? Is a custom script file still required? Or, has Microsoft given us the ability to populate the WPAD.dat file with FQDN’s instead of IP’s so that we can still utilize Kerberos with NLB without writing a custom script file?

  12. December 5, 2012 at 8:35 am

    No changes here, Mike. Although you can configure the Forefront TMG 2010 firewall to return FQDNs for each array member in the WPAD script, you can’t make it return an alias that would resolve to the VIP. That will still require the use of a custom WPAD file, unfortunately.

  13. KingBuzzo
    April 25, 2013 at 7:50 am

    I am seeing frequent ntlm authentication failures in IE so I tried your method to force Kerberos although it seems my setup is a bit different.

    Do I still need WPAD if I am using the F/W client? The F/W client automagically configures IE to use the VIP.

    Providing authentication by AD groups for specific content filtering is why we are trying to implement TMG and it doesn’t make sense to me why it isn’t as easy as we thought!


  14. April 26, 2013 at 3:21 pm

    This article specifically pertains to enabling Kerberos authentication to work when you’ve enabled NLB and you want your clients to connect to the VIP. In your case, all you need to do is make sure your clients, including your firewall clients, are using the FQDN to communicate with the Forefront TMG 2010 firewall and not the single label hostname or IP address. You can control the behavior of the firewall client enforced IE settings by updating the settings of the Internal network properties. See the “Internal Network Properties” section of my article on ISAserver.org:


  1. June 7, 2012 at 2:15 am
  2. September 7, 2013 at 12:39 am
Comments are closed.