Hopefully you managed to get yourself started with client certificates in the last post, or maybe this was something you had already sorted out in your own lab without any assistance of mine. The thing is, an ActiveSync configuration that only works over the LAN isn’t all that worthwhile is it? You’ll want to make it work across them Intertubes as well don’t you?

Now granted, this does not have to be complicated as such. If you have gotten it working directly on your Exchange and you’re piping the traffic through a regular firewall which just happens to do a port forward on the incoming traffic it doesn’t require much effort (just forward the port and let Exchange handle the rest). I don’t know about you though, but I prefer some kind of reverse proxy in between that inspects the traffic and authenticates the connection before passing it through to the back-end server. Perhaps not entirely unsurprising I have chosen Microsoft ForeFront Threat Management Gateway 2010 (the artist formerly known as ISA Server) for this purpose in my infrastructure. Let’s try to build on what we have already done, and create some firewall rules that will make this work.

The three-headed dog
When you authenticate yourself to ForeFront with username and password the firewall is able to read your actual credentials, and after checking these to be good with Active Directory they are passed along to the Exchange Server. So as far as Exchange is concerned it’s just like you authenticated directly to Exchange. But client certificates do not work this way. TMG is not able to pass along the certificate and present it directly to Exchange. This is a desired design that improves the security of the credentials. So how does TMG pass along your identity? This is where Kerberos enters the stage. You can read all the details in the TechNet Library if you want to understand the protocol (multiple readings might be necessary) – take a look here:
http://technet.microsoft.com/en-us/library/cc995228.aspx

The short take of it is that we need to configure Kerberos Constrained Delegation (KCD) for this to work, and there are some additional things you need to do before creating the firewall rules. Keep in mind that this requires your TMG Server to be joined to the same domain as the Exchange Server. (And from what I can tell based on my testing they need to be in the same AD site/subnet as well.)

Configuring Active Directory
First order of the day is to open up “Active Directory Users and Computers” on your Domain Controller (or your workstation if you have remote tools installed). Locate the object for your ForeFront TMG Server. (Do not touch the Exchange Server account.) Go to the “Delegation” tab of the properties. Configure it as shown below (look up the “Service Type” and “Computer” account by clicking the “Add” button):

In case you’re wondering I have intentionally blanked out the “User or Computer” column in my screenshot The computer account you need to add is the Exchange Server hosting the CAS role.

The service type is supposed to be http even though we are using https – it is not a bug or typo. (SSL is something you layer on top of http, it’s not an entirely different protocol.)

Configuring Exchange
If you followed my previous article you might have “Basic Authentication” enabled under the Authentication options for the Microsoft-Server-ActiveSync virtual directory. (Client certificates is enabled in a different config view shown in the next paragraph.) But this will not get you very far with Kerberos. The concept with Kerberos is that Active Directory grants the “tickets” to TMG, which are passed along to the Exchange Server, and thus you will need to enable “Windows Authentication” as well. (Actually you can disable Basic if you like, but maybe you like to keep it for other purposes.)

IIS Manager

Basic and Windows are enabled.

To accept or require…let me see…
In my previous post I briefly mentioned that you could have the SSL settings set to either Accept or Require certificates. The client certificate from the ActiveSync device will be passed along as a Kerberos ticket, and will work even if you set it to “Ignore” on the Exchange Server. The effect of setting it to require here is that the TMG Server will have to present a client certificate in addition to the Kerberos ticket. You can mull it over what you prefer – I’ll get back to the TMG settings affected later on down this page.

Locate “SSL Settings” in IIS Manager

Set to Ignore/Accept/Require.

Creating a Web Listener
You have now laid the foundations in your infrastructure for creating the necessary firewall rules so you may now switch to your ForeFront TMG console.

Now, you can run through the Web Publishing Wizard and create the Web Listener as part of this process, but I think it’s more clean to create the listener before creating the publishing rule. The important screenshots are shown below (I’ve created a listener called “HTTP / HTTPS” through the Wizard already):
Connections
HTTP should not be checked/enabled.

Authentication
Select “SSL Client Certificate Authentication”, and if you like you can check “Use a fallback authentication method” if you have some devices that do not support certificates.

Authentication->Advanced

You would think that you need to check “Require SSL client certificate”, but this only applies when using Forms-Based Authentication (which is not supported by ActiveSync).
You would also need to configure the correct server certificate on the “Certificates” tab. In the “Advanced” dialog you would most likely (after testing things working) change the “Client Certificate Trust List” to only trust certificates issued by your CA.

Creating a publishing rule
After you’ve got the listener configured we move on to creating the actual publishing rule. You can use the Web Publishing Wizard, but choosing “Publish Exchange Web Client Access” will make it slightly easier for you.

Pick any name that suits your rule naming scheme.

Choose your Exchange Server version (I’ve only tested with Exchange 2010), and select only “Exchange ActiveSync”.

Remember that you must use SSL for this specific scenario.

Type the internal host name, and while it’s optional to specify an IP address I recommend it. (Ensures you’re not getting irritating SSL errors when bridging the traffic if there some mismatch in DNS names and certificate names.)

Select the Web Listener we just created. Should not be necessary to edit the properties.

Select “Kerberos constrained delegation”. The SPN should already be filled in (based on the internal name you specified earlier in the wizard). It’s important that this matches up with the SPN you specified in Active Directory. Depending on how your AD and DNS is configured you might have to use the full FQDN instead of just the short name. (Short name worked for me, but keep it in mind if you’re having problems getting it working.)

Using Client Certificates for the Bridging
If you specified “Required” on your ActiveSync virtual directory you have to edit the rule you just created to accommodate this. If you set it to “Ignore” or “Accept” you can skip this step.

For this to work you need a certificate installed on your TMG Server. But it should not be in the Computer store that other rules require. You need to import it into the Firewall Service certificate store. You just need a plain Computer certificate with the FQDN as subject name.

Import into this store:

Next you should go to the “Bridging” tab of your publishing rule. Check “Use a certificate to authenticate to the SSL Web server”, and select the certificate you imported in the previous step.

Hit “Apply” in your TMG console, and fire up either a device, or my EAS MD utility to test. Hopefully things work at this point, but if you’re unlucky you might run into some error. When I tested I experienced 401/403 which means authentication failed – if so double check all the settings. I also saw a 408 timeout error, and this usually implies something is failing in the Kerberos delegation.

When googling Kerberos errors you might run into tips suggesting you should use the SetSPN tool. While this is a perfectly ok tool it is not required for this scenario, and if you do use it remember to clean up the mess it leaves. While using the ADUC interface for editing will automatically update the relevant info in AD there is no automagic involved with SetSPN. The odds are that you will mess around, try a couple of different settings, and forget to remove the incorrect ones. Using the AD GUI is much better.

Depending on how you view things you might consider us to be finished now, or almost there. When authenticating directly to the Exchange Server we saw that by enabling and disabling basic authentication we could control whether the device needed to supply both a client certificate and a username/password, or just the certificate. How to achieve this in our current setup? Well, the thing is that a publishing rule will only let you specify one authentication type. (Fallback mechanism is only invoked when the primary mechanism fails.) And to set up multiple authentication methods on TMG you need to create multiple web listeners, which in turn requires multiple external IP addresses. When you’re not using certificates it is possible through some “hackish” approaches to have multiple authentications. With certificates you still have the problem of passing along the certificate. I have only looked briefly at this, and not had any success getting it working. (It could be something obvious for all I know.)

So, do we call “bad design” on this one? Well, it’s not a straight answer to this question. If you are enjoying the benefit of not having to enter passwords on the device you’ve achieved that goal. If you insist that things are more secure using both means…Well… The thing to consider as well is how easy it is for users to enroll certificates. Do they need to perform any special means for enrolling or can they just enroll on the desktop, export as a pfx file and transfer to any device? And what about the device handling the certificates? With Windows Mobile you need to import the certificate into the private store where it is tamper-proof and non-exportable. Think through the entire scenario, not just the TMG rules, and evaluate what’s right for you.

I learned a lot jumping through all the necessary hoops to get this working, and I hope you found it to be of some value. Let me know if something is missing from this quick two-part guide.