The RDP Files

Part II: Creating the publishing rules

If you’ve read part I of this series, you’ve hopefully got your TMG standalone array up and ready to publish Exchange 2010 services. Before creating the publishing rules themselves, we need to address authentication.

Since our TMG servers are members of a workgroup in the DMZ (same applies if using an AD domain in the DMZ with no trusts to the internal AD forest), we will need to configure a method of authentication. I typically prefer the use of LDAPS since it is supported by default on AD domain controllers and is very simple to configure.

Setting up LDAPS Infrastructure

LDAPS uses a secure lookup to validate users against the AD domain. SSL is used to secure either LDAP (port 389/636) or global catalog (port 3268/3269) queries between TMG and select DCs on the internal system.

The setup steps are as follows:

1. Configure select DCs with a certificate – any DCs that are participating in LDAPS must have a server authentication certificate. This certificate would be deployed automatically by an AD based enterprise CA.
2. Export the trust root certificate from one of the DCs and copy the file over to each TMG server.
3. Import the certificate into the ‘Trusted Root Certificate authorities’ folder on each TMG server.
4. Ensure that firewalls allow traffic from the TMG servers to the selected DCs over ports 636 and 3269.

     A few tips to assist with this task:

• If you just deployed your CA, run the command ‘certutil –pulse’ on a DC to issue the certificate.
• Reboot the domain controller after issuing the CA to activate a listener on ports 636 (secure LDAP) and 3269 (secure global catalog).

Configure LDAPS authentication

Within the TMG console, follow these steps to configure LDAPS:

• Right click on the ‘Web Access Policy’ node.
• Select ‘Configure (Related)’ and then ‘RADIUS Server Settings’
• Select the ‘LDAP Servers’ tab and click the ‘Add’ button to create an LDAP set
• Enter a name for the LDAP set (e.g. Internal DCs), the domain name and credentials used for authentication

NOTE: this account needs minimal rights in AD and a non-expiring password

• Make sure that ‘Use Global Catalog (GC)’ and ‘Connect LDAP servers over secure connection’ are checked.
• Add the selected internal DCs that were used in the preparation steps.
• Define the mask for this LDAP set using ‘domain\*’ for the expression and the created LDAP set and click OK
• Define another mask for this LDAP set using ‘*@domain.com’ for the expression and the created LDAP set and click OK
• Repeat the above steps for any additional domains as needed

Publish Exchange Services

Publishing the services is fairly simple by following the wizard. Here are the steps:

First, to create the listener that will be used for all of the rules:

• Select the ‘Firewall Policy’ folder and the Toolbox tab on the right.
• Navigate to ‘Network Objects’ and right click ‘Web Listener’ to create a new listener with the following info:

1. Name: Exchange 2010 Listener
2. Require SSL secured connections with clients
3. Web Listener IP Addresses: All Networks (and Local Host)
4. Use a single certificate for this Web Listener: select the certificate for webmail.domain.com
5. Authentication Settings: HTML Form Authentication and LDAP (Active Directory) client authentication
6. Enable SSO for Web sites published with this web listener with the name: domain.com

• Open the properties of the recently created listener, select the ‘Connections’ tab and configure the following:

1. Enable HTTP connections on port 80
2. Redirect all traffic from HTTP to HTTPS

Next, to publish OWA:

• Select the Firewall Policy section and from the the ‘Tasks’ tab on the right and click on ‘Publish Exchange Web Client Access’
• Name the rule ‘Exchange 2010 OWA’
• Select the ‘Exchange Server 2010’ version option and check ‘Outlook Web Access’
• Accept the default selection of ‘Publish a single web site or load balancer’
• Accept the default selection of ‘Use SSL to connect to the published server…’
• On the ‘Internal Publishing Details’ page, enter: webmail.domain.com
• Check ‘Use a computer name or IP address to connect to the published server and enter the CAS array FQDN
• Enter the ‘Public Name’ of ‘webmail.domain.com’
• On the ‘Select Web Listener’ page, select the ‘Exchange 2010 Listener’
• Accept the default authentication delegation using ‘Basic authentication’
• Accept the default of ‘All Authentication Users’ and complete the wizard

Edit the recently created rule, select the ‘Paths’ tab and add a new path as follows:

• Folder: ‘/’
• External path: same as published folder

Next, follow the same steps to create the ActiveSync publishing rule. Change only the name and select the ‘Exchange ActiveSync’ option on the ‘Select Services’ page. Adding the root folder path isn’t necessary for this rule.

Then, following same process create the Outlook Anywhere rule with an appropriate name and the ‘Outlook Anywhere (RPC/HTTPS)’ services option. Adding the root folder path isn’t necessary for this rule.

Finally, we need to create a rule for Autodiscover, since that service uses a separate URL and some different options.

• Right click on the ‘Exchange 2010 Outlook Anywhere’ Rule and select ‘Copy’
• Right click on the next rule down and select ‘Paste’
• Edit the new rule and make the following changes:

1. Name: Exchange 2010 Autodiscover
2. Public Name: autodiscover.domain.com
3. Users: All Users (remove Authenticated Users)
4. Authentication delegation: No delegation, but client may authenticate directly

All the services are now published and the only thing remaining is to improve the user experience by configuring redirection to allow any URL to be entered in the browser. The third and final part of this post addresses redirection.

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.