Part 1: User Authentication for Forefront Threat Management Gateway (TMG) 2010

Traditional hardware-based network firewalls have one serious limitation - you can't control and track user access unless you are forcing them to perform another layer of firewall login on top of domain desktop login. If you really do, it certainly would cause much unhappiness among your users. On the other hand, if you can't control user access and track them directly from your firewall logs, you won't impress your auditors either. Hence, a simple solution to please both groups is to implement an Active Directory (AD) aware firewall solution.

One such firewall product to be seriously considered is from the maker of AD - Microsoft Forefront Threat Management Gateway (TMG) 2010 with latest Service Pack 1 (SP1). Besides being an AD-integrated firewall, it is also featuring Intrusion Prevention System (IPS), URL content filter, Web content cache and forward/reverse application proxies  - all rolled into one system.

Prior to deployment, various types of user authentication and application supports should be considered. There are 3 types of client setup to be considered:

1. SecureNAT clients that "hide" behind some IP address. Mainly used only for anonymous Internet access. However, it does not support user authentication.
2. Firewall clients (a.k.a TMG clients) that provide proxied winsock connections between the user applications and TMG. It automatically send client credentials with requests, which include Integrated AD authentication,  LDAP authentication, or RSA authentication (OTP).
3. Web Proxy clients supports above authentication mechanisms. However, the only application supported is the Web browser itself. No credentials are supplied if anonymous access is enabled.

From above, you can see that the strongest & most powerful client protection is provided by the TMG clients.

Forefront TMG Installation
The initial TMG setup can be pretty straightforward, as you will be guided by a step-by-step GUI wizard (click here for details). I have configured a test setup using Hyper-V as follows:

Mass Installation of TMG Clients using AD Deployment

To simulate mass deployment on an AD domain, I have assigned the TMG clients (a.ka. software pushdown) to all computers (or users) using Group Policy - Software Installation. For mass deployment, it is also more efficient to use client auto-detection and auto-configuration using information stored in Active Directory or DNS/DHCP (click here for details). AD detection would be preferred. In the absence of AD, DNS/DHCP discovery will be used.

To publish TMG information on AD, you would also need the ADconfig Pack, which can be downloded. To store information on Active Directory, at the command prompt, type: TmgAdConfig.exe add -default -type winsock -url [-f] where the service-url entry should be in the format http://{TMGServer}:8080/wspad.dat.

TMG Client Default Automatic Detection

Enable AutoDiscovery on TMG Management Console

(Networking -> Edit Internal Network -> AutoDiscovery Tab)

DNS Setup

Another important setup to note is the DNS configuration. Just as in normal AD environment, you should configure the TMG server and the clients to reference AD-integrated DNS servers (typically Domain Controllers). Both DC1 and client1 should set TMG server as default gateway. TMG server should have a default route set directly to the Internet.

For testing purposes, you may configure the default forwaders of DNS servers to your ISP name servers.

Firewall Policy

For user authentication testing for Internet access, I have configured the following firewall rules:

There are only 3 rules configured. The first rule is system default generated rule that block users from accessing potentially harmful sites. The second rule is to permit DC1 to forward client DNS requests to ISP name servers. The third rule is to limit HTTP/HTTPS access just to AD users authorised to access the Internet.

Client Testing

To simulate an unauthenticated user trying to access Internet, I login to Win7 client1 using local computer account. As expected, the Internet access is denied for anonymous access as shown under the "Logs and Reports" section of the TMG management console.

Subsequently, I login using a domain user account. Internet access to xin.msn.com succeeded.

Security Considerations for Active Directory Forest

As you can see from above, Forefront TMG succeeded in controlling user access based on Active Directory information. The logs also reveal User Identity and destination URLs instead of merely just client and desintation IP addresses as in most network firewall logs. As the firewall is relying on AD for user authentication and authorization, Microsoft advises further protection using forest segregation and one-way trust in Technet. Below is an extract:

In a domain environment, if Active Directory Domain Services (AD DS) is compromised for example by an internal attack, the firewall could also be compromised because a user with Domain Administrator rights can administer every domain member, including the server running Forefront TMG. Similarly, if the firewall is compromised, the domain in which Forefront TMG is located is also at risk. By default, the Domain Admins group is in the Administrators group on the Forefront TMG server.

At the edge, you can install Forefront TMG as a domain member or in workgroup mode. As a domain member, it is recommended that you install Forefront TMG in a separate forest (rather than in the internal forest of your corporate network), with a one-way trust to the corporate forest. This may prevent the internal forest from being compromised, even if an attack is mounted on the forest of the Forefront TMG computer. However, there are some limitations with this deployment; for example, you can configure client certificate authentication only for users defined in the Forefront TMG domain, and not for users in the corporate internal domain or forest.