MobilityDojo.net

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.

Certificates is not only a recurring theme on this site, it’s also a recurring pain point from what I hear. Getting it working is just down right confusing sometimes. With this in mind I thought I’d walk us through a scenario where you want to secure your Exchange ActiveSync deployment with the use of client certificates.

Ok, I said “a scenario”, but it might be more correct to say “a couple of scenarios” because there are a couple of design choices you can make. But let’s set the stage before we proceed – why are we even discussing certificates in the first place? What are they good for?

Let’s be honest – you will save yourself a lot of work and hassle if you go for the good old username & password combo. But through using certificates you can achieve other goals which might not be met the same way without taking the route of yet more complex configurations:
- Security
- User friendliness

Yes, these are normally two conflicting goals – I know Security can be beefed up with certificates as a means of adding an extra factor to the authentication process, as something you need in addition to a password. User friendliness can be improved upon by removing the need for users typing in complex passwords every couple of weeks on their mobile device.

With that in mind let’s see what we can do to get this train rolling. Oh, yes, one more word of advice; since we are dealing with mobile devices do not hit the implement switch before you have checked out if there are any devices that are not able to handle it. Windows Mobile devices are ok, iPhones are ok, possibly Symbian too. Don’t know about Android (it would be specific to the ActiveSync client used since it’s not provided by the OS). “Feature phones”, also known colloquially as “dumbphones” are probably out of the loop.

I assume that you have already installed an Exchange Server with the Client Access Server role functioning before following along here. I am using Exchange Server 2010 RTM on Windows Server 2008 R2, and ForeFront TMG 2010 as a firewall/reverse proxy. Exchange 2007 might be slightly different on some points, but pretty similar. Which OS you’re running matters because part of the functionality is provided by the OS, so if you’re running on Windows Server 2003 things will also differ from what I do on my servers.

We’ll start out enabling client certificate authentication directly on the Exchange server assuming for the sake of the test that all mobile devices connect via the LAN In the Exchange Management Console go to
Server Configuration->Client Access->Exchange ActiveSync.
Your properties might look like this:

You’ll want to switch this to “Require client certificates” like so:
 

Note that we have unchecked “Basic authentication” as well.
As it says in the dialog box you need to configure SSL itself through the IIS manager. Often when I test and debug in my lab I disable SSL and run it through plain HTTP. This will not work if you want to use client certificates, and you should require SSL. (If you haven’t messed around with this setting the defaults after installing Exchange 2010 are already configured to require SSL.)

Actually you could change the client certificate requirement in IIS too:

And as long as we have the IIS console open. How about we configure the certificate mapping at the same time? Mapping what you say? While having a certificate is a nice thing in itself how does Exchange verify if your certificate is good? If someone presented you with a hand-written post-it note with a doodled self portrait and “driver’s license” written along the top would you trust it? Wouldn’t you rather have the laminated, (or credit card version), with some official looking logos and stamps? We need to define where Exchange should perform the lookup for verifying that your certificate is good, and this we call mapping the certificate. Rather than explain the process in detail I’ll refer you to this link for the necessary steps:
http://www.iis.net/ConfigReference/…/…/…/clientCertificateMappingAuthentication

Short version – install the “Client Certificate Mapping Authentication” role service, and enable it to have Exchange use Active Directory as the source for certificate verification.

Since we haven’t gotten to the part of enrolling certificates on devices yet you can use my ActiveSync “emulator” if you’d like to test at this point – http://mobilitydojo.net/downloads

If all is good you should be able to run a “Basic Connectivity Test” even without specifying a password. (You need to provide the username as that’s used for other purposes behind the scenes.) The .cer file I’m using is a certificate I have enrolled through AD directly to the “Personal” store on my development box, and exported to a file without a private key.

Now, back to that “Basic authentication” bit again. I said there might be different scenarios to choose from, and technically you don’t have to uncheck the box like I did. You have three possible combinations of client certificates and basic authentication;
- Basic authentication enabled, ignore/accept client certificates. This is the default. Will let you synchronize as long as you provide a valid username and password.
- Basic authentication disabled, require client certificate. Will let you synchronize as long as you provide a valid certificate.
- Basic authentication enabled, require client certificate. Will let you synchronize provided you supply both a valid certificate, and a username & password combo.

You can test out all combos with a device, and/or my utility, but I’m getting differing results testing in a browser. (Which is not the recommended way to test EAS anyways.) Pick your poison as to whether you’d like to use a real device or my utility but at this point it’s easier to ignore real devices and get back to those later. What this means is that whether you enable or disable basic authentication, (in addition to requiring certificates of course), dictates whether you require one or two factors for authenticating the users. You’ll see the 401 and 403 error codes when testing if you don’t get the authentication right.

I guess we’re doing fine so far aren’t we? But so far we have concerned ourselves with the easy part of the equation. Play around with the settings and see if you can make it work, and in the next installment I’ll have a crack at making it all work from outside your LAN