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

By /

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

Introduction

We began this discussion on supporting various networking services by delving into the configuration of DNS on your TMG firewall. In the second article in this series, we began our examination of authentication issues by going over a number of issues surrounding domain membership for TMG firewalls. In the third article, we continued on that broad subject, talking about authentication for outbound connections. Now we can cross those subjects off the original list and see what we have left:

Past article:

  • Domain member versus Workgroup
  • Authentication for outbound connections

This article:

  • Authentication for inbound connections

Future article:

  • Authentication for non-Windows clients

In this, Part 4, we’ll continue the discussion by looking at authentication for inbound connections.

Authentication for Inbound Connections

In contrast to the previous article on outbound connections, we’re going to focus now on authenticating inbound connections. But first, let’s ensure we have our terminology defined. What are inbound connections? Some people refer to inbound connections as “ingress” traffic. In the ISA/TMG world, we refer to connections that are initiated by external client systems as inbound traffic. In general, inbound traffic originates from hosts that are located “out there” somewhere on the Internet. However, there are some multi-homed DMZ scenarios in which client systems that are under the control of the organization might generate something consistent with inbound traffic, and we won’t split hairs on this distinction today.

With the TMG firewall, there are two basic ways by which you can enable inbound connections from Internet-based clients to corporate resources that are located behind the TMG firewall. The first method is what we refer to as Server Publishing. The second method is Web Publishing.

Server Publishing

Server Publishing is essentially reverse NAT with some NAT editors/security inspection applied to the connections. For example, you can publish an FTP server using a Server Publishing Rule. When you use a Server Publishing Rule to publish the FTP server, the connection is accepted by the TMG firewall, some protocol verification is performed, and then the connection is forwarded to the FTP server using either the IP address of the original host or the IP address of the TMG firewall as the source address of the connection made from the TMG firewall to the destination server on the corporate network.

Server Publishing works for giving remote workers the access they need, but one thing that Server Publishing Rules don’t allow you to do is authenticate incoming connections. When the inbound connection is made by the external host to the external interface of the TMG firewall, that connection is routed to the internal host without any authentication taking place on the TMG firewall. There is no mechanism included with the TMG firewall that enables this kind of “pre-authentication” at the firewall before the connection is forwarded to the destination server.

Web Publishing

The second method by which you can enable inbound connections to resources on the corporate network is to use Web Publishing. The catch here is that you can Web Publish only a small subset of protocols: HTTP, HTTPS and tunneled FTP. These are the traditional web protocols that are hosted on web servers, hence the term web publishing.

There is a big difference between web publishing and server publishing. While server publishing is at its core just a form of reverse NAT with some application layer inspection, Web Publishing (using Web Publishing Rules) is actually a reverse web proxy process. What that means is that the TMG firewall’s web proxy service will accept the incoming connection, inspect it, and then completely recreate the connection and create a new connection to the destination web server. In its role as “proxy,” the TMG firewall acts on behalf of the client that made the original request. Since the TMG firewall acts as the “new client” in this scenario, it has complete control over how that new request is issued to the destination web server.

Because the TMG firewall has such a large amount of control over these types of connections, it has additional capabilities in this scenario. One of the important capabilities that you can take advantage of is the ability to authenticate the incoming connection when it reaches the TMG firewall. This is often referred to as “pre-authentication” since the TMG firewall authenticates the user before the connection request is proxied by the TMG firewall to the destination web server. If the user successfully authenticates, and if that user is authorized to connect to the destination server (with the authorization being determined by the configuration of the Web Publishing Rule), then the TMG firewall will recreate the request and proxy it to the web server. If either authentication or authorization fails, the connection is denied and dropped.

The same web proxy service that enables you to authenticate outbound connections for web proxy clients on the internal network is used to authenticate incoming connections. However, you have a few more options when enabling authentication for incoming connections, including the use of some higher security options than those you might want to use for outbound connections. The reason for this might be that Microsoft decided that a higher level of security should be applied on incoming connections compared to outbound connections, because the level of trust and risk is higher for incoming connections compared to internal clients.

Authentication options

What are the authentication options that you have available for incoming connections? These include the following:

  • Active Directory
  • LDAP
  • RADIUS
  • RADIUS One-Time-Password (RADIUS OTP)
  • RSA SecurID

Remember the discussion of authentication options in our previous article on outbound authentication? We were only able to use Active Directory and RADIUS authentication for outbound connections. With inbound connections, using Web Publishing Rules, we can also choose from three additional authentication options: LDAP, RADIUS OTP and RSA SecurID. Let’s look at each of our options in a little more detail.

Active Directory authentication

Active Directory authentication is a single factor authentication method that requires only a user name and password. Users will need user accounts in a domain that the TMG firewall trusts, which means the TMG firewall will have to be a member of a domain that trusts the accounts in the domain(s) in which the user accounts are located. Active Directory authentication is popular because it’s easy to implement, but it might not be considered as secure as some of the other options because it uses only single factor authentication.

LDAP authentication

LDAP authentication can be used in the place of Active Directory authentication in circumstances in which you don’t want the TMG firewall to be a domain member. This is a common scenario for organizations that are a bit anxious about putting a domain member firewall on the Internet. While I don’t agree with the level of resistance I’ve seen out there regarding this scenario, there is no doubt that it’s a common issue that needs to be dealt with. This was the primary motivator for Microsoft to create LDAP authentication for incoming requests.

At first glance, you might think that you could use any LDAP enabled authentication repository – and that would be a reasonable conclusion, except for the fact that it’s incorrect. The LDAP authentication method can only use Active Directory domain controllers as their authentication repositories. What this means in practice is that user accounts will still need to be maintained on Active Directory domain controllers, just as with Active Directory authentication. This is also a single factor authentication method. Thus the bottom line is that the big difference between Active Directory authentication and LDAP authentication is that you can use the same user accounts, but the TMG firewall doesn’t need to be a member of a domain that trusts the domain(s) from which the user accounts source.

RADIUS authentication

RADIUS server authentication for incoming connections is similar to RADIUS server support for outbound connections, which we discussed in the outbound connections section. The authentication requests are accepted by the TMG firewall. The TMG firewall then sends the user credentials to the RADIUS server, which in turn sends the authentication information to the authentication repository. In this case, the user accounts don’t need to be domain members per se, but there is some additional configuration that will have to be done. Similar to the situation with LDAP authentication, you can remove the TMG firewall from an Active Directory domain and still authenticate users. You can even take advantage of certificate authentication, although this really isn’t required because user certificate authentication can be performed by the TMG firewall itself; however, RADIUS can extend this support.

RADIUS One Time Password authentication

RADIUS OTP is a form of two-factor authentication that you can use to increase the level of security for RADIUS authentication attempts. The TMG firewall can use a RADIUS one-time password to validate credentials for incoming requests to published Web servers. One-time password mechanisms typically consist of physical devices (often referred to as “tokens”) and a server. Both the server and the devices produce a new password or “passcode” at a pre-defined frequency. The passwords are tied to each device (this is done to insure that two devices don’t share the same passcode, which would obviously present a security risk). The server that validates the passcodes is installed on a RADIUS server and can be associated with the existing list of RADIUS users. RADIUS OTP does take more time to set up and configure, and there are the associated costs that are related to the physical devices that the users must keep on their persons. But as a two-factor authentication method, it’s going to be more secure.

RSA SecurID

Finally, there is RSA SecurID. This is another two-factor authentication mechanism that works similar to RADIUS OTP, except that it doesn’t use a RADIUS server. Instead, it relies on a 128 bit “token” (which can be a USB dongle or a software token) that generates authentication codes at 60 second intervals (or other fixed intervals) and creates one-time passwords. Users must have both the token and a PIN that they enter to authenticate.

Summary

In this article, we took a look at the authentication options that are available to you for inbound connections. In contrast to outbound connections, where you can enforce authentication for all connections using virtually any protocol, with inbound connections you are limited to authenticating only those connections that are handled by the TMG firewall’s web proxy server – and this therefore limits you to HTTP, HTTPS and HTTP-tunneled FTP. However, to make up for this limited protocol support in some way, you are given a wider variety of authentication options. Thus you get a consolation prize of sorts. I hope you enjoyed reading and learned something from this article. See you next month! –Deb.

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

About The Author

Debra Littlejohn Shinder is a technology and security analyst and author specializing in identity, security and cybercrime, utilizing her past experience as a police officer and police academy/criminal justice instructor. She has written numerous books and articles for web and print publications and has been awarded the Microsoft MVP designation for fourteen years in a row.

Read Next

Static vs Dynamic IP Address

Static vs Dynamic IP Address

Most people are familiar with Internet Protocol (IP) Addresses, but many people don’t know you have 2 types. In this article, you’ll learn about static…

Read More »

Leave a Comment

Your email address will not be published. Required fields are marked *

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

Scroll to Top