How To Publish Exchange Server 2013 to TMG 2010

How To Publish Exchange Server 2013 to TMG 2010

All articles

In this article, we’ll be discussing things you’ll need to do to configure Forefront Threat Management Gateway (TMG) so that you can effectively publish Exchange Server 2013 to the Internet, providing access to three of its most popular services: Exchange ActiveSync, Outlook Anywhere, and Outlook Web Apps.

With Exchange Server 2013 being out for quite some time, Microsoft has discontinued Forefront Threat Management Gateway (TMG) in December 2012. However, thousands of Microsoft customers are still depending on Forefront TMG to secure their corporate networks. Many of them are not prepared to upgrade their network infrastructure or switch to a different product, but do need a solution to secure their Exchange Server 2013 when publishing to the Internet. Perhaps they are upgrading their Exchange Server 2007 or 2010 to the latest version, or are just adding the Exchange Server component to their network. Whatever the reason, if they have a working solution protecting their network, they can re-use that solution to secure Exchange Server 2013.

The Basics 

Considering the discontinuation of Forefront TMG, I assume you’ve been a TMG user for quite a while. The basic assumption is you have already completed the basic configuration steps such as authentication, certificates, publishing rules etc. All those things apply to everything protected with TMG. They are not unique to Microsoft Exchange Server, and definitely not unique to Exchange Server 2013. If you haven’t performed basic configuration yet, please make sure to read the appropriate beginners guide. 

When you’re done with the basics, let’s move to publishing Exchange Server 2013.

Step by Step 

In order to allow client access to your Exchange Server 2013, you’re about to create proper policies in Forefront TMG to allow HTTPS, POP3, IMAP and SMTP traffic flow securely between your server and the clients. 

Note that there is no Exchange Server 2013 publishing wizard in TMG. However, you can still use the 2010 wizard – with just a few sidekicks. 

Step 1. Create a new Web farm 

Creating a new Web farm is the first step of your setup. Using a Web farm right away instead of publishing load balancer VIPs or single servers allows for easier scalability in the future. Creating a Web farm and adding your 2013 Client Access servers into it is no different than creating a Web farm for 2007 or 2010. Here’s an example:


Step 2: Configure Delegation settings 

The next step of the setup process would be creating the correct delegation settings. Essentially, delegation is what allows TMG to pass (delegate) credentials of the authenticated user to the Exchange Server being published. 

Configuring delegation settings for Exchange ActiveSync

Launch the TMG wizard for publishing Exchange ActiveSync, select the Exchange 2013 CAS Farm as your target, and set the correct delegation setting. 

For the purpose of publishing Exchange Server 2013, your choice of delegation methods is limited to either Basic or NTLM delegation. Other delegation methods are currently not supported for publishing Exchange Server 2013, so make sure to select either Basic or NTLM. For most users, Basic would be the natural choice, unless you want to use NTLM for a certain reason and has enabled the corresponding authorization type in Exchange. 

Configuring delegation settings for Outlook Anywhere

Launch the Exchange Server 2010 Outlook Anywhere wizard. Choose the Exchange 2013 CAS server farm and make sure the ‘Publish additional folders on the Exchange Server for Outlook 2007 clients’ box is checked. 

Step 3: Create the rules

The wizard will create a new rule. Review the newly created rule, making sure that everything appears correct. Open the Public Name tab, and add the autodiscover.company.com name to it. If you are using Basic Delegation, add Basic to the authentication methods enabled on the Client Access Server for Outlook Address Book and Exchange Web Services. That’s it, the rule is ready to work for Exchange Server 2013. 

Step 4: Configure Outlook Web Access

At this point, you have successfully configured delegation and authentication settings to enable client access to Outlook Address Book and Exchange Web Services. However, Outlook Web Access must be configured in a separate step. 

Launch the OWA Publishing Wizard for Exchange 2010. Complete the publishing wizard to create a basic rule. As a result, you should be able to test Outlook Web Access on the most basic level. 

In order for the new OWA rule to fully work with Exchange Server 2013, you will need to make a few modifications to the rule. 

Modify the logoff parameter

First of all, you will need to modify the logoff parameter. Due to the changes in Exchange 2013, the old parameter will no longer work. To modify the logoff parameter, open the properties of the newly created OWA publishing rule, and select the Application Settings tab. Replace the line you see under “Published server logoff URL” to the following value: 
/owa/logoff.owa


Step 5. Granting access to cloud apps

Outlook 2013 introduces an all-new cloud app model, allowing to extend Outlook functionality and enhance user experience. Examples of such apps include Bing Maps, Suggested Meeting, Bing Translate, and others. You can build your own apps, too, allowing your network users, for example, to share parts of a common schedule or make use of certain aspects of your network infrastructure. These apps are also accessible via Outlook Web Access. But are they really? 

The simple answer is: they won’t work out of the box. In default configuration that you’ve just created by following steps described in this article, TMG will perform OWA Forms Based authentication in front of Exchange. As a result, the user’s exchange credentials will not be provided to the app at runtime, and the user will see an authentication dialog asking the user to log in. The annoying dialog form appears where it does not belong, right in the email message. 

In order to bypass this form, we’ll need to create a rule to exclude certain requests from pre-authentication. Essentially, we’ll create a partial override to the /owa/* rule we’ve just created. 

The rule we’ll be creating will handle requests to the following path:

/owa/guid@domain.com/version/owa2/ext/def/

The easy way would be substituting the line with something like this:

/owa/*/*/owa2/ext/def/

Looks logical, doesn’t it? Well, TMG doesn’t make it easy: wildcards are not allowed to appear in the middle of the path. You can only use wildcards at the end of the patch. 

Therefore, to solve this issue, you will need to form a static path with valid /guid@domain.com/ and /version/ parts. 

The good news is you can form the /guid@domain.com/ part. The guid is essentially the ExchangeGUID of the mailbox with the OrganizationCapabilityClientExtensions capability, while the domain.com part is the primary SMTP domain name of that mailbox. 

Issue the following command to locate the mailbox on your Exchange Server: 

Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like “OrganizationCapabilityClientExtensions”} | fl exchangeGUID, PrimarySmtpAddress 

The result will look something like this: 
[PS] C:\WINDOWS\system32>Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like "OrganizationCapabilityClientExtensions"} | fl exchangeGUID, primarysmtpaddress

ExchangeGuid : 3adbaa78-a453-8354-a7fe-3456536767ff PrimarySmtpAddress : SystemMailbox{33553aaf-467e-8934-ab43-356abc358dde}@advsoft.ru

Now you have all the required information to construct the /guid@domain.com/ part.

guid: use the value of “ExchangeGuid” 
domain.com: use the domain name of your SystemMailbox 

For above sample, the correct /guid@domain.com/ part will look like this: 


What about the /version/ part? This one changes with every update to Exchange Server, so normally you would need to watch the updates closely, modifying this parameter as needed. But… remember what we learned about wildcards? We know we can use wildcards at the end of the patch. So here we go, substituting the /version/ part and everything that goes past it with a plain, simple /* wildcard. 

Now, when you have all the required information, you can go ahead and create the actual TMG rule. 

Use TMG Outlook Web Access publishing wizard in to create a new rule. Make sure the rule you’re creating is of a higher priority than the rule you already created. Use the following settings: 

Path Tab: /owa/3adbaa78-a453-8354-a7fe-3456536767ff@advsoft.ru/* 
Users Tab: All Users (pre-authentication is disabled) 
Authentication Delegation: No delegation, but client may authenticate directly. 


After applying that rule, test if your OWA apps work as expected. The new rule allows Outlook 2013 apps work without throwing any unwanted logon forms. 

Make sure your new rule appears higher in the TMG Firewall Policy list than the general rule you created before. As this rule is more specific, it will be only applied to Outlook app traffic.

Moving OrganizationCapabilityClientExtensions capability to another mailbox

What if you were to move the OrganizationCapabilityClientExtensions capability to another mailbox? In that case, the ExchangeGUID would change, and you will need to modify the rule to reflect the new path (specifically, the /guid@domain.com/ part). 

Security Considerations

Effectively, the newly created rule may look like it opens un-authorized access to certain resources of your Exchange Server. Does it present a vulnerability? 

In pure scientific ways, it does. In real life, the probability of someone exploiting this vulnerability is going to be extremely low if you’re doing all other things right. Let us see what could possibly happen if someone was to exploit this rule. 

First of all, the rule is specific to path on your Exchange Server containing the unique Exchange GUID. The GUID is so long that it can’t be brute-forced, even in theory. So in order to use the rule the hacker will need to determine the GUID first. Unless they are an insider already having access to your Exchange Server (which would make the whole point moot), they’ll have to sniff the traffic. And this is exactly the reason why you must configure the system to enforce SSL encryption of all traffic. SSL-encrypted traffic, even if intercepted, cannot be decrypted within reasonable timeframe. 

There’s also another point. Mail apps can only activate in the context of a certain message, and can only run when the user clicks on them. When launched, the apps execute strictly in the context of the Outlook/OWA host; otherwise (if opened e.g. in a Web browser), they will not be able to access any message data. 

Information that can be accessed by the app depends on its requested permission level as declared in the manifest. Requested permission levels can be viewed on the app management EAC page. As a system administrator, you have the ability to only approve apps that you trust. 

More information is available on setting permissions for Outlook mail apps: 


Securing Exchange Server 2013: The Alternatives

With Microsoft Forefront TMG being long discontinued, why not use Microsoft Unified Access Gateway (UAG) to publish your Exchange Server instead? Just a few months ago this would not be possible, as you would sacrifice too many security features found in the UAG. Today, you can easily do this by installing Forefront UAG Service Pack 3 and following advice given in Microsoft whitepaper called "Publishing Outlook Anywhere Using NTLM Authentication With Forefront TMG or Forefront UAG". With Forefront TMG being discontinued, Microsoft continues developing its Unified Access Gateway solution, so you may be better off using the current product.

Tags: TMG, Exchange Server 2013, UAG