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;
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!
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.
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.
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!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.