Publishing Exchange Server 2010 with Forefront UAG and TMG
Published Jul 16 2010 09:27 AM 36.3K Views

Since joining the Exchange Customer Experience team a few months ago, a question I'm commonly asked (aside from “When are you taking over the storage calculator from Ross? He’s a busy chap and as the new guy on the team you should help him out so he can take a break now and then.” – these comments added by Ross as a pre-condition to publishing this) is how to increase the security of access to Exchange from the Internet. I’m asked this mainly because I have a particular interest in client access and security aspects of Exchange, and have on many occasions come up against security folks who want to take all the fun out of deploying Exchange, or to put it their way, make things more “secure”.

Well, I’ve gone and written a whitepaper that walks you through the entire process of using either Forefront Threat Management Gateway (TMG) or Unified Access Gateway (UAG) to publish Exchange 2010. It starts by helping you decide whether to use Forefront TMG or UAG, makes sure you get the terminology understood, then provides step-by-step instructions to configuring the environment. It also covers migration considerations, troubleshooting steps and even how to publish ECP, but not Outlook Web App. And if you don’t know why you might want to do that, it even explains that!

I have a few more of these guides underway, and so we will also be publishing guides on how to enable Outlook Anywhere with NTLM through TMG/ UAG, while still benefiting from pre-authentication, how to do certificate-based authentication for mobile devices, and one other paper I’m keeping the subject of under wraps for now, but it promises to be an interesting way to secure remote access, that many of our customers will find interesting.

The guides are a little too detailed to publish as regular pages on TechNet, so we’ll be providing them as downloadable whitepapers. The first of which, “White Paper – Publishing Exchange Server 2010 with Forefront Unified Access Gateway 2010 and Forefront Threat Mana... is available.

Greg Taylor

36 Comments
Not applicable
Great, there goes my weekend.  Thanks for the articles!
Not applicable
Yes indeed a good article
Not applicable
Great acticle to use on monday at a client who want's E2010 and TMG2010 in production
Not applicable
Excellent article! When running Outlook Anywhere, you should really try to explain the difference between Basic and NTLM. Not mainly the technical aspects of the difference. I've read many explanations on that, but from the user's perspective - what's the difference for choosing one over the other? For example, why are there two choices at all if one is beneficial over the other?
Not applicable
@Jonas - glad you liked it first off.

With regard to Basic vs NTLM from a user perspective, Basic, with any version of Outlook prior to 2010, results in a pop up dialog asking for creds. Outlook 2010 makes the 'save this password' actually work, so in an Outlook 2010 world, Basic can mean no need to authenticate every time you open/reconnect, but in all earlier versions, you will have to enter creds every time.

NTLM, when used by a client that is domain joined and logged in with cached creds, results in the client simply sending the cached in creds to the server, resulting in what looks like a pretty seamless single sign on experience. However, if you want to do pre-authentication at something like TMG, and not let the traffic go all the way to CAS, you need to configure TMG for this. That's in the future Whitepaper.

NTLM on a machine without cached creds will again result in a pop up - or... there is a way to avoid that, but again for that you'll have to read the upcoming whitepaper on how to get OA NTLM to work through TMG... yes, it's a teaser... Reason is, the steps to get OA/NTLM to work, with pre-auth are complex, and I'd rather I give you all the steps you need than ask you to join the dots. It won't be long before it's ready.
Not applicable
Hi Greg,
Great stuff !, i think thus that "Provide certificate-based authentication for Exchange ActiveSync, Outlook Web App, and ECP" in the table should show that it's obviously available with UAG too....
Not applicable
Ilantz, it's not supported to do SSL client certificate based authentication for Activesync with UAG at this time. I checked with the UAG team (both the TMG and UAG teams reviewed and approved this document) and that's their current support position.
Not applicable
Hi Greg & Exchange Team,

Thanks for the great article. Very thorough and comprehensive.

Would it be possible to use a combination of certificate + user /password authentication for "internal" Windows 2003 based AD Forest user accounts that are associated with mailboxes in a separate Windows 2008 R2 / Exchange 2010 based Resource Forest from external Web browsers and/or ActiveSync devices?

If it is, would this require TMG 2010 to be a member of the Resource or "internal" Forests?

Thanks in advance!

Regards,

Peter
Not applicable
Just want I needed. Will read through this today and attempt to setup TMG tomorrow. Have found some of the info out there around Ex2010 & TMG a little lacking in clarity.

Thanks
Not applicable
@Peter - Interesting question - so there are a couple of thoughts I have.

Firstly, if you are using a resource forest, you still use the Exchange resource forest to publish/authenticate the user - the Exchange servers in that forest go chase down the user object in the other forest to make sure it has the permissions necessary to access the mailbox. As to whether TMG needs to be in one domain or the other, I would put it in the Exchange forest, or don't put it in the domain, and just use LDAP to the Exchange forest DC's.

On the question of using certificate + user/password - that's an interesting scenario -  what you can do is require a certificate to validate the user (not authenticate) before they get to see the Forms Based auth page - if you want to do that, go to the FBA listener on TMG, to the Authentication tab, then click the Advanced button - put a check in Require SSL client certificate.

When you do that, the user will be prompted for a user certificate, and if they provide one from a trusted CA (you can scope that down in the additional settings available in Advanced Auth Options) then they get to see the FBA page. If they can't provide one, they won't get to see FBA at all. It's not authenticating the user, it's more like validating the user. Dioes that answer the question?
Not applicable
I am often asked how to allow only company owned or approved computers / devices to access Outlook Anywhere and ActiveSync. Some definitive guidance on this would be most helpful.
Not applicable
That's the subject of an upcoming paper....
Not applicable
Hi,

i was using http filters to further secure exchange front-end/cas servers. there was a nice guidance for exchange 2003 servers:
Microsoft TechNet Application Layer Firewall protection for Exchange Server 2003 with ISA Server 2004

will the recommended http filter configuration be updated as well (methodes, extentions, etc.) ?
i figured out the most new filters with monitoring the traffic, but an offical guide would be better.

kind regards
Peter
Not applicable
Hi Greg,

Thanks for your prompt response.  

Validating OWA users prior to FBA would be beneficial, however would this be applicable to ActiveSync users as well (as FBA is not used for their authentication?)?

Would there be way a of utilising certificates to provide either pre-validation, or actual per-user authentication with ActiveSync devices - taking into account the resource Forest constraints?

I assume that not having the TMG server in the domain - which is a requirement for user certificate based authentication - only allows for pre-authentication?

Thanks again.

Regards,

Peter
Not applicable
This is awesome Greg.  Is the other doc going to address hereditary baldness? If you could include that in your next whitepaper that’d be great.
Not applicable
@Peter - so the validation with cert solution I mentioned would not work for EAS, or OA, it only works for browser based clients. That approach does not require TMG to be domain joined, as the cert is only used for validation, and it is not the primary form of authentication (FBA is).

If you want to use a client certificate for authentication, which can be done for either OWA or EAS users (but not OA), and you want pre-authentication, then TMG needs to be domain joined, so it can do KCD to CAS. As to whether this works for users in an account forest, take a look at http://technet.microsoft.com/en-us/library/cc752953.aspx - as 'it depends'. TMG and CAS would need to be in the same domain/forest for KCD to work.

DJ Ball covered the steps to get cert auth for OWA working in his post at http://msexchangeteam.com/archive/2008/10/07/449942.aspx and I will be publishing another paper showing the steps for OWA with TMG and EAS cert auth too, just as soon as I can.

So, certificate authentication, requires TMG be in the same domain as CAS. The certificate validation option I mentioned will work even if TMG is in a workgroup.
Not applicable
Thanks for this exciting article.
It's described to publish the CAS servers as Farm with all CAS server listed. What should we do if we've a CAS array with NLB?

Thank you in advance of your help.

Best regards,
Michael
Not applicable
@Michael - glad you liked it. I have a blog post ready on the subject of what to do when combining web farms with load balancers. I'll tidy it up today and we'll publish it very soon.
Not applicable
Hi Greg,

Awesome document!!! I really like all the details, screenshots and that you took the time to explain the TMG/UAG terminology and do a comparison. Well done :)

BTW found a typo/error on the file. On page 9 it says "A host record, AutoDiscover, has been created in external DNS to allow Outlook Web App and Exchange ActiveSync clients from outside the network to reach the Autodiscover service.". It should say Outlook Anywhere not OWA :P

Not applicable
Well spotted Gabriel, we'll fix that if/when we re-release the doc.
Not applicable
Hi Greg,

Thank you for this document.
You said that SSL Client Certificate based authentication is not supported yet in UAG for ActiveSync.
But if we only want to authenticate users with SSL certificate for Outlook Web App, using UAG is supported. Right ?

Thank you
Not applicable
Yes it is, SSL client certificate auth for OWA against UAG is supported. I'll include the steps required to make that magic happen in the Cert Auth whitepaper that will be out at some point.
Not applicable
Greg,

OWA is configured as default application without "Use Portal Frame".
i'm getting following error after authentication if i don't specify /owa/ in Url :
You are not authorized to access this application.
And in Web monitor event viewer,
A request on trunk webmail; Secure=1 failed because of an unknown application. The URL is /owa/

In your doc, you specified /owa/ in Url.
i think i missed something :)

regards,
stEfO
Any idea ?
Not applicable
In the OWA application, try checking the 'Evaluate without enforcement' checkbox. Also go back and run through the process again, just to be sure.
Not applicable
I checked "Evaluate without enforcement" in "Web Settings" tab of OWA Application. I terminated active sessions and purged client's IE cache.


I still receive "You are not authorized to access this application" in IE and "A request on trunk webmail; Secure=1 failed because of an unknown application. The URL is /owa/" in Event Viewer



Once authenticated, if i replace following url

https://webmail.weeta.local/uniquesig8b47c...31840/uniquesig1/owa/


by https://webmail.weeta.local/owa/, it works fine.


Not applicable
Greg,
when we configure OWA as first application, we are agree that it should redirect end users to OWA even if he didn't include /owa/ in Url ?
thx
Not applicable
Yes it should, it does for me, I'm not quite sure what is causing yours to fail. Did you try re-creating the trunk, and the application? Is there anything unusual in your setup?
Not applicable
I already re-created the trunk and the application.
As it should work, i will check my test environment
thx Greg
Not applicable
Hi Greg,

I found why it didn't work.
In my lab, End user was connected to UAG through HTTPS and UAG was connected to CAS server through HTTP

Configuration:
In CAS Server
   "Require SSL" not checked on default web site

In UAG
   Trunk configuration > General
       Server certificate: UAG computer default certificate

   Application Properties > Web Servers
       "HTTP Port" checked with value 80

In this case (End User --HTTPS--> UAG --HTTP--> CAS), automatic redirection to /owa/ does not work after authentication. The end user must modify manually the Url to include /owa/.

I created good certificates and configured a full HTTPS chain from End User to Exchange CAS. In this case, redirection is working fine.

Thx

Not applicable
Hi Greg,

Great article, good job! I'm deploying TMG2010 for OWA and OA but I have Exchange 2007.  It looks to me this paper should apply equally well to 2007 'tho?  Are there any particular sections you think don't apply or needs configuring differently for Ex2007?

Thanks!
Henry
Not applicable
@Henry - There's really very little difference with Exchange 2007, it's only the ECP piece/considerations, and you can therefore ignore them.

@stEFO - glad it's working ok now.

Not applicable
How would this need to be modified to support Calendar Federation?  Do you need to publish EWS separately with no authentication at the TMG layer?
Not applicable
Here's how to do this - place a rule higher up in the processing order, requiring no auth for the following specific urls;

/EWS/exchange.asmx/wssecurity
/autodiscover/autodiscover.svc
/autodiscover/autodiscover.svc/wssecurity

Give that a try.
Not applicable
Thanks Greg.

I created this rule, set it to "No Authentication, but users can authenticate directly", and set it to apply to
"Everyone" instead of "Authenticated Users".  The web listener is set to FBA, but "always authenticate" is not checked.

It still does not seem to be working.  Am I missing something?
Not applicable
RedGrey - set the Users tab on the rule to All Users
Not applicable
Thanks Greg.  That was what it was set to already (I meant All Users when I typed "Everyone").

I think my problem is due to the fact that I'm using SSL offload, which I know has issues with EWS.  I may need to wait for SP1.
Version history
Last update:
‎Jul 01 2019 03:52 PM
Updated by: