Considerations for the TMG Firewall in Supporting Services (Part 3)

If you would like to read the other parts in this article series please go to:


We’re back to continue our foray into authentication issues for TMG. In the previous article, Part 2 of this series on supporting services, I addressed many of the questions that come up surrounding the question of domain membership (or not) for TMG firewalls. I hope that you found it entertaining and/or useful and that it added some new value to the discussion or at least reminded you of some core issues that you might want to consider if you’re in the market for revisiting the issue of domain membership for your TMG firewalls. We can now check that subject off the list I gave you regarding subject matter for this discussion about supporting authentication services. Let’s see what we have left:

Past article:

  • Domain member versus Workgroup

This article:

  • Authentication for outbound connections

Future article:

  • Authentication for inbound connections
  • Authentication for non-Windows clients

As indicated by the arrow, in Part 3 of this series, we’ll take a look at authentication for outbound connections.

Authentication for Outbound Connections

You know that the TMG firewall can control outbound access (which is sometimes referred to as “egress traffic) based on the authenticated user. This allows you to create Access Rules on the TMG firewall that enable you to control which users can access which sites, using which protocols, at which times of day (and there are some more options too, but those are probably the most commonly used ones). This level of access control allows you to give some users wider access to Internet-based resources than what you give other users. Most TMG firewall administrators who are concerned about security will apply the principle of least privilege, which means you give users access to those resources that they need to do their jobs, but no more.

The Changing Paradigm

Least privilege for Internet access was a big subject years ago when the ISA and subsequent TMG firewalls were developed. At that time, the attitudes of many organizations toward Internet access were very different from today. In fact, if you recall, many companies considered the Internet to be a “necessary evil.” When you fast forward to today, in this age of cloud computing and universal, always-on access is pretty much a given.

Many employees now consider Internet access a “right” and if you put limits on what people can access (other than pornography, pirated music/movies/software and other socially unacceptable or illegal content), you might just make them less effective at work instead of more effective. This new viewpoint on the need for Internet access on the job is even more important when you consider that people now use social networks heavily not just to socialize, but to find answers to difficult questions. Savvy businesses are coming to see that blocking access to social networking sites could actually put organizations into an uncompetitive situation.

So in this new paradigm, we might say that user/group based access control isn’t the iron-clad solution it used to be. Does that mean that there’s no value to it? I wouldn’t go that far, even if you have a very open network where you allow users to do essentially what they want to do on the Internet. A big value of user/group access control, by using user/group authentication via the TMG firewall, is that you have comprehensive user-associated log files indicating what individual users are doing on the Internet and when they’re doing it. That information can be very useful, especially in tracking down internal security threats (whether deliberate or inadvertent).

Internet client types

Regardless of whether or not you want to use user/group based access control to actually limit what users can do with your Internet connection, you need to understand some basic components of how it works. It is essentially based on the type of “client” that connects to the Internet through the TMG firewall. As I’m sure you know, there are three “client types.” These are:

  • SecureNAT client
  • Web proxy client
  • Firewall client (called the TMG client with TMG, but most ISA/TMG admins still call it the firewall client)

Let’s briefly review the basics.

The SecureNAT client doesn’t authenticate with the TMG firewall. SecureNAT clients are just devices that are configured to use the TMG firewall to access the Internet based on the routing configuration and default gateway settings on the client.

The Web proxy client is a device that is configured to use a web proxy server for HTTP/HTTPS access. Typically this is done through the browser configuration on Windows devices, but non-browser applications can also be configured to use the web proxy client configuration. When the application is configured to use a web proxy, it will forward the HTTP request directly to the TMG firewall using the port configured the TMG firewall that listens for web proxy client connections. When the TMG firewall accepts the request, it runs the request through its Access Rules and if allowed, it will recreate the request and forward it to the destination server. It then receives the response and forwards the response to the client. The web proxy service on the TMG firewall can perform authentication on the client request to see whether or not it’s allowed.

A similar sequence of events takes place with the Firewall client. The difference here is that the Firewall client is a Winsock proxy client application that you have to install on the client systems. After you install it, it will automatically intercept calls from Winsock applications and forward (remote) the network calls to the TMG firewall. The firewall service on the TMG firewall will accept these requests, run them through the Access Rules, and if allowed, will proxy those requests to the destination server. The TMG firewall then receives the response and forwards that response back to the client that made the request. The big difference between the web proxy and Firewall clients is that web proxy only works with “web” protocols (HTTPS/HTTP/HTTP tunneled FTP and other HTTP tunneled protocols). In contrast, the Firewall client will work with almost any protocol you throw at it.

Authentication options

Now that we have a basic understanding of the clients, we need to consider the authentication options that are available to you. For the Firewall client, your authentication options are pretty limited. The client must be a domain member and it must be in a domain that is trusted by the TMG firewall. That means that both the client and the TMG firewall have to be domain members. That’s it – there are no other options. If you have non-domain member clients and you want them to access the Internet, you’ll either have to create an access rule that applies to them and doesn’t require authentication (the exception being if you want to configure those as web proxy clients), or you don’t let them have outbound access. A nice thing about domain membership is that you never get prompted for credentials, because both the client and server can use Active Directory based authentication protocols.

Web proxy clients are a bit more flexible when it comes to authentication options. In this case, you can configure the TMG firewall to use integrated Windows authentication (which requires domain membership), or you can use RADIUS authentication or LDAP authentication. When you use RADIUS authentication, you can configure the TMG firewall to use a RADIUS server to forward the authentication requests to an authentication repository, so the TMG firewall doesn’t have to belong to the domain. Similarly, you can configure the TMG firewall to use an LDAP server to authenticate outbound web proxy requests. The thing to note here is that the LDAP server can’t just be any LDAP capable server – the LDAP server has to be an Active Directory domain controller. Gotcha! I know many people were disappointed by this, but that’s how it works and they aren’t going to change it at this point.

The user experience is going to be different depending on the authentication method the web proxy uses. If you make the TMG firewall a domain member, and the clients are in a trusted domain, then the users won’t see any authentication prompts. However, if you use RADIUS or LDAP, the user credentials aren’t transparently forwarded to the TMG firewall, so the users will need to enter the credentials themselves and may see multiple authentication prompts.

Some of you might be interested in certificate authentication. Wouldn’t it be great if the clients could authenticate with the TMG firewall using a user certificate, and maybe even a computer certificate too? Yes, that would be great! Unfortunately, the TMG firewall doesn’t support this configuration for the web proxy clients.

Well, never say never. There is one scenario where you can have a computer identify itself using a certificate for authentication. That is a very specific scenario where the TMG firewall needs to authenticate with a TMG firewall in front of it – in a scenario called “web proxy chaining.” It was a very compelling configuration back in the old day, but those days are over and I haven’t seen anyone use that configuration for quite a while.


In this, Part 3 of our series on supporting services and the second part of our discussion of authentication issues, we looked at authenticating outbound connections. I hope you have a better understanding of the authentication options available to you based on the client type you’re using, and some of the requirements for the TMG firewall. In Part 4, we’ll talk about authentication options for inbound connections. See you then! –Deb.

If you would like to read the other parts in this article series please go to:

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top