Publishing Exchange 2010 with TMG

Posted: August 15, 2011 in Exchange, ISA/TMG Server, Security

Part I: Introduction and Creating the array

During a recent Exchange 2010 migration project, I found that while there are many resources online to assist with publishing Exchange 2010 using TMG, none covered my scenario very well and most were missing details that were needed to make the solution work as I desired and intended.

Since I believe that this specific scenario is common, I will outline the specific details of the installation in a series of posts covering the whole process as well as a couple of sticking points that require a few extra tricks to address.

Please note that these guides are not intended as an exhaustive step-by-step manual for this process but rather as a set of tips, tricks and guidance for anyone who is already familiar with Exchange 2010 and TMG and the overall publishing process.

The environment

Exchange 2010 with Service Pack 1 is deployed using several mailbox servers in a single DAG hosting all mailboxes. The HT and CAS roles are hosted on two shared servers. The servers are load balanced across all ports. A CAS array was created (along with a DNS record) and point to the load balancing VIP.

Note: This post does not include a detailed discussion of load balancing. The information provided should apply equally well to WNLB and a hardware load balancer.

Two TMG 2010 Enterprise servers are deployed in a DMZ with a single interface to be used as reverse proxy servers only. The TMG servers are load balanced across ports 80 and 443.

The servers are all protected using a SAN certificate that includes the intended OWA/OA/EAS URL: webmail.domain.com and the Autodiscover URL autodiscover.domain.com as well as the FQDNs of the CAS/HT servers.

Deploying TMG – Installing the array

Extending the high availability options provided by Exchange 2010 to TMG is a key part of any implementation of the platform. No point in ensuring no single points of failure in the Exchange system if one of the primary access methods (OWA, ActiveSync, etc.) is a single point of failure.

TMG provides three options for high availability:

  • Manual – this option includes multiple TMG Standard edition servers that are load balanced but not aware of each other. Rules are synchronized manually across servers.
  • Partially automated – by leveraging the Enterprise edition of TMG, the servers can share an array configuration database that is stored on one server and replicated to the other. This option is known as a standalone array. A manual process is required to failover the configuration database to the other servers.
  • Fully automated – An enterprise array can be created by offloading the configuration database to another system (or ideally, multiple redundant systems). This configuration is a fully automated cluster.

I typically prefer the partially automated solution as it doesn’t require any additional systems but avoids the potential for user error and misconfiguration. Since the configuration information is loaded into memory on each TMG server, access to the database itself is only needed when making configuration changes so a manual failover is a very acceptable risk.

Preparation steps:
  • Confirm that each node can resolve the FQDN of the other node (by using DNS or hosts file)
  • Confirm that the user account you are logged on as is the same on both nodes (same name and password)
  • Confirm that both TMG servers are joined to the same workgroup
Certificate Configuration

If the servers are part of a DMZ domain, you can use an Enterprise CA to configure certificates. Since in my experience a DMZ CA is rare, this post uses self-signed certificates to authenticate TMG servers to each other

Generate the certificates using the makecert utility:

makecert -pe -n “CN=TMGArrayRootCA” -ss my -sr LocalMachine -a sha1 -sky signature -r “TMG Array Root CA”

makecert -pe -n “CN=TMG01.dmz.com” -ss my -sr LocalMachine -a sha1 -sky exchange -eku 1.3.6.1.5.5.7.3.1 -in “TMGArrayRootCA” -is MY -ir LocalMachine -sp “Microsoft RSA SChannel Cryptographic Provider” -sy 12 “TMG01.cer”

makecert -pe -n “CN=TMG02.dmz.com” -ss my -sr LocalMachine -a sha1 -sky exchange -eku 1.3.6.1.5.5.7.3.1 -in “TMGArrayRootCA” -is MY -ir LocalMachine -sp “Microsoft RSA SChannel Cryptographic Provider” -sy 12 “TMG02.cer”

Once the certificates are generated, use the Certificates MMC to export the certificates, copy them to each TMG server and install them as follows:

  • Import the TMGArrayRootCA certificate into the trusted root certificate folder
  • Import TMG01 and TMG02 into the personal certificate folder

Finally, using TMG console browse to System and select the Install Server Certificate task in the action bar on the right.

To verify the certificate installation use the Certificates MMC focused on the service account and select ISASTGCTRL as the service. The personal folder should contain the certificate the active array manager.

Array Creation
  • On node 2 <TMG02.dmz.com> open TMG console and select ‘Join Array’ from the tasks on the server node
  • Select the Standalone array and point to the IP of node 1 and enter the administrator credentials.
  • Confirm that the root CA is already installed on the server and complete the installation. This process will create the array and join the second node to it.
  • Restart all servers (array manager and the array managed)
  • After each system comes back up, open the TMG console and open the properties of the server node. In the intra-array credentials tab select the workgroup option and enter the required credentials

This completes the TMG installation and prepares the environment for publishing Exchange services, the topic of part 2 of this post.

Advertisements
Comments
  1. Luis says:

    Hi, thanks for this post. I’ve a question about certificates when TMG its in DMZ. If I’ve a forest, with 3 or 4 subdomains, the certificate is the same for subdomains or I need to create a certificate for each other domain???

    Thanks a lot.

    • Guy Yardeni says:

      Hi Luis,
      Thanks for your comment/question.

      First, we have to make sure we’re talking about the same certificate. The SSL certificate that validates the TMG and CAS servers to clients on the Internet should not have dependency on your internal domain structure. It should simply be using the same name as the DNS record that points to the TMG server along with any applicable SANs. Likewise, the certs used between TMG array domain members do not have any relation to the internal domain structure.

      The certificate that does depend on our internal structure is the one being used for LDAPS into the internal system. In this case, you need to make sure that the TMG server trusts the certificates assigned to each domain controller it will use. If you have an internal PKI as part of your forest that’s the easiest case. If the TMG is joined to a forest domain, no action is necessary. If the TMG server is not joined to the same forest as the PKI installation, then the root and issuing CA certificates from the forest must be exported (without private key) and imported in the Trusted Root Publishers store on the TMG server.

      So in both cases, no issue with child domains. The one area to look out for with multiple domains is with the LDAPS configuration itself when the server entry is configured on TMG. The easiest way is to use the GC protocol and educate users to use their UPN for logins since those are not domain specific. Otherwise, server entries must configure for DCs for each domain with the appropriate credential pattern: domain\username.

      Hope this helps but feel free to ask additional questions,

      Guy

  2. Luis says:

    Thanks for your quick response.

    When I talk about certificate, I want to say internatl certificate, for validate users from TMG to Domain controllers.

    We want to install TMG for publishing OWA.Now I have another question. In LDAPs scenario with child domains, with internal certificate create from interl PKI,, If its possible to enable users change password???

    Thanks a lot.

    Regards, Luis.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s