More Whitepapers to Help You Securely Publish Exchange

Published Dec 06 2010 10:12 AM 19K Views

A few months ago we published a Whitepaper detailing the steps required to securely publish Exchange to the Internet using TMG and UAG. (That document has recently been updated by the way, and the newest version is available here White Paper - Publishing Exchange Server 2010 with Forefront).

At the end of the last post I hinted at some related upcoming Whitepapers. The first two of them are ready. The first is about using IPsec to restrict access to OWA and Outlook Anywhere to machines you control or manage, and it is available here: Using IPsec to Secure Access to Exchange

The reason for this first paper is interesting; at least, I think so. Exchange has for a long time now offered many different ways to access a mailbox from any location - but some of our customers still do not allow Outlook Anywhere (and OWA, though less so as OWA has many multi factor authentication solutions in the market) connections from the Internet. These customer's security teams tend to think of these connection mechanisms as 'insecure' because any machine can connect, there is potential for Denial of Service (DoS) and brute force passwords attacks, their security policy states 'two factor authentication' is required, and so on.

Several options exist to solve some of these problems, some of which are available today, some others are in the works, and some are just not well documented. One important consideration when choosing a solution however is to think about the user experience; if the solution requires a lot of user action, it results in security happiness, but user unhappiness, and usually the reverse is also true.

Let's be clear here, it is not expected that these solutions should be adopted by every customer that deploys Exchange, but if a customer is particularly security conscious, then it helps if a well-documented and supported solution exists, enabling those customers to satisfy their security needs, and allow them to provide their users with an Anywhere Access solution.

The options generally available are;

  • VPN - establishing a VPN before connecting Outlook or OWA allows two factor authentication to be used, but the user experience can be poor - a user cannot simply launch their email application and get access to their email.
  • Direct Access - Direct Access provides Intranet like access from any location with no user experience issues, it's like a VPN without the need for the user to perform any actions - but the requirements for this are significant - Windows 7 Ultimate/Enterprise is the only supported client, and UAG is the preferred edge solution.
  • Security by obscurity - using private certificate authorities to generate SSL certs prevents machines without the root certificate from connecting - but is easy to bypass simply by installing the certificate as 'trusted'.
  • Using IPsec to secure the HTTPS connection - When IPsec is enabled and required on the endpoint used for publishing Exchange to the Internet, only machines with the right credentials can establish a connection. Outlook/OWA then authenticate as usual, as they have no visibility into, nor involvement with the network security layer.

If you want a solution that works with all versions of Exchange, and can be deployed today, without significant additional investment, IPsec is an attractive solution. And co-incidentally, that's what the Whitepaper explains how to set up!

How IPSec Works - The Science Bit

IPSec at the Machine Level

Computer to Computer

Basically it works like this. The client and server each have a policy (IP Filter List policy) defined that states what traffic entering or leaving the network card should be subject to IPSec. When traffic matching the rule is sent or received, the policy settings apply. If the policy says to secure the transport using machine certificates for authentication, so be it. If the policy said to blow a raspberry, it would happen. Though given how most servers are in noisy datacenters, you usually can't hear it.

The configuration of the IP Filter List policy can easily be distributed through AD Group Policy to the client machine (the server policy can be optionally configured too). The client is configured so that it will negotiate IPsec when connecting to a specific IP address or addresses, and to authenticate that connection using a certificate or shared key (Shared keys are only useful for testing, because if this were compromised, every IPsec client would need updating and the resulting threat window is a large as the time it takes to complete this task)

Standard machine certificates for domain joined machines are usually sufficient for IPsec, and these are usually installed via auto-enrollment in an Enterprise AD. Certificate requests for non-domain joined machines can also be processed if required, which would allow an Enterprise or service to permit specific machines to acquire a certificate despite not being a member of AD. Those machines would require the certificate to be imported and then the IPsec policy to be manually configured. These offline requests would still require properly authentication and authorization before the certificates are issued. All of the details required to set this up are in the paper.

So once the policy is applied, the client and server perform an Internet Key Exchange (IKE) or use AuthIP (depending on operating system but the end result is the same) with each other over UDP 500, or UDP 4500 if NAT is detected (NAT-T). The two machines negotiate a level of encryption/authentication before establishing a Security Association (SA). The SA is subsequently renewed based on either a time interval or the amount of traffic processed.

Once the SA is established, Outlook, OWA or any client is then able to establish a connection to the remote host (in this case, the external IP/listener of TMG) as though it was directly connected. If Outlook/OWA are closed the SA remains open until the expiration of the connection, or until one party disconnects.

When you boil it down, the control of which clients can or cannot connect becomes a function of how the PKI is managed. Machine certificates cannot be exported and copied by default, so only machines that can enroll or are provided with a certificate can connect. If a certificate is revoked, then the client is only able to connect for as long as it takes for the admin to revoke the certificate and for the IPsec endpoint to notice that change.

What Are Some of the Benefits of the Solution?

  • Clients establish a secure connection to the server with no user or application interaction or visibility. IPsec operates at Layer 3 of the OSI model (Network).
  • Only clients with a valid machine certificate issued by a CA that is trusted by the service endpoint can connect and even attempt to authenticate. DoS is moved from username/password layer to the IPsec negotiation layer, which is much harder to crack.
  • Works with AutoDiscover, EWS, OA, OWA.
  • When combined with computer lock, this could be considered two factor authentication - something you have (the certificate), something you know (your password).
  • You might also say it is two factor anyway, as something you have is the certificate, something you know is your username/password which are required for OWA.
  • Works with NAT and all versions of Windows later than XP SP2.

What Are Some of the Drawbacks of the Solution?

  • If the IP address of the service endpoint is changed, th e policy becomes outdated. Policies are based on IP address, not FQDN's.
  • Windows Mobile does not natively support IPsec in this peer to peer fashion, so cannot utilize the solution, however third party IPsec solutions do exist for WM and other platforms.
    • Think about this though - If EAS is used, AutoDiscover would need to be on a separate IP address from OA, so it can be excluded from IPsec and still used by EAS devices, or a third party IPsec client could be installed on the mobile device.
  • This solution has some deployment complexity simply due it not being well documented but also because of its dependencies on PKI and IPsec, technologies not widely understood. But hey, now you have a Whitepaper, you can make it appear that you know all about IPsec soon!

What Are the System Requirements?

  • All Windows clients from Windows XP SP2 onwards support IPsec and NAT-T.
  • TMG at the network edge is recommended, though traffic can pass all the way to CAS if required (if this were the case then the policy created would need to contain network scopes to differentiate internal/external traffic, or the same policy could be applied everywhere).
  • A PKI to issue the certificates - an AD integrated PKI means getting the certificates onto client machines is easier, but any PKI can be used. As long as the client and server both trust the same CA, and can both build a chain of trust and check revocation, the PKI will work.

Exchange ActiveSync and Certificates

The second paper is about using certificates to authenticate to Exchange, from a user perspective though, not machine, and specifically when using Exchange ActiveSync or OWA. The paper is available here: Using TMG and UAG to Securely Publish Outlook Web App and Exchange Activesync with Certificate Based...

The paper covers the type of considerations you need to make when choosing to deploy certificate based authentication, how to configure it when using Forefront TMG and UAG, and provides troubleshooting tips in case you have problems along the way. I hope you find it helpful. The one step in there about how to configure KCD to a web farm has in itself paid me back many times with helping customers configure this scenario, so make sure you go look at that.

What Now?

Now this isn't as hard as it seems, though the papers are quite long as you'll see. My advice would be to build the scenarios out in a lab, just like the documents, make sure it all works as expected, then look at making any changes you want to make that are specific for your particular deployment.

Good luck and enjoy!

Greg Taylor

Not applicable
Is there also a whitepaper that shows how to configure this correctly when terminating the ActiveSync client connections at the CAS? I'm using ISA 2006 and all requests are tunneled through to the CAS. With 2003 you had to use constrained delegation between frontend / backend. What's the procedure for 2010 and how would that work in a co-existence scenario?
Not applicable
Thanks Greg,
Great doco's and the IPSec worked a treat for our laptops.
Not applicable
Well, "Machine certificates cannot be exported and copied by default" sounds nice, but is wrong.
There's no way of preventing the use of eg jailbreak.exe to export any private key marked with "private key not exportable". The checkbox is more like begging "please do not export the key".

Long way to go...
Not applicable
Great stuff Greg !!
Too bad outlook is still not equipped with native support for Two-Factor auth.. client certificate sounds like something that should be long supported.

Off-Topic : How come Exchange 2010 SP1 brakes the redirection for OWA with the Exchange2003url set when TMG/ISA is involved ? i fail to see any updated documentation on that matter...

Thanks again!
Not applicable
ilantz - We actually have a fix for the redirection issue.  You can call PSS for the interim update in he mean time until we have the fix shipped in a rollup.

Not applicable
Thanks ross !! will do that !
Not applicable
@Robert - there is no Whitepaper for that scenario as all you need to do is enable cert auth in EMC. Without testing I'm not 100% sure on whether KCD is required between 2010 CAS and 2003 MBX, I suspect not, but it's an easy setting to figure out, it works, or it doesn't... I'll see if I can get time to test it, but I know it will work, it's just whether KCD is required or not that I am not sure of.

@Aengus - great, thanks for the feedback!

@Klaus - so the use of a tool like that presents some interesting questions. Firstly though, I would stand by my comment of machine certs not being able to be exported by default - they can't - unless you choose to use a tool like this (which is detected as a virus/trojan by many AV scanners) which requires you to have local admin priviliges as well - and the use of a tool like this is not the default behaviour of most users.

Given that most organizations that are looking to secure things like OA and OWA are already security minded - it's unlikely users will be local admins, could uninstall their AV etc. I'm not saying a tool like that can't be used to export a cert, I'm just saying that you can mitigate against it in several ways. Security is multi-layered, and one thing alone will never be enough to stop a determined hacker.
Not applicable

Armani Jeans
Christian Audigier Jeans
Versace Handbags
Not applicable
Thanks for the papers, they are truly great documents! Unless I am mistaken, these gateway products do not support load balancing the RPC protocol. So, for larger deployments where MAPI is the primary connection method, what recommendations can you offer? I suppose a hardware-based NLB may be able to provide this function, but wouldn't that negate the need to also have UAG/TMG? Or, is the answer that, if you have specific requirements, such as load-balancing RPC/MAPI traffic, and something like ceritificate-based ActiveSync, you may need to leverage a combination of solutions? Thanks in advance.
Not applicable
Hi Adam, glad you find the papers useful, thanks for the feedback.

You are quite right that neither TMG nor UAG can load balance RPC traffic, and so for that you do need to look at a hardware or software load balancer.

Once you throw one of those into the mix, and you have TMG or UAG then you are right again that you have some additional things to consider. I posted a while back on the issue, and which scenarios, such as cert auth that require you use a web farm, rather than trying to publish a load balancer.

The article is here - but in general terms, use a web farm on TMG/UAG for internet based access, and the load balancer for internal access.
Not applicable
We currently have ActiveSync with client certificate authentication enabled. Now we are introducing Outlook Anywhere. To prevent 'weakest link' situations we also want to provide Outlook Anywhere with stronger authentication than only username/password.
Is there a scenario where Outlook Anywhere also works with certificate based client authentication?
Not applicable
Hi Eric, at the current time there is no way to confgure Outlook Anywhere to use client certificates for authentication.

That limitation was really the reason behind the IPsec solution - which allows the computer to authenticate with a certificate before the user is able to authenticate with their own credentials.
Not applicable
Great document.

We just found one issue during implementation:
In the "Configuring Connection Security Rules on a Windows Vista or Windows 7 Based Client" on page 29, we see how to configure the Connection Security Rule to a specific protocol/port.

Unfortunately Vista doesn't allow to configure port/protocol in the UI.

Now if somebody just continues - thinking it doesn't matter if this restriction isn't applied on the rule at the client ... but still configures the Connection Security Rule at the TMG server (on Windows Server 2008 R2) including the protocol / port - then he gets IPsec errors 4654 "No Policy configured". (IPsec rules on both machines need to be identical).

One workaround is to configure the rule in netsh - which allows configuring protocol/port. Another workaround would be to allow all ports/protocols on the server as well.
Version history
Last update:
‎Jul 01 2019 03:55 PM
Updated by: