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!