If you would like to read the other parts in this article please go to:
- Considerations for Replacing your TMG Firewall (Part 1)
- Considerations for Replacing your TMG Firewall (Part 3)
- Considerations for Replacing your TMG Firewall (Part 4)
- Considerations for Replacing your TMG Firewall (Part 5)
In part one of this article series, we began the discussion about what you might want to think of when you are evaluating new firewalls to replace your TMG firewall, now that Microsoft has announced that there will be no further development on TMG. There are literally hundreds or even thousands of firewall features that you could consider, but we don’t want to go through each and every one of those. Instead, what we’re going to try to do here is look at what the most essential and more important features are that we depend on in the TMG firewall and call them out and discuss their capabilities, so that you can be able to more clearly determine whether those capabilities are available in other firewalls that you’re considering as TMG replacements.
As a reminder, here is the list of basic TMG firewall capabilities that we started with last week:
- Inbound SSL Bridging
- Outbound SSL Bridging – SSL inspection
- Pre-authenticating and delegating Web Proxy
- SSTP VPN Server – remote access client VPN server
- Site to Site VPN server
- Winsock Proxy
- URL Filtering
- Web Antimalware
- Multi-ISP connectivity
- Network Load Balancing – HA support
We’ve already talked about inbound SSL bridging and outbound SSL bridging (SSL inspection) in Part 1. Let’s begin this section with the pre-authenticating and delegating Web Proxy capability.
Pre-Authenticating and Delegating Web Proxy
One of the primary roles for many TMG firewalls is the performance of web proxy services. You might recall that in earlier discussions on this site, we discussed how a web proxy is quite different from a NAT device. A NAT device only looks at the network and transport layer headers and makes substitutions to those so that public address clients can access private address resources, and vice versa. There is no protocol level manipulation above the IP and TCP/UDP header when you’re dealing with a NAT-only device.
How the web proxy works
In contrast to that, a web proxy looks at the entire content of the communication. It can manipulate network, transport and application layer headers. In essence, what the web proxy does is intercept a communication from a client of the web proxy device, analyze it, and then make any changes that need to be made based on the policy that is configured on the web proxy device. Then it will forward the communication to the intended destination.
In addition to manipulating the packet in such detail, the web proxy device can also provide course and fine grained access control. By coarse grained access control, I’m talking here about the ability to allow or deny a connection to the intended resource. This is one of the most common uses for a firewall and the web proxy capability is no exception. Fine grained access control, on the other hand, is about controlling what the user can do after that user has been given access to the network or to a particular server or a particular service on a server.
For example, suppose a user tries to connect to the Outlook Web App site on your Exchange servers. The type of experience that the user will have should be based on the level of trust for both the user and the device from which the user is connecting. If the user is not connecting from a corporate managed device, then you could create a policy that blocks such users from saving attachments. Or you could detect from which countries the user is connecting and, if the user is connecting from particular countries, you could configure the web proxy to limit the read controls so that RMS mail is not accessible. These are only a few examples. The possibilities are endless.
Authenticating the user
In order to enable any of these access control scenarios, we are going to need to address the subject of authentication. You have to be able to authenticate the user before you are going to be able to make any kind of authorization decisions. This is where web proxy pre-authentication comes in.
There are actually two kinds of web proxy pre-authentication that you need to be aware of, although in most cases when people are thinking of web proxy pre-authentication, they are thinking about a reverse proxy, web publishing scenario. While that is probably the most common scenario in which web proxy pre-authentication is used to provide coarse and fined grained access control decisions, it’s not the only one. The other fairly common scenario for web proxy pre-authentication is the forward proxy scenario, by which internal users (or at least users who are behind the web proxy device) are authenticated before the decisions are made regarding how users will access materials that are “external” to the web proxy device.
The TMG firewall has both of these capabilities, but the its richest feature set comes from its support for web proxy pre-authentication for incoming connections (in other words, its support for reverse web proxy or web publishing). When you create a Web Publishing Rule, you have the option to limit access to that rule to a collection of users, a group, or a collection of groups and users. If someone successfully authenticates with the TMG firewall but is not on that list of authorized users, then the connection will be dropped. This is an example of coarse grained access control.
Another thing the firewall needs to be able to do is perform delegation of authentication. What this means is that the TMG firewall should be able to authenticate on behalf of the external user. This prevents the actual user from directly authenticating with the destination web server; that’s important because doing that could lead to a potential compromise of the web server. Instead, what the reverse proxy needs to be able to do is collect the user credentials, authenticate the user, authorize the user and then forward those credentials to the web server. Then, after the web server says “OK, you’re in”, the TMG firewall will forward the connection to the destination web server.
But prior to the authorization is the authentication. How does the TMG firewall authenticate the user? What protocols does it support? What authentication repositories can you use? How do you secure the credentials exchange process?
The TMG firewall supports a number of authentication protocols, some of which include the following:
- Basic – when you use Basic authentication, the client will be prompted for credentials by the TMG firewall. The TMG firewall will validate the credentials and when it forwards the request to the Web server it will use these credentials to authenticate to the Web server in a manner that is consistent with the configured delegation method. The web server must be configured to use the authentication protocol that matches the delegation method being used by the TMG firewall.
- Digest/WDigest – when you use Digest or WDigest authentication, the client makes a request and then the TMG firewall denies the request and asks the client for authentication information. The credentials are sent to a domain controller for validation.
- Integrated – Integrated authentication uses the NTLM, Kerberos, and Negotiate authentication mechanisms. The current Windows log on information on the client computer is used for authentication. If the authentication exchange fails, the browser will prompt for credentials until the user enters valid credentials or closes the prompt dialog box.
- Forms-based authentication – With forms-based authentication, the TMG firewall accepts clear text credentials from the client and these credentials are used to populate a form. The TMG firewall can then use some type of protocol translation mechanism and forward these credentials to the authentication repository or the destination web server.
- Client certificate authentication – When you use client certificate authentication, the TMG firewall accepts a certificate from the client machine. The certificate must be trusted by both the client and the TMG firewall. The TMG firewall can be configured to set many limiting parameters regarding which certificates it will accept.
Authentication repositories will enable different methods for validating the user credentials. The TMG firewall can validate the user credentials using a number of methods. Some of these include the following:
- No pre-authentication. When you choose to use no pre-authentication, the TMG firewall will not authenticate the user on behalf of the destination web site. Instead, it will let the web site do the authentication. In this case, the TMG firewall simply forwards the connection to the destination web site without concern for the context of the user who is connecting to the web site.
- Active Directory. You can use Active Directory as your authentication repository and support NTLM and Kerberos authentication for the connecting clients. The TMG firewall will authenticate on behalf of the client and then forward those connections to the published web server. The TMG firewall will need to be a domain member in order to take advantage of Active Directory authentication.
- LDAP server. If you don’t want to make the TMG firewall a domain member, but you still want to be able to take advantage of Active Directory authentication repositories, then you can configure the TMG firewall to use an LDAP server. The TMG firewall will authenticate the client against the LDAP server and then forward the credentials to the published firewall, most likely using an authentication protocol translation mechanism.
- RADIUS server. Another option that can be used when you can’t make the TMG firewall a domain member is to use a RADIUS server. The RADIUS server can be configured to use any number of authentication repositories. In that way, you can authenticate both Active Directory and non-Active Directory based users.
- RADIUS OTP. RADIUS OTP uses the OAuth protocol that can be used to authenticate a user in a multi-factor authentication model. The user presents credentials and a one-time password in order to be validated prior to the TMG firewall forwarding the connection to the published web server.
- SecurID. SecurID is another two-factor authentication mechanism that can be used together with user name and password, and can be connected to a number of different authentication repositories.
As you can see, the TMG firewall’s pre-authentication capabilities are flexible and comprehensive, and we’ve only touched the surface of what the TMG firewall can do in this space. Pre-authentication is critical because you never want to allow external users anonymous access to your web servers. Anonymous access could lead to all of the types of exploits that can be generated by anonymous users (DDoS being just one of many). The TMG firewall is much better able to withstand attacks than your web servers are, and thus users should be authenticated at the firewall first.
I haven’t talked too much here about pre-authentication for forward proxy because there is no delegation feature involved. Instead, all the web proxy needs to do is authenticate the user prior to allowing external access. The TMG firewall enables you to perform both coarse and fine grained access control for outbound connections as well, and outbound web access rules can be configured to allow only certain users and groups to have access. What the TMG firewall won’t do is pre-authenticate internal users for external servers.
In this article, Part 2 of a series, we talked about one of the key features in the TMG firewall: the pre-authentication feature. This can be used for both forward and reverse proxy scenarios, but it is most often applied in a reverse proxy scenario because of the pre-authentication and delegation capabilities. We saw that the TMG firewall includes a number of authentication protocols and validation mechanisms that can be used in a heterogeneous environment. Pre-authentication is a very important feature that you’ll need to consider when you are evaluating the firewalls that you’ll be considering to replace your TMG firewall.
If you would like to read the other parts in this article please go to: