Introduction
A common requirement in enterprise networks is to require authentication before users are allowed access to the Internet. This should be part of the access control requirements that are established by your corporate security policy. As the TMG firewall admin, you then have to configure the firewall to support those policies. In this article, we’ll look at how TMG can authenticate outbound web requests and how you configure it to do so.
Methods of authentication
The TMG firewall provides two methods for authenticating outbound web requests:
- Via a global configuration setting on the outbound web proxy listener
- On a firewall rule by rule basis
At the Web listener level, you can specify the authentication method, while at the firewall rule level you can specify the user or group that is allowed outbound access. When the TMG firewall receives the user’s request, if authentication is required from the Network to which the user sent the request, the TMG firewall evaluates the firewall policy set to find a rule that is a match with the request. At that point, if the user’s credentials are denied by the authentication repository (for example, Active Directory) the request is denied and no other rules will be evaluated.
To access the authentication options for the default Internal Network in a Web proxy traffic scenario, you perform the following steps:
- On the theTMG firewall, open the Forefront TMG firewall console.
- Click Forefront TMG (Server Name) in the left pane of the console.
- 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 the one shownin the figure below.
Figure 1
Multiple authentication methods are available with the default method being Integrated. The method(s) you choose will dictate the way the TMG firewall validates users requesting access to the resource. So let’s take a look at each of these methods and what each involves, as well as caveats for using each.
Digest
Digest authentication requires that you use the HTTP 1.1 protocol. This means that the Web browser needs to support HTTP 1.1. Any requests that are sent by non-HTTP 1.1–compliant browsers will fail.
It’s important to note that this authentication method works only with domain accounts in networks that operate in Windows Server 2000 mode and above. You will be reminded of this requirement when you enable this method, as shown in the figure below.
Figure 2
WDigest
WDigest was first introduced in Windows XP (Wdigest.dll) and then moving forward, it was supported in Windows Server 2003 domains. The WDigest method has the following unique characteristics:
- The user name and domain name are case-sensitive in WDigest authentication. In this respect, it differs from Digest, Basic, and Integrated authentication. This means the user name must be typed exactly the way it was typed when the administrator created the user account in the Active Directory.
- WDigest requires that the value in the resource part of the URL path be explicitly specified. For example, 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 the TMG firewall is a member of a Windows Server 2003 or later domain with Digest authentication enabled, the TMG firewall will use WDigest by default. The advantage of using WDigest instead of Digest is that WDigest does not require a reversibly encrypted copy of the user’s password to be stored in the Active Directory, and this represents a security advantage. For more information on how Digest and WDigest authentication work on the Windows operating system level, review the article here.
Integrated Authentication
Integrated authentication allows the TMG firewall to use the 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 names and passwords are never sent across the network in readable form, if at all.
Basic
With Basic authentication, user names and passwords are sent through the network in unencrypted, encoded format. Basic authentication is the weakest (from a security perspective) of all available authentication protocols. Some people once thought (back in the 1990s) that because basic authentication uses Base64 encoding, the information was encrypted. Now we all know that encoding is not encryption. If a Base64-encoded password is intercepted over the network by a network analyzer (sniffer), the password can be decoded and accessed with no extra effort on the part of the person performing the network analysis.
Okay, then why would anyone use Basic authentication if it is so unsecure? The main reason is that Basic authentication is compatible with the vast majority of browsers and applications that are in use today. To solve the encryption problem, most admins use SSL on top of HTTP to encrypt the traffic and protect the credentials.
When you select Basic authentication in the authentication dialog box, you will see the message that appears in the figure below.
Figure 3
This dialog box warns you about the dangers of enabling Basic authentication 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 that is shown in the figure below, the Select Domain button will be enabled. This is because when the client application sends credentials, the TMG firewall uses the default domain for Basic authentication.
For example, when a user (Tom) sends a request to access a resource, the TMG firewall appends its own domain (MSFIREWALL) to the request and forwards the authentication request as MSFIREWALL\TOM. If the Select Domain button is available, you can click it and add the domain you want the TMG firewall to use for authentication, as seen in the figure below.
Figure 4
SSL Certificate
Also known as client certificate authentication, this method uses a certificate that is provided by the client. TMG uses this certificate to validate the client’s credentials and capability of accessing the requested 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.
Figure 5
RADIUS
Remote Authentication Dial-In User Service (RADIUS) protocol is specified in RFC 2865 to be used as a centralized authentication repository. The TMG firewall 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 (the TMG firewall in this example) request, and sends back a RADIUS response message.
When RADIUS is used as the authentication repository, the traffic between the client application (e.g., Internet Explorer) and the TMG firewall will authenticate using HTTP Basic authentication. Recall that HTTP Basic authentication passes the user name and password without encryption. When you use RADIUS as 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. SSL protection is unfortunately not available for outbound connection requests, as the web browser cannot be configured to establish a secure channel to the web proxy listener.
When you enable this option, you must specify the name or IP address of the RADIUS Server that will be used by the TMG firewall. The figure below shows where you add the new RADIUS server information. Click the Add button to add a new RADIUS server.
Figure 6
The figure below shows the dialog box where you add the information about the new RADIUS server.
Figure 7
Here you specify RADIUS Server information, such as the server name (or IP address), a shared secret that will be used between RADIUS Server and RADIUS Client (in this case the TMG firewall), the authentication port that will be used (1812 by default), and what the timeout period will be (5 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.
Require All Users To Authenticate
The Require All Users To Authenticate option was a little confusing to ISA firewall administrators in the past. Many believed that if you disabled this option, users wouldn’t be able to authenticate. That fact is that this is not the case and this setting doesn’t have anything to do with turning off the ability for the web proxy listener to authenticate requests. Authentication requests will still be evaluated according to the authentication method used by the network and the firewall rule that applies to the request.
When the Require All Users To Authenticate option is enabled, it means that all outbound connections must be authenticated – just as the option says. This option has priority over any options that you specify in the firewall policy level. If you want to allow unauthenticated connections outbound, then do not enable this option.
In addition, some other issues might arise when you use this option:
- Random authentication prompts. When a connection request matches a firewall rule allowing anonymous access and this option is enabled, TMG sends an authentication request to the client because this setting disallows anonymous connections.
- SecureNAT clients fail outbound access attempts. Because the SecureNAT client doesn’t provide credentials to the firewall, the requests sent by those clients are denied.
Summary
In this article, we went over the authentication protocols available to you for authenticating outbound web proxy connections through the TMG firewall. We also went over various authentication repositories, such as Active Directory and RADIUS. Finally, we went over the issues involved with requiring authentication at the level of the outbound web proxy listener.
