Forefront Threat Management Gateway - Workgroup Configuration with Exchange 2010

In this post I will give you some information around publishing Exchange 2010 with Forefront Threat Management Gateway (TMG) or ISA 2006 and weather or not these servers should have domain membership.

Microsoft's recommended deployment is that you add your TMG servers as members of your Active Directory domain. For the TMG setup whitepaper please see the following link. This whitepaper explains how to setup TMG step by step with domain membership.

http://download.microsoft.com/download/E/5/6/E56ACB6E-7BCC-40F1-8F18-E636B7BFE088/PublishingExchangeServer2010withForefront.doc

When Microsoft initially released Threat Management Gateway, it did not support workgroup configuration. It's a product that is designed to run as a member of your Active Directory domain and configuring it any other way results in significant loss in functionality and in some cases security. I managed to find a copy of the original release notes published by Microsoft which is available here... stating that TMG does not support workgroup configuration. http://technet.microsoft.com/en-us/library/cc487898.aspx

Previous versions of the product such as ISA2006 did support workgroup configuration and some companies implemented it in this method. There was an outcry and as a result Microsoft changed their stance on this and updated the product to support domain membership.

Can you publish Exchange 2010 using TMG without adding the Threat Management Gateway server as a member of your internal Active Directory domain? Yes you can, there are 3 ways to do this:

- Configure another Active Directory domain to hold TMG. Create a Transitive Forest Trust between your production forest and your TMG forest. Create domain local groups on the TMG Active Directory forest and nest any groups that require access rules inside the TMG forest’s domain local groups.

- Configure an internal PKI, if you want security you need to ensure you have an offline root stand-alone CA, and a subordinate enterprise issuing CA which is AD Integrated. Issue a digital certificate to each domain controller and configure your environment to support LDAP over SSL for AD Authentication. To configure your domain controllers to support LDAPS using SSL see http://support.microsoft.com/kb/321051

- Configure a RADIUS server on your internal network. Configure the TMG server as a RADIUS client to pass through authentication requests to the RADIUS server. The RADIUS server will then pass the authentication request through to Active Directory. You will not get Outlook Anywhere working if your using RADIUS authentication, see http://blogs.isaserver.org/pouseele/2007/02/06/a-quest-for-strong-user-authentication-with-rpc-over-http-services-and-isa-server-2006/

All three of these options have the following disadvantages:

- Will require additional servers weather its certificate authorities, radius servers or domain controllers to run a new AD forest.

- Will extend the project life cycle from an originally estimated 2 weeks to 4-8 weeks depending which of the 3 options you wish to go down.

- Increase complexity of your network and increase downtime periods should infrastructure fail as this is not a highly available deployment.

Neither of these solutions add any significant layer of security and are not seen as efficient solutions due to the Administrative overhead they create.

In a Microsoft whitepaper written by Greg Taylor "Publishing Outlook Anywhere Using NTLM Authentication With Forefront TMG or Forefront UAG", Greg dedicated a section around joining Forefront TMG/Forefront UAG to an Active Directory domain or leaving it workgroup. For a copy of this article see the following URL:

http://www.microsoft.com/download/en/details.aspx?id=22723

Here is an extract from Greg Taylors whitepaper:

"Domain Joining Forefront TMG/Forefront UAG or Leaving in a Workgroup"

In most organizations, the decision whether to domain join the server hosting Forefront TMG/Forefront UAG to your production domain may be one of the more contentious parts of the deployment.

For Forefront UAG deployments, the guidance is clear. Because Forefront UAG is not a firewall, it should be placed behind some other device that acts as a firewall on the corporate network. Also, it's recommended that Forefront UAG be domain joined to make authentication simple and flexible. Forefront TMG is installed on the Forefront UAG computer during installation, but that's done only to protect the host system and for the underlying functionality it provides to Forefront UAG.

Forefront TMG deployments are more complex to discuss because Forefront TMG is considered a firewall and can protect the network edge. Domain joining Forefront TMG offers many advantages: it allows certificate based authentication to be used at Forefront TMG, using Kerberos Constrained Delegation to communicate to Exchange; it allows easy use of Active Directory groups and user objects in publishing rules to restrict access; and it provides other benefits. For an impartial view on whether to domain join Forefront TMG, see Debunking the Myth that the ISA Firewall Should Not be a Domain Member. For more information about identifying your infrastructure design requirements, see Domain and workgroup requirements.

The link Greg Taylor mentions in his white paper "Debunking the Myth that the ISA Firewall Should Not be a Domain Member" by Thomas W Shinder, Microsoft MVP is an excellent read. Please view it here:

http://www.isaserver.org/tutorials/Debunking-Myth-that-ISA-Firewall-Should-Not-Domain-Member.html

In Thomas's article he mentions:

ISA/TMG that is a domain member machine is more secure and more flexible than a non-domain member machine and that they do themselves and their companies a disservice by not joining the ISA firewall to the domain. This is a significant issue and not something to be taken lightly because there is a serious security hit you take when you don’t join the ISA firewall to the domain.

He also covers in his article the primary reason companies go through all this effort of not joining the TMG/ISA server to the internal domain, compliance managers and external auditors that believe in this myth. He writes:

Should the ISA firewall array be placed in a domain or a workgroup? That is the question. Is it nobler to place the ISA firewall in a workgroup where you can avoid the catcalls of clueless compliance managers, "hardware" firewall know-nothings, or “network guys” who think of network security as "port opening and closing", or should you bear the slings and arrows of the same harridan housewives and carping screws for placing the ISA firewall in the domain, where you can get a higher level of overall security and substantially improve your security position?

The last article I would like to point you at is a TechNet article published by Microsoft around considerations when and when not you would place your TMG server as a member of your internal Active Directory domain. Please view this article here:

http://technet.microsoft.com/en-us/library/dd897048.aspx

I would like to finalise by saying majority of TMG deployments should all be a member of your Active Directory domain especially if your just publishing Exchange 2010. However there may be circumstances where your using your TMG server for things other then just Exchange and you may need to look at implementing TMG in a workgroup configuration.

Joining Forefront Threat Management Gateway 2010 to an Active Directory domain to publish Exchange 2010 services to the Internet is not a security threat to your network.