Help
Now that you have Forefront Threat Management Gateway up and running, it's time to configure your protected networks. This excerpt from Diogenes, Harrison, & Saxena's Forefront Threat Management Gateway (TMG) Administrator's Companion will guide you through the process.
All networks behind TMG are known as protected networks. These networks are protected from the default external network (which is usually the Internet), which is considered an unprotected network. You can't think of the Internet as a network where you can transmit your data in plain text and believe that you are safe. This is just like going to a war zone inside a bulletproof tank thinking that you are safe just because you are inside the tank. Figure 11.29 shows an example of the network layers and categorization.
As shown in Figure 11.29 the protected networks can be located in the local LAN right behind TMG, or they can be located in remote offices where you have a private WAN link connection. In this case the only path to the unprotected network (Internet) is by sending the traffic through TMG Firewall. In other words, the only device that should have direct access to the protected and unprotected networks is TMG Firewall.
When you first install TMG and select the networks using the Getting Started Wizard, you define the core parameters so that TMG can identify what is considered a protected network and what it is not. To determine this, TMG relies on the template that you choose in the wizard and also the networks that you associated with each network interface.
After running the Getting Started Wizard and the Web Access Wizard, you are ready to use TMG. However, you can configure some additional options afterward. To access the options for the internal protected network, follow these steps:
On the TMG computer, open the Forefront TMG Management Console.
Click Forefront TMG (Server Name) in the left pane.
Click the Networking node in the left pane of the console and then click the Internal tab in the middle pane.
-
Click Edit Selected Network in the right pane and you should see a dialog box similar to the one shown in Figure 11.30.
On an Enterprise edition, the Internal Network properties have the following configuration options:
-
Addresses Allows you to configure the IP addresses that define the network.
Domains Allows you to specify what domains are considered internal. This is used for the TMG Client to know that the traffic for domains specified in this tab should be sent directly to them.
-
Web Browser This tab has the parameters that determine how TMG handles traffic coming from Web Proxy Clients.
-
Automatic Discovery On this tab you can enable automatic discovery for TMG Clients and Web Proxy Clients.
-
TMG Client This tab allows you to configure parameters that will be used by Firewall Clients.
Web Proxy Here you configure which port TMG will listen on for Web Proxy requests and also how it will handle authentication. We will cover authentication options in this chapter.
-
CARP This tab allows you to enable the cache array routing protocol to balance Web requests and cache content across members of the array.
-
NLB This tab allows you to enable Network Load Balance capability in TMG.
When TMG receives traffic coming from this network you also have a chance to authenticate the user that is sending the connection request.
In an enterprise environment one common requirement is to authenticate users before they have access to the Internet. This requirement is part of access control requirements established by company security policy. As the TMG administrator, you have to make the system compliant with policy. TMG provides two methods of authenticating user requests for Web access:
Globally at a network listener
Per firewall policy rule
At the network listener you can specify the authentication method, whereas at the firewall policy level you specify the user or group that needs to authenticate. When TMG receives the user's request, if authentication is required from the network where the user sent the request, TMG evaluates the rules to find a rule that matches with the request. At that point, if the user's credentials are denied by the authenticator (Active Directory, for example) the request is denied and no other rules are evaluated.
To access the authentication options for the default internal network in the Web proxy traffic scenario, follow these steps:
On the TMG computer, open the Forefront TMG Management Console.
Click Forefront TMG (Server Name) in the left pane.
Click the Networking node in the left pane of the console and then click the Internal tab in the middle pane.
Click Edit Selected Network in the right pane.
-
Click the Web Proxy tab and then click the Authentication button. You should see a dialog box similar to that shown in Figure 11.31
Multiple authentication methods are available; however, the default method is integrated. The method in use dictates the way TMG validates users requesting access to the resource.
Digest authentication relies on the HTTP 1.1 protocol to work properly. This means that the Web browser needs to support HTTP 1.1. Requests sent by non-HTTP 1.1–compliant browsers will be rejected. This authentication method works only with Microsoft Windows Server 2000 and later domains.
The restriction imposed by this authentication method will be brought to your attention when you enable this method, as shown in Figure 11.32.
WDigest was first introduced in Windows XP (Wdigest.dll) and inherited in Windows Server 2003. WDigest has some unique characteristics, such as:
The user name and domain name are case-sensitive, which differs from Digest, Basic, and Integrated authentication. This means that the user name needs to be typed exactly the way it was registered when administrator created the user account in Active Directory.
It requires that the value in the resource part of the URL path is explicitly specified. For instance, let's say the user sends a HTTP GET for http://host.contoso.com. This request will fail because the URL resource (/index.htm in this example) is missing.
When TMG is a member of a Windows Server 2003 or later domain and the authentication method is set to Digest, TMG will use WDigest by default. The primary advantage of WDigest over Digest is that WDigest does not require that reversibly encrypted copy of user's password to be stored in Active Directory. For more information on how Digest and WDigest authentication work on the Windows operating system level, review the article at http://technet.micro...y/cc780170.aspx.
Integrated authentication allows TMG to use Windows Security Support provider (SSP) to validate user credentials. This authentication method supports the use of Negotiate, NTLM, or Kerberos authentication. The advantage of these authentication methods is that user passwords are never sent across the network in readable form, if at all.
When you use basic authentication, user names and passwords are sent through the network in encoded format, but no encryption is used. This means that this authentication method is the weakest of all those available. Some people think that because basic authentication uses Base64 encoding, the information is secure. It is not—encoding is not encryption. If a Base64-encoded password is intercepted over the network by a network sniffer, that password can be decoded and accessed.
By enabling basic authentication, you can be vulnerable because credentials traverse the network in a weakly encoded format. You might wonder why people use this method. People use basic authentication because it is compatible with the majority of browsers and applications in use today. It is possible to overcome this weakness by adding SSL on top of HTTP to encrypt the traffic and protect the credentials.
When you select this authentication method in the authentication window, the message shown in Figure 11.33 appears.
This informational dialog box alerts you to the dangers of enabling this authentication method on a protected network. If you confirm that you want to use this method by clicking Yes, you will notice that in the Authentication Servers section in the Authentication dialog box as shown in Figure 11.34, the Select Domain button now is enabled. This is because when the user sends credentials, TMG uses the default domain for Basic authentication.
For example, when a user (Bob) sends a request to access a resource, TMG appends its own domain (contoso) to the request and forwards the authentication request as CONTOSO\BOB. If the Select Domain button is now available, you can click it and add the domain you want TMG to use for authentication purposes, as shown in Figure 11.34.
Also known as client certificate authentication, this method uses a certificate provided by the client. TMG uses this certificate to validate the client's credentials and capability of accessing the resource. This certificate could be embedded in a smart card or it could be used by a mobile device to access Microsoft Exchange using ActiveSync.
If you enable this option without an SSL certificate installed on TMG, the message shown in Figure 11.35 appears.
Remote Authentication Dial-In User Service (RADIUS) is a network protocol specified in RFC 2865 to be used as a centralized authentication repository. TMG can act as a RADIUS client and send user credentials and connection parameter information to a RADIUS server. The RADIUS server evaluates the request and authenticates the RADIUS client (TMG) request, and sends back a RADIUS response message.
When RADIUS is used as the authentication provider, the traffic between client application (Internet Explorer, for example) and TMG will be authenticated using HTTP-Basic. This is an important point to understand because HTTP-Basic passes the user name and password without encryption. When you use RADIUS as an authentication provider for a Web publishing scenario, you can enhance security by using HTTPs. This way all traffic from TMG to the client will be encrypted.
When you enable this option, you must specify the RADIUS Server that will be used by TMG. To do so, click the RADIUS Servers button. Figure 11.36 shows the RADIUS Servers dialog box.
Because no RADIUS Server is yet configured, you need to click Add to create a new definition for the server. Figure 11.37 shows the Add RADIUS Server dialog box.
This dialog box allows you to specify the RADIUS Server's information, such as server name (or IP address), a shared secret that will be used between RADIUS Server and RADIUS Client (TMG), the authentication port (1812 by default), and what the timeout will be (five seconds by default).
You can create multiple RADIUS Servers and TMG will use them in order, checking the list from the top down, to authenticate the request.
The Require All Users To Authenticate option was misinterpreted for many years by ISA firewall administrators. The myth was that if you disabled this setting, users wouldn't be able to authenticate, which is not true. User requests will still be evaluated according to the authentication method used by the network and the firewall rule that applies to the user's request.
Enabling the Require All Users To Authenticate option simply means that you cannot have anonymous access coming from this network. This means that if you need to allow one group of computers to have anonymous access to a particular Web site and you create a rule to allow this, the rule will be superseded by this setting. This option has priority over any authentication setting that you specify in the firewall policy level.
In addition to this scenario, some other issues might arise when you use this option, such as:
Users are randomly prompted for authentication. When a connection request matches a firewall policy rule that allows anonymous access and this option is enabled, TMG will send an authentication request to the client because this setting indicates that no anonymous requests are allowed.
SecureNET Clients cannot access resources. Because SecureNET doesn't provide credentials to TMG, the requests originated by those clients will be denied.
The comprehensive, one-volume guide to deploying and managing Microsoft® Forefront® TMG for Web security, network perimeter security, and application security.
