Personal Certificates and Exchange ActiveSync

By now you might have been playing around with enrolling certificates on your own, either through use of my little utility or typing your own xml, or making your own utility for all I know. I mentioned previously that Exchange ActiveSync (EAS) was one candidate for doing something useful with a personal certificate. There are a couple of use cases for certificates relating to EAS:

  • Authentication to Exchange instead of username/password combo.
  • Encrypting messages.
  • Signing of messages.

Signing and encryption is more commonly referred to as S/MIME.

We’ll start with authentication. Which also happens to be a nice and tricky thing to research 🙂 I’ll make a few assumptions – I’m running Exchange 2007 SP1, but things should be similar on Exchange 2003. I’ve done my testing running Exchange on Windows Server 2008, but Server 2003 should behave similar even though IIS7 has some differences from IIS6. Since ISA Server unleashes a troubleshooting scenario of it’s own with Kerberos Constrained Delegation I’ve left that out of the scope for now. Actually the server side setup warrants a dedicated article so I’ll just assume you’ve got the server configured and working with client certificates. (Don’t know yet if I will provide my take on how to configure this, or if I’ll leave it to Google to provide reference material.)

Quick tip: To verify ActiveSync functionality (without involving a device) open up https://exchangeserver/Microsoft-Server-ActiveSync on your computer. You should be prompted for credentials and receive an error – “501 – Header values specify a method that is not implemented.” This works for both basic/integrated authentication and client certificates.

Microsoft also has a handy tool called “wfetch” that will allow you to skip the browser, and specify how you want to authenticate.
Link: https://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=…9210

Working out how to configure this using official Microsoft documentation is..well.. It didn’t give me every answer I wanted. Official documentation tells us two main things: you need to connect your device to ActiveSync/Windows Mobile Device Center to enroll for a certificate, and you need to perform the initial sync through the desktop as well. (Your computer also needs to be domain-joined, and you need to establish a partnership between desktop ActiveSync and device ActiveSync. It will not work in “Guest” mode.) And this procedure works, nothing wrong with that. But I think I’ve already touched upon the “Going Mobile” aspect of things before. I don’t like being tethered if I don’t have to. The problem is that setting up ActiveSync on the device the wizard prompts you to enter a password, and the device is hard-wired to attempt basic authentication first. After doing that you should be informed that certificates is the preferred way to go, and that your computer will set this up for you. (A registry value called “EnrollForCertOnNextCradle” is flipped to 1.) This means that depending on how you configure the rest of your servers, (for instance the already mentioned ISA box), you might have to configure Exchange to accept both basic, and certificate-based authentication.

I configured my Exchange to require client certificates, and to accept no other tokens of authentication. I then used my own utility to enroll a personal certificate. Since I could not configure ActiveSync through the wizard I wrote a configuration xml that I pushed through via RapiConfig.
Look up the Sync CSP on MSDN: http://msdn.microsoft.com/en-us/library/bb737700.aspx

Using only a minimum of configuration I applied the following provisioning document:

<wap-provisioningdoc>
  <characteristic type="Sync">
    <characteristic type="Connection">
      <parm name="Domain" value="MobilityDojo.net" />
      <parm name="Server" value="exchange" />
      <parm name="User" value="andreas" />
    </characteristic>
    <characteristic type="Mail">
      <parm name="Enabled" value="1" />
    </characteristic>
  </characteristic>
</wap-provisioningdoc>

I omitted the password (since this is part of what we are trying to achieve), but I did type in the username. I haven’t tested what happens if you omit the username, but you should probably do some testing and establish a process as to how you handle this when rolling out for production use. This is all standard procedure for provisioning the settings from a server and should be doable. Here comes the undocumented part – under the ActiveSync registry key on the device HKCU\Software\Microsoft\ActiveSync\Partners\{GUID} are two registry values I provided with a value:

EmailAddress I configured this with my email address, which is also defined in my personal certificate. (I’m thinking there might be some match checking between the two.) You can have multiple addresses as long as you separate them with semi-colons.

ClientAuthCertRequired I set this to 1 (as in required) as opposed to the default of 0.

The part that makes this hard to pre-provision is that these two keys are found under the GUID unique to each ActiveSync partnership. And you can’t guess this GUID before you have provisioned the sync settings.

I then proceeded to fire up ActiveSync on the device. It said there was an Exchange partnership, but that it had never been synchronized. I hit “Sync”, and the “green wheel” started spinning. I was never prompted for a password, and didn’t get to choose a certificate to use either, but after churning away for a while the device stated everything was in place and working like it should.

Now there might be a “hidden” reason Microsoft states you cannot do this, and there might be a flaw in my approach, but it sure does seem nice to do it like this. I’ll admit though that Microsoft are correct in the sense that it did require some tweaks to get this working and it wasn’t exactly available out of the box. (I have heard the argument before that coding is cheating because then you can do “everything”. Maybe, but MSFT could have provided some pointers even if it requires some legwork on your own.) If you are enrolling on the order of 10-20 devices you’re probably better off using the cradling procedure, unless you have a special interest in doing it different. This doesn’t pay off until you have an amount of devices that can justify that you configure and test provisioning xml, writing utilities, etc.

The manual tweaks yes…Allow me to elaborate on that part. It doesn’t seem very accessible the way I just described it. You probably don’t want to do all this xml thing for other than testing anyways. Your MDM solution of choice should probably provide you with options for setting things like server name, domain, etc. It’s probably not that much effort making it set the ClientAuthCertRequired to 1 either. Setting user name, and email address may or may not be supported depending on the scripting capabilities available to you. The approach I might be taking is to extend the certificate enroller utility I posted two weeks ago. I haven’t worked out the details for that however so for the moment I don’t have a new release available, and I’m not making any promises either 🙂 If you’re comfortable with Visual Studio you should be able to work it out though based on the bits I’ve provided in the sections above.

I’ll only briefly touch upon signing and encryption of messages. You cannot configure this before completing the first sync. This primarily being that you need to be running SP1 for Exchange 2007 server side, so the device needs to “negotiate” the capabilities before enabling this. The user then gets a new option enabled in his mail configuration due to the fact that he’s got a certificate on the device to sign and encrypt individual messages. Or you as MDM admin guy can configure that one or both of these is always a requirement for sending a message. There are already policies/settings for managing this in SCMDM, and most likely other MDM platforms handle this equally good. But then you have to choose signing and encryption algorithms and everything. You’re probably just as well looking up the official documentation on this topic, and make your own decisions:
http://msdn.microsoft.com/en-us/library/bb737380.aspx

I don’t know about you, but I think things are starting to shape up now, and we’re getting somewhere with the whole personal certificates concept 🙂

7 thoughts on “Personal Certificates and Exchange ActiveSync”

  1. So if I configure windows mobile device to use certificates (self-signed or 3rd party), user will not be asked to enter new password to re-initiate sync after user change password for his/her domain account? This is based on a scenario where user’s domain account password has to be reset every 90 days.
    I am trying to determine if there is an alternative to entering new password in the mobile device every 90 days.

    Thanks,
    GS

  2. With client certificates you do not have to re-enter your password on the device. By default a user certificate will have a valid period of one year, which means you must re-enroll every year, (and possibly use the password when doing this), but other than that the password is no longer an issue.

  3. Hi, Is there a way to have both password and client certificate enabled so as to double up the security. I would like to have the password re-entered on device if the AD password changes.

  4. Not to my knowledge. ActiveSync can only handle one authentication type. Part of the point in moving to certificates is getting rid of the password which in addition to the security perspective also is annoying from a user perspective 🙂 The certificate is separate from the password attribute so when using a certificate ActiveSync will not have any knowledge of expiration dates on the password.

    If you want to handle certificates in a more strict manner you can edit the template and set the validity to less than 1 year (which is the default). You can also look into enrolling separate certificates for the device and have this checked/verified at the edge (on something like ISA server) although this requires some extra work (read: coding or buying third-party apps). You can also put the Exchange server behind a VPN tunnel that requires username/password, but I would discourage you from doing this. (It’s not a good user experience if you experience drops in connections, and it will consume extra battery.)

    Combining some of the above you could go for SCMDM as a device management solution, but that’s a lot of extra work if you do not need an MDM solution 🙂

  5. Loading xml files on the device like this is a Windows Mobile specific thing.
    iPhone supports client certificates, and some Android devices do as well, but how you enroll the certificates for these operating systems would require a different approach.

Leave a Reply

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

*