Securing Exchange ActiveSync with Client Certificates – LAN Access

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:
image

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

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:
image

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
image

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 🙂

25 thoughts on “Securing Exchange ActiveSync with Client Certificates – LAN Access”

  1. No me funciona. Error de SSL.

    Testing HTTP GET:
    Response: Error en el servidor remoto: (501) Sin implementar.
    Inspect the HTTP code given above.
    501/505: This is correct behaviour, and means it is responding!
    403: The server requires SSL and will not let you connect over HTTP.
    401: Wrong username/password. May also occur if you’re using a reverse proxy which performs authentication.

  2. Great article!

    Quick question: Can I have some EAS clients authenticate with username/password only (no certs) and have others just use client certificates (no passwords)?

    It sounds like that flexibility would be possible if “accept client certificates” is chosen as well as having “basic authentication” ticked. However your post above seems to indicate that it’s an all-or-nothing thing.

    I’d really like to have clients pick whichever auth method they’d prefer, so hopefully it’s possible!

  3. What you want is one of the common challenges holding back client certificate authentication scenarios. Sure, works with Windows Mobile, but what about Android, etc?
    If the devices connect directly to Exchange I am not aware of a good solution for doing this. I can think of some hackish approaches that I haven’t tested, but by default it’s all or nothing. (If someone with deeper knowledge of IIS knows something I don’t feel free to correct me.)
    If you are using ForeFront TMG or a similar solution you can handle it. With TMG the authentication is performed at the edge, and delegated to the Exchange Server. By using the “Fallback” option in the web listener the server will first ask the client if it’s able to provide a client certificate, and if it isn’t able to do this it can fall back to basic authentication instead. So if you have a TMG server it’s not so much work to implement, if you’re just using a basic firewall in front of Exchange it might not be worth the effort trying to make it work.

  4. I was looking forward to following your guidance but it seems I’m a few steps behind. For client certificates, I wanted to create self-signed certs. I attempted using OpenSSL For Windows, mostly following the info at http://serverfault.com/questions/168580/creating-client-certificates but when it came to step 6 to sign the client certificates “with the CA cert” I never have gotten the openssl.cfg file right do get it to open the ca.key.

    Can you refer me to better guides to create certs for mobile devices or do you have any comments that might provide guidance so I can get to the point of testing with your emulator program?

    Thanks.

  5. I did finally get the certs created as outlined in the article I referenced earlier, but I’m not sure I know how to import/enroll them.

  6. The documentation to which one is referred for client certificate mapping authentication says that for using AD authentication, both the server and client have to be members of an Active Directory domain. For the testing that might work, but the mobile devices are not going to be members of the/a domain. Is this an issue with client certificate mapping authentication using Active Directory?

  7. The client in the case of the mobile devices is the TMG server, or a similar solution. The certificate is what proves the identity of the mobile device, but TMG needs to be a member of Active Directory to use Kerberos Constrained Delegation.

    There are differences between the mobile operating systems as to what format they like their certificates in, but both Windows Mobile and iPhone are happy to use pfx files whereas Android prefers it as a p12 (which can be just a renamed pfx file if you like). The details of how to import them and use them is also slightly out of scope for this article – as I’ve said before in a number of articles. You will need to do testing before using client certificates, but once you get it working it’s real nice 🙂

  8. Couldn’t get it working until I ran the following commands:

    appcmd unlock config /section:clientCertificateMappingAuthentication
    appcmd set config “Default Web Site/Microsoft-Server-ActiveSync” -section:clientCertificateMappingAuthentication /enabled:true

    I kept getting 401.2.

    I’m using Moxier Mail on Android which does support client certificates as well as S/MIME signing and encryption.

  9. It could be that your server is more tightened security-wise than my lab environment 🙂 But of course in a production environment one should be doing so, so it’s a useful tip (will insert it into the article).
    Haven’t gotten round to testing Moxier – I usually prefer to not having to resort to third-party utils/sw for what I consider basic functionality. (In my opinion the lack of proper Exchange support on Android is something Google should be ashamed of.)
    But unless S/MIME & client certs support shows up in the Samsung Galaxy S II (I mean – the Gingerbread ROM for the S is promising) I’ll eventually have to test Moxier or TouchDown properly.

  10. I keep getting this error using the utility. I have SSL and certificate both checked. But all iPhones and iPads are ok. Is it normal?

    Testing HTTP GET:
    Response: The remote server returned an error: (403) Forbidden.
    Explanation:
    The server requires SSL and will not let you connect over HTTP.
    (For instance trying to connect over HTTP while IIS requires SSL.)
    Status: Further action required
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Testing HTTP OPTIONS:
    Response: The remote server returned an error: (403) Forbidden.
    Explanation:
    The server requires SSL and will not let you connect over HTTP.
    (For instance trying to connect over HTTP while IIS requires SSL.)
    Status: Further action required

  11. If iOS devices are working your ActiveSync setup should be good in general – does the 403 error only occur with my utility or also with Android devices (if you are able to test this)? The 403 error indicates that for some reason you aren’t allowed to use the service, even though it’s most likely up-and-running. Do you know if the Exchange Server is running any kind of filters as to which devices are allowed? Or does it require client certificates perhaps? A reverse proxy in front performing additional checks?
    Is this Exchange 2007 or 2010?

  12. Thanks for your response Andreas. The 403 error occurs on your utility and Android devices. The Android devices would work only if the Exchange 2010 is set to “ignore client certificate”. There’s also no rules to govern which device can log on. We even allow non-provisioned devices.
    A client certificate is needed but I’ve tried the certificate on the utility and android without any success.
    I don’t know what else to check.

  13. Well, ok, then the 403 would indeed be caused by failing client certificate authentication.
    iOS devices have good support for client certs so they usully work nicely once they’re configured. Android can be a hassle with client certs (as they’re not supported in the native EAS client). Are you using a third-party ActiveSync client? TouchDown from Nitrodesk supports it, and the newer Samsung support it (you don’t get to configure it without MDM though). Ice Cream Sandwich should bring native support for client certs. So I can’t really tell why it’s failing on your Android devices without knowing more.
    As for why it doesn’t work with my utility..that’s on my table 🙂 I have tested my utility quite extensively against both Exchange 2007 and 2010 with and without a ForeFront TMG in front. Do you have the client cert as a pfx file with a private key? And password protected? Does my utility give any errors indicating it’s not able to read the certificate? (I assume you are using the latest version of EAS MD.) Is your Exchange server configured to require both username/password and a client cert, or only certificates? Is the username in user@domain.com or domain\user format?
    Try to remove the fake device from OWA (if it’s present) and re-attempt to sync.

  14. I got the following error
    Testing HTTP GET:
    Response: The remote server returned an error: (404) Not Found.
    Explanation:
    File not found shouldn’t occur…check IIS that files are not missing.
    Status: FAIL
    which file ?.

    without clientCertificate in the server active sync works but i get the same error with your tool.
    thanks arnold

  15. So configuring the Exchange IIS settings for plain basic auth works with both devices and my utility? But it fails when checking any of the Require/Accept certificates in IIS?

    Are you accessing Exchange directly or through a firewall/proxy?

    And you’re using a pfx file with the correct password?

  16. Hi Andreas,

    I’m still trying to get it work. I run your great tool from my SBS 2008 and am using a certificate which I downloaded from certsrv from a client computer (mine) which belongs to the domain and was logged in as user from that domain (me). I’ve tried your tool by specifying my username, domain, server address as localhost, use ssl. Use client certificate (the pfx file I exported from my client computer after installing it. I have also tried the .cer version without password), Certificate password And selected protocol version 12.1.

    I get the following message “The server requires SSL and will not let you connect over HTTP.” What might be the issue?

    My localhost has enabled authentication of Active-Directory Client certificates (Translate from dutch). My SBS Web Applications/Microsoft-Server-ActiveSync has SSL required-128 bits and client certificates required. And its authentication options of the website are all disabled.

    I would appreciate your help.

  17. Hi Andreas

    Microsoft support erecomended that I use your utility to help with diagnostics of errors I am getting in my EAS 2010 environment. I am using client certificates direct to the EAS no reverse proxy. I first tested using a PFX file with the password and I get the 403.7 error; but after reading through your site I used the CER file which seems to work.
    The problem is I do not understand how your utility completes the authentication (client TLS session) without the private key. Have I misunderstood how the utility works, or what it is testing??
    Obviously the mobile device requires the private key in a P12 or PFX file, but these tests are giving me the same error as above, 403.7.

  18. When you use a cer file the file acts as a pointer to the actual certificate which you probably have in your certificate store. So you are actually using the private key although the utility itself has no direct knowledge of it – just a quirk of how .Net works with the Windows OS 🙂
    When you’re testing with a pfx file (on the desktop) is this based on the same cert as the cer file? (Not just same common name, but same thumbprint.)
    Are you seeing the 403.7 error in the IIS logs when trying to sync from a mobile Device? What kind of mobile device are you testing with? Are you using client certs only, or a combo with basic auth?

  19. Hi,

    we have a strange problem on a w2008 r2 with exchange and sp3. After Installation of exchange sp3 all mobile phones with windows mobile 7.8 (Samsung Omina 7) stops syncing with activated “client certificate required”. Phone always asks for password and says wrong account settings.
    With client certificate ignored, everything works fine.
    BUT if i try connection with an iphone or your active sync test program it works with client certification.

    I tried owa with client auth required and this works fine on
    the w7.8 phones, so certificates shoulf be ok.

    Any Hint for this ?

  20. With the exception of a couple of minor bugs from time to time Apple’s implementation is usually not a bad ActiveSync client so if things work with iOS I tend to think along the lines of bugs in the other clients.

    Windows Phone 7.x supports client certs, but not in a very good manner. The cert is probably installed correctly if you can get it to work with OWA on the same device, but possibly something got messed up with the EAS settings. Have you tried removing the mail account and reconfiguring it?

  21. It depends on what you’re trying to do. Is the intention that those who can use certs should do so, while those who can’t should still use basic auth? Or is the intention that both should be in use?

    On the server side you can configure IIS to require both types of auth. You can’t easily configure a fall-back scenario with only IIS though. With some reverse proxies you can setup auth to attempt to use certs first, and fall-back to basic if that fails. (I’ve tested this with ForeFront TMG, but since that’s end-of-life it’s not my recommended solution.)

    On the client side I’ve had various levels of success with different EAS implementations. Not all EAS clients support certs at all, but of those who do some also require the username/password to be set, and some will only use the cert. And configuration through the interface on the device, and configuration done through an MDM platform can also differ.

    It is, as it often is, not as easy as one would have preferred.

  22. Hi,

    I’m trying to make EAS (Exchange 2013) working. but while testing with your tool, I receive the following error: The remote server returned an error: (403) Forbidden.
    Explanation:
    The server requires SSL and will not let you connect over HTTP.
    (For instance trying to connect over HTTP while IIS requires SSL.)
    Status: Further action required

    I’m trying to publish using WAP/ADFS (Windows 2012 R2). In the same time, OWA published with client certificate authentication works fine, and same cert is used to test with EAS.

Leave a Reply

Your email address will not be published. Required fields are marked *

*