Publication de Exchange Server 2013 à l'aide de Forefront TMG
Un nouvel article de l'équipe de développement d'Exchange sur la publication de Exchange Server 2013 à l'aide de Forefront TMG 2010:
Now that Exchange Server 2013 is available, some of you may well be wondering how to publish it to the Internet using Microsoft Threat Management Gateway (TMG) or perhaps the Microsoft Unified Access Gateway (UAG).
This post will help you configure TMG, for sure, but not UAG - as for the time being, you can't effectively publish Exchange Server 2013 using UAG without turning off many of the security features in UAG. Why's that? Well, as you'll have gathered from other posts on this fine blog, we re-wrote OWA for Exchange 2013. And when an application like UAG inspects OWA traffic, it gets a little confused when you change everything, without telling it. So, the UAG team are busy beavering away re-writing their rule sets to work properly with Exchange 2013, so the advice for now if you have UAG, is to wait for a future UAG update, where it is currently expected that Exchange Server 2013 support will be added.
So back to TMG. TMG can be configured to work with Exchange Server 2013, and that's what I'm going to walk through in this post.
I'm going to make an assumption here (risky perhaps, but if you are reading this post it is highly probable you already have TMG publishing either Exchange 2007 or 2010) that you are familiar with the existing guidance we have published. That covers the basic configuration of things like certificates, authentication, publishing rules and more - so rather than repeat all that here, we're just going to focus on the Exchange Server 2013 specific changes you need to make. If you want to go refresh yourself and re-read that whitepaper, go ahead, this page will wait patiently for your return.
Welcome back. And off we go.
The first thing to know is that there is no Exchange Server 2013 publishing wizard, but do not panic as you can instead use the 2010 wizard, and then make some changes described here.
The first thing you will want to actually do is create a new web farm (and I hope you use web farms rather than publish load balancer VIPs or single servers as it makes life much easier in the long run) and put your 2013 Client Access servers into it. It's the same procedure as for 2007 and 2010 including the connectivity verifiers, so just go ahead and create a web farm. Here's mine. It's a small farm. More of a gentleman's farm than a real farm, but it will work nonetheless.
Now you have a web farm, let's create some rules. But before we get into that, we're not going to cover the actual cutover here, that's perhaps another post, we're just going to run through the rules you need. When it comes to the actual cutover, just to briefly mention it as I've started now, and it's hard to stop typing once you get the flow going, if you have both 2007/2010 web farms and 2013 web farms all you really need to do is change the web farm being used on the To: tab for each publishing rule, and assuming the rest of your Exchange configuration is correct, you just did a cutover. Is that an oversimplification? Sure, but frankly the cutover is as it was for previous versions and if I don't get to actually writing about the TMG rules for 2013 and instead keep rambling on about things like this then I'll never get this post finished and you will have given up reading.
Oh, I'm sidetracked again. Squirrel. Oh sorry, back again. Before we can cover the rules we also have to talk about delegation. Delegation is the method by which TMG authenticates, proxies, re-uses (depending on how you see it) or delegates the credentials, of the authenticated user to the Exchange Server it is publishing. At this time, Exchange 2013 only supports Basic or NTLM delegation, it does not support Kerberos Constrained Delegation (KCD) for now, so all delegation must be Basic, or NTLM. If you have no idea what KCD is, welcome to the majority, just make sure you don't select it ok? So with that last piece of housekeeping out the way, onto the publishing..
We shall begin by agreeing that you have used the TMG wizard for publishing Exchange ActiveSync. You have selected the Exchange 2013 CAS Farm as your target and set the correct Delegation setting (typically Basic but it's your choice if you want that, or to use NTLM, as long as Exchange is enabled for the auth type you have chosen to delegate it should work fine).
What now? Nothing. For Exchange ActiveSync you are done. Move along, nothing to see here. It just works. Well done you.
Given that was so easy, let's try another. Outlook Anywhere. That must be harder.
You run the Exchange Server 2010 Outlook Anywhere wizard, don't forget to check the 'Publish additional folders on the Exchange Server for Outlook 2007 (yes, out of date isn't it) clients' option and choosing the Exchange 2013 CAS server farm.
Now, just like before, you may need to revisit the rule the wizard creates, particularly the Public Name tab, and add the autodiscover.company.com name to it, just as you did for 2007 and 2010, and if you are using Basic Delegation you will probably need to go and add basic to the authentication methods enabled on the CAS for OAB and EWS (just as you did for 2007 and 2010), but apart from those few things, you are done. The rule works for 2013, there is nothing else to do.
| Wizard Default |
You Probably Want This |
 |
 |
So at this stage you are probably wondering why we needed a blog post. If this stuff just works, why bother wasting valuable pixels and your time with a blog post. Well, OWA doesn't work out of the box. So that's where we need to focus.
The first thing to do is run the OWA Publishing Wizard for 2010. That gets us part of the way there. It creates a rule, which you can tell to prove OWA is working at the most basic level.
Clearly as you test the rule you will see the 2010 OWA Forms Based logon page. Don't go trying to make it look like 2013 OWA just yet, let's get the whole thing working before you start fiddling, as I know some of you will. For now, leave it.
So the first thing we need to do is modify the logoff parameter. That has changed between 2010 and 2013 and so the default TMG sets you up with won't work. This is easy to do. Open the properties of the OWA publishing rule you just created and change the parameters on the Application Settings tab thus;
| Wizard Default |
You DO Want This |
 |
 |
That was easy. Next is the tricky one. Strap yourselves in, this one might be a bit hard to get on the first read.
Outlook 2013 brings to the table a new cloud app model, meaning you can download and install apps that enhance the power of Outlook. OWA has them too, if you have tried OWA 2013 or Outlook 2013 you might have seen the Bing Maps app, the Suggested Meeting app - some really cool apps that you can use out of the box. You can also build your own, integrating into your own in-house systems, for example.
Why am I telling you this? Did the app team want some free advertising? No. It's really because they don't work out of the box if you have TMG doing OWA Forms Based authentication in front of Exchange. Why? Well, the apps are surfaced in Outlook via a trident control, which is essentially an instance of IE framed into the Outlook host. The user's exchange credentials are not provided to the app at runtime. So from a network perspective, the app loading looks like an anonymous HTTP GET, coming from an IE browser. And that request is to a sub directory of /OWA.
So guess what TMG does? Throws up a form, inside the app control window, asking the user to log in. Oops. Not a super user experience it has to be said. It looks a bit like this.
Now the way around this is familiar if you have ever configured Hybrid, or Org Relationships using the Microsoft Federation Gateway. We need to exclude some requests from pre-authentication. We need to craft a higher priority rule than that for /owa/* to catch these requests. Now, this is a bit deep, but I know the readers of this blog are smart, so I'm sure you will follow along.
The request Outlook makes is actually to /owa/guid@domain.com/version/owa2/ext/def/ and what makes this more challenging is that TMG won't allow you to specify path wildcards in the middle of a path, eg. /owa/*/*/owa2/ext/def - not allowed. Wildcards are only allowed at the end of a path - path/path/* is allowed for example.
The good thing here is that /guid@domain.com/ is predictable. (Version on the other hand changes each time you update Exchange). It's constructed using the ExchangeGUID of the org mailbox with the OrganizationCapabilityClientExtensions capability. You can find this cleverly named mailbox by running the following command on your Exchange Server;
Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like "OrganizationCapabilityClientExtensions"} | fl exchangeGUID, PrimarySmtpAddress
Here's my example:
[PS] C:\WINDOWS\system32>Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like "OrganizationCapabilityClientExtensions"} | fl exchangeGUID, primarysmtpaddress
ExchangeGuid : 3eccca51-d996-49df-b6e0-302d644fdcaa
PrimarySmtpAddress : SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}@contoso.com
So once we have those two pieces of information, we take the ExchangeGUID and the @domain part of the primary SMTP address of that mailbox, and construct a string (guid@domain.com) like this;
3eccca51-d996-49df-b6e0-302d644fdcaa@contoso.com
Warning: You should only do this during months with an 'r' in them otherwise you may cause a black hole to open and swallow the entire planet. Do not come looking for me if that happens and say I did not warn you.
Now for the TMG rule.
Use the OWA publishing wizard in TMG to create a higher priority rule than that you already built for OWA that contains these settings;
Path Tab: /owa/3eccca51-d996-49df-b6e0-302d644fdcaa@contoso.com/*
Users Tab: All Users (no pre-auth in other words)
Authentication Delegation: No delegation, but client may authenticate directly.
It looks a bit like this;
Apply that rule and it should now all work as expected. The rule allows just Outlook 2013 apps to bypass pre-authentication and work as expected.
Here's my rule, it is higher in the list, making it a higher priority and so it is processed before the generic OWA rule. The rule is more specific to the request, so it applies to the traffic from Outlook apps.
Is this rule opening you up to an attack or some vulnerability you might ask? And you should ask, it's a good question. Well for one, the Exchange GUID is unique to your organization. So in order to use the rule someone has to figure that out. That's quite hard unless someone is eavesdropping on your traffic, and if the session is SSL encrypted, which it should be if you are serious about what you are doing, so really it's a non-issue.
Secondly, you should understand that mail apps activate in context of a given (user selected) message, and only execute (load the source html/js) when clicked on by the user. The app needs to load in context of the Outlook/OWA host for any of the API's to be able to access data via cross-document messaging (in other words, loading the app source directly into a standalone browser instance won't have any message data to access).
What data the app can access depends on the permission level requested by the app (declared in the app manifest, and viewable in the app management EAC page). So as an admin, with the ability to publish apps you approve of to your users, you can ensure only apps you trust can be used.
For more information about requesting permission levels for mail apps, you should review the following topics:
So to wrap up, don't forget, this new rule has to be higher in the processing order than the regular OWA rule. And if you were to move the OrganizationCapabilityClientExtensions capability to another mailbox, the ExchangeGUID would change, necessitating the rule to be fixed up.
So what else? Nothing. Well, nothing for now. At this stage you should have Exchange 2013 working very nicely through TMG, but if you do have issues, post them here and we'll try to help.
Greg Taylor
Principal Program Manager
Exchange Customer Experience
