Regarding the certificate enrollment – thiw will surely be a problem in our scenario. We have offices all over the country (without local IT support), and the users are instructed today to simply go to the nearest shop of the chain they buy from and get a new phone if it breaks or they need a new one. Asking them to enroll for an certificate using Windows Mobile Device Center just feels like asking for trouble . But the PFX files could definitely be a solution – I didn’t realize this actually was possible since everyone seems to state you need Mobile Device Manager.

Looking at how to enroll for certificates according to Microsoft (http://technet.microsoft.com/en-us/library/ff459604.aspx) they suggest to use the ExchangeUser template rather than a User template. Looking at the (default) ExchangeUser template, this only allows usage for “Secure E-mail” not “Client Authentication”. This can’t be right, so I sugess Microsoft simply forgot to mention the details regarding this. I used the normal User template and that worked, but I guess creating a seperate template would be a good idea to be able to identify which users actually have certificates enrolled for Mobile Devices to authenticate with ActiveSync.

Let me know if you have any other comments/experiences from the real world when implementing certificate-based authentiation for ActiveSync.

While I have no doubt private keys can be exported from a WM device given enough effort, it’s certainly no easily accessible interface for the user that I am aware of, and I have not located an easily accessible API for developers to do so either. (The private keys are stored in a special part of memory that is protected.) Windows Mobile is Common Criteria certified so I assume this is implemented in a proper way. The certificate template used should have private keys set to non-exportable as an additional measure.

As for enrolling the certificates; yes, you need to provide username and password if you use my utility. And user certificates will be issued. Thinking about it you’ll see that device certificates doesn’t make sense for ActiveSync. You wouldn’t associate an Outlook installation with the computer it’s installed on either. Device certificates can be implemented as a separate measure, where you use a device certificate for authenticating the network access much like NAP in Windows Vista/7, or for an L2TP VPN connection. But that’s a separate topic

The password should be flushed from the device after enrolling the certificate, and this is handled automatically by Windows Mobile Device Center per my understanding. With my utility the password may be cached until you soft-reset, but it’s never associated with ActiveSync.

The link you provided implies that the Exchange server needs both basic authentication and client certificate based authentication enabled. This isn’t entirely true either. This assumes you follow a procedure where you the wizard attempts sync with username/password, but is informed by the server (after authenticating I believe) that a certificate is required. Following my findings in a previous article (http://mobilitydojo.net/2009/03/24/personal-certificates-and-exchange-activesync/) you can disable basic authentication and enable only client certificates provided you perform the additional settings. As I said, I would probably combine it all into one app of some sort to handle both ActiveSync provisioning and certificate enrollment (I did most bits manually in my article). These experiments were conducted only through direct access to the Exchange, and ISA/TMG would add to the complexity.

If you are so inclined you can also have some manual method where users or a certificate administrator have to copy pfx files (with private key included) copied to the device, installed, and then delete the file. This would eliminate entering passwords altogether. (You’d still need username, but that’s not sensitive info in the normal sense of the word.) Of course if you want total security you might still be interested in looking into options like writing an ISAPI filter, or other measures making sure only the specific devices you allow to sync. You know better than me where you draw the line between “acceptable security” and “too much hassle to implement”

I was given the impression that it would be a “client certificate” for the device itself, but the user still needed username and password because it says “in addition to the user name and password” in http://technet.microsoft.com/en-us/library/bb430770.aspx, but that doesn’t seem to be true since it’s a certificate for user authentication. I would guess that they mean that you need to supply user name and password when you enroll for the certificate?

Then I wonder, would you really consider certificate-based authentication to be any more secure than user name and password? Even though there doesn’t seem to be any way to export a certificate+key from Windows Mobile, I’m sure there are ways. So maybe the authentication alternatives are on the same level of security and you should consider additional security measuers, like the ones you state in your article above?

You cannot enroll for certificates through the CA’s web interface from the device since the plug-in you need is not available for devices. This was the same for 2003 CAs, but an additional component (that I’ve never tested) was available that enabled mobile devices to access the interface.

I was in the process of researching for a write-up of a complete certificate-based EAS setup with only client certs enabled on ISA. But my ISA failed due to hardware reaching their end-of-natural-life, and I never resumed it while running through the betas and RCs of TMG. Having upgraded the other major components of my infrastructure like 2008R2, Exchange 2010, and TMG RTM I don’t find it unlikely I’ll be having a fresh look at the topic. (Not sure if ForeFront UAG would be a better choice, but TMG should work too.

What caught my eye here: http://technet.microsoft.com/en-us/library/bb430770.aspx is that you need a domain-joined computer running Windows Mobile Device Center. According to http://searchexchange.techtarget.com/generic/0,295582,sid43_gci1356233,00.html that’s because from Win2008 (which we run) you can’t request certificates from a mobile device. Maybe this is an alternative to your util?

I would say putting a computer in the DMZ joined to your internal forest is never recommended. And if you look at the Microsoft Design and Planning guide for TMG/ISA at http://technet.microsoft.com/en-us/library/dd897048.aspx you see that they recommend a different forest. Although with a one-way trust but I wonder if Kerberos Constrained Delegation will work then. You could always do SSL tunneling straight to the CAS but then you have other (worse?) security issues.

Have you ever implemented certificate-based authentication with ActiveSync and ISA?

I’m a fan of certificate-based authentication, because once you get it working it’s secure and usually not so bad from a user perspective either. Configuring everything, and making it all work is not necessarily a cakewalk though (especially with mobile devices). I’ve made a utility for enrolling certificates in a user friendly manner for Windows Mobile devices. The drawback is that you only get 1024 bit keys, and you have to be on the LAN (or publish your CA to the network you use), so it’s sort of limited in that sense.

I have been meaning to do some more stuff regarding certificates, but as we all know – things take time

I’m not an authority on ISA, so I can’t say what the official best practice is, but from what I’ve read one of the better setups of ISA is to have a front-end/back-end ISA configuration where the back-end is domain joined, and the front-end is in a workgroup or separate forest. Whether ISA should be joined to a domain or not is one of the main discussions in the ISA community from what I’ve seen

What are your comments on certificate-based authentication and you have a manual process to issue client certificates? (I’m mainly talking Windows Mobiles 6.5+ here).

One thing I notice with Microsoft’s recommendations (http://technet.microsoft.com/en-us/library/bb794751.aspx#AppendixC) is that they assume the ISA server and CAS server is in the same domain but best practices is also not to put an ISA on the DMZ in the same forest as internal servers.

Thank you Bernhard