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.
Excellent article!! When I did this a while back I was hoping this would make it easier for the user by not needing to enter username and password on their device and also no need for them to change password every 90 days or so when they changed it on their account in AD. But this turned out to be the complete opposite.
First, getting those certificates on the devices turned out to be very tricky for most mobile phones. So that left us with the IT-department needed to configure the devices for them (using username and password, at least we could guide them over the phone if they were on the other side of the country).
Secondly, if we looked at the scenario that the phone was lost and if we decided to Revoke the certificate, it took several hours before the authentication stopped working. I don’t know if this is a setting on how often TMG checks the CRL but if someone looses their device we want to make sure those credentials are changed/revoked. Of course, there are many other security measures we can take like RemoteWipe, automatic lock of phone after X minutes but anyway…
You asked for it, so I’ve tried to come through on your request
(As I said before it’s something I’ve been meaning to explore for my own sake as well.) I’m happy with the way I got it working server side though. Yes, the certificate deployment scenario still remains, and no matter how much we tweak it I’m not sure we’ll achieve the same levels of usability as username/password.
My thoughts on the enrollment bits of it is that using SMS as an out-of-channel communications channel it should be possible to build something on top of Windows CA in it’s standard form and get the certificates out to the devices some way. I have not explored the details of this yet, so we’ll see if it’s something I get around to later.
Combined with an MDM solution it should also be possible to make it more manageable for the end-user. Sure, you’ll have the challenge of sorting out which devices support a client certificate scenario, but in my opinion you should always have some sort of control over which devices are allowed in an enterprise scenario. Not saying it has to be narrowed down to two Windows Mobile devices, but letting the user choose just about any device poses challenges.
There are some settings in TMG both for the CRL updates/caching, as well as re-authenticating certificates, but I have not experimented with these. It’s the same when you’re using basic authentication too – changing password in AD will not lock out the device immediately. I have seen devices happily syncing for another hour before it stops. But of course – if a device is lost a wipe should be issued as well. And if you’re running power-on-password protection too it’s not that likely that someone will read out the info on the device.
What computer do you put in the “Delegation” tab? Is it the Exchange Server, or the TMG server? I can only get “401 – Unauthorized: Access is denied due to invalid credentials.” errors when I use the http/exchangeserver.test. You kind of imply you should use http/tmg.test which I then can’t get past the TMG Proxy, without an error.
I’m actually trying to configure Exchange 2010 OWA for Smart Card logon using TMG 2010. So far, I just get the 401 error… seems like KCD isn’t quite working yet, but I’m not sure where it’s failing.
–Reference–
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):
Well, I didn’t really make that too clear in my post since I blanked out parts of the screenshot
(I added a clarification above.)
The computer account you add on the delegation tab is your Exchange Server, or the one hosting the CAS role if you have split it into different servers.
Smart Cards should be the same as software certificates, as it’s just dedicated hardware for storing the certificate, but I haven’t the necessary tools for using smart cards in my lab so I haven’t tested that.
ahh.. ok, I got it figured out. The problem I was having was.. IIS’s Auth Provider wasn’t configured for negotiate. It was blank for some reason. And the “Delegation” tab should be setup for the other server to be clear.
Great article.! Can you confirm two things about this solution please. Our environment is Exchange 2007 SP2 with separate CAS servers. Now we wish to publish ActiveSync for a batch of users and would like to use certificate based authentication.
1. Is it a requirement to have an Enterprise CA integrated into AD or can it be done with an Standalone CA or 3rd party CA ?
2. Must the ISA server be a Domain Member server in order to use Constrained Delegation? Is there any alternative if the ISA server in the DMZ is not a member of the Domain.
1. You can do it with a stand-alone CA or third-party by configuring the “Client Certificate Trust List” and “Client Certificate Restrictions” tabs on the listener. (Advanced Authentication Options.) If you do this you should use username/password in addition as there is no direct correlation between the CA and AD. I would probably go down the route with an Enterprise CA, but of course since you bring up this question you probably have a reason for doing so
(Note – I do not have an ISA server available to check if these options are there as well, I checked on a TMG server.)
2. The ISA/TMG doing the KCD delegation must be a member of an AD domain. If you have a scenario where your ISA is in a workgroup in a DMZ you can use this as a front-end ISA and configure an additional ISA as a back-end where the latter is joined to a domain.
Hi Andreas,
I have an exchange 2010 running on windows 2008 r2. The server also hosts ActiveDirectory, DNS, Certificate Authority & SCEP.
I am looking for some assistance on ‘how to get client certificates’ for authentication and secure mail such that the mobile devices can sync mail via Microsoft activesync. Using the certificate the devices should be able to sync email. There should be a need to enter the password for authentication.
At a later stage i want the devices to use the SCEP to procure a cert (using a templete) from the CA and authenticate to exchange to sync email.
Would you be kind enough to help me on this subject
What’s the challenge you’re currently facing? Have you configured Exchange for client certs, and just need to finalize the rest of the config? Or are there other issues holding you back?
You don’t specify which devices you are using, and what other components there are in the infrastructure. Since you’ve got all services running on one box I assume you’re either working in a lab environment or using Small Business Server? (You really do not want all those services installed on the same server in a production environment.)
iOS, Android 4.0, and Windows Phone Mango are all able to use client certs for ActiveSync.
Only iOS natively supports SCEP, and it is possible to use SCEP-enrolled certs for ActiveSync.
Let me know where you need pointers and I’ll try to help out.
Hey Andreas,
Thanks a lot for writing these articles. I’ve been on a quest to find a solution to users having to enter their credentials constantly on iOS devices due to password expiry. I had been discouraged about certificates because another site mentioned they only function as an additional factor in the authentication and cannot substitute for username/password auth.
From the looks of your article though, unchecking the box for basic auth should make EAS authenticate entirely via certificate–which is exactly what I want.
I’m in the process of putting all the pieces together right now. I’m sure I will be admonished for this, but I will be using SBS 2011 (the full one, not the essentials version) to do all/most of the heavy lifting. This indeed is a small business and I’ve relied on SBS for the better part of ten years now and at this point I’m comfortable with the pros and cons.
I also don’t think I’ll be using Forefront TMG. I use pfsense for firewall, SPI, UTM stuff and don’t really feel like complicating that at this point in time. I just pass 443 through the firewall, which is how SBS is configured to do it. I can understand the reverse proxy for big organizations with deep pockets but for small business I’m not sure it’s worth the costs involved. I do want to ask though if for some reason it’s more advantageous to use TMG when doing EAS via certificate auth versus basic auth?
OK so SBS comes preconfigured with the CA role and issues self-signed certificates to users and computers. So I am wondering if it would be best just to leverage the built-in CA or if I should dedicate a separate machine (which would be virtual anyway) for this. Sadly I haven’t had to mess around much with certificates (other than installing one from GoDaddy for the server so that EAS and Outlook Anywhere work properly without throwing SSL warnings).
As far as deployment goes, I’ve set up a Mac Mini running OS X Lion (with the Server add-on) and am investigating its new “Profile Manager” which should be able to automatically deploy and update configuration payloads over the internet to our “fleet” of iPhones and iPads. I’m fortunate that I don’t need to account for any other type of client (no android, WM, blackberry, etc.) so I think that Profile Manager should be able to facilitate the deployment of the user certs to their iOS device(s).
My ultimate goal here is to also set up WPA2 Enterprise protection on our wireless network (right now it’s just a PSK) and have the certificate authenticating the wireless be deployed to each iPhone as well as the user certificate for EAS. Maybe even the same certificate can accomplish both feats–I don’t know.
I think this really could be a slick solution if I can manage to get it implemented properly. I’m going to get everything set up in a lab first before I even think about flipping the switch. If you have any tips or advice for me (order of operations, potential gotchas, security considerations, etc.) I would greatly appreciate it. PKI looks daunting from the outside (which is why I’ve mainly tried to avoid it thus far) but I think it would present some pretty helpful advantages where end users are concerned. If I can eliminate the regular calls about peoples’ iPhones popping up password prompts I’d be a very happy IT guy!
Thanks very much.
P.S. Any idea on certificate auth for “Outlook Anywhere” (which I think is the latest name for using the Outlook client over an SSL link). I have some users that are purely out in the field and never come into our office. When their passwords expire Outlook isn’t much help. Irconically, OWA (which is less full-featured than Outlook in almost every other regard) deals perfectly with expired passwords and makes it easy to change. Seems Outlook (despite being given a facelift every couple of years) still cannot facilitate password changes nor can it use certificates in lieu of password-based authentication. Sigh…
Dan,
You’re onto something here
It’s true that most client cert deployments employ the certificate as an additional authentication factor, but it is possible to have it replace username/password. But most ActiveSync clients will not let you do the configuration wizard without entering “regular” credentials. If you configure your IIS to ignore this it shouldn’t matter though.
I learned to hate SBS after I inherited a domain with SBS 2003 and a non-optimal configuration. I was later able to throw it out and rebuild the domain using Standard Edition 2003 and stand-alone Exchange which made me much happier. I hear that the newer versions have improved a lot though, so as long as you know what you’re doing you should be fine.
I like passing traffic through TMG for things like this, but it’s not a must have, and just piping 443 to Exchange should also work. Functionality wise you’ll be able to get client cert auth running both with and without TMG. Actually there’s more work involved if you’re using TMG and want to use both certs and username/password, but since this is not what you’re looking for that’s not a dealbreaker.
You can use the CA on your SBS box. What you need to decide when it comes to the CA is whether it should be accessible over the Internet as well, or only internally. When setting up the iOS devices they need to communicate directly to the CA after receiving their profiles – so if it’s only available on the LAN users need to be in the office to configure their devices the first time.
The certificate you acquire through SCEP can also be used for WiFi and EAS. With WiFi it’s a logical fit since the cert identifies the device, but with EAS that might be less logical. (Still workable, it’s just that you would in theory prefer a cert issued to a user for a purpose like EAS.)
So, yes, setting it up correctly you can automate the config with Profile Manager, the device automatically enrolls for a client certificate, and this is automatically used for both WiFi and EAS.
I have seen a guide for setting up Outlook Anywhere with certs, so that’s also doable. It’s a bit more tricky to get right than EAS though. Unfortunately I cannot remember all the details, but I found the guide somewhere in the TechNet library.
PKI can be a complicated topic if you want to do a deep-dive, but learning the basics isn’t that hard. (I’m certainly not a guru myself.) Certificates have been getting more and more important the past couple of years, so I would definitely recommend spending a couple of hours getting comfortable with the concepts.
I’m trying to deploy certificate based authentication with an iphone using a standalone exchange 2007 with client acces role on windows 2003 server and IIS 6.
I configure Exchange to require certificates without basic authentication and i’m getting 403 errors.
Is there something else i’m missing from the configuration?
Thank you
Have you mapped the client certificates to Active Directory?
Check the following links:
http://technet.microsoft.com/en-us/library/cc757474(WS.10).aspx
http://technet.microsoft.com/en-us/library/cc758484(v=ws.10).aspx
Andreas, thank you for the detailed response and words of encouragement. It’s great to hear that this is indeed possible and doable with the setup I’ve got. And I fully understand peoples’ qualms about SBS. There are lots of restrictions with it. But for the right circumstances and when set up properly it really is sort of a neat product.
Can I ask for a couple of points of clarification in your post? Here goes:
1. You say that “most ActiveSync clients will not let you do the configuration wizard without entering “regular” credentials. If you configure your IIS to ignore this it shouldn’t matter though.” I assume this applies to iOS devices as well? If so, then can you point me in the right direction as to where in IIS I would find this setting? Actually, I’m not terribly opposed to users needing to authenticate via username/password the first time the account is configured–it’s really the subsequent prompts after their password expires and is changed that I’m looking to solve. But if it’s easy to cover both bases with the cert then all the better.
2. You say ” What you need to decide when it comes to the CA is whether it should be accessible over the Internet as well, or only internally. When setting up the iOS devices they need to communicate directly to the CA after receiving their profiles – so if it’s only available on the LAN users need to be in the office to configure their devices the first time.” So I’m curious about this and maybe how it relates to #1 above. Why does the CA itself need to be accessible to the internet? Is it a matter of opening additional ports in the firewall or does it all get routed over 443?
My plan was to manually export each user’s certificate (this is a small business and a brand-new domain no one is using yet so this is feasible) and load it into a profile on Lion’s Profile Manager so that all they would need to do is connect to Profile Manager, accept the profile, and would automatically get their domain user certificate loaded on the device.
I guess I just assumed I could do that–I don’t yet know for sure but I thought so. If I can do that then does my CA still need to be internet facing?
3. In regards to Outlook Anywhere, all I’ve been able to find is a few documents talking about how you can now use certs on smart cards for authentication–but that might be a bridge too far for us. Smart cards have always intrigued me but I haven’t really found any reports of any small businesses using them. Maybe that can be next year’s project.
But seriously if you think you really did see a walkthrough involving Outlook Anywhere authenticating with a certificate installed to the local certificate store please let me know–I’d be very interested in that.
Thanks again for patiently answering my questions!
I love the idea of SBS, and before virtualization became as popular as it is now I might have opted for it at home. But there’s nothing holding me back on the hardware side these days to run an “enterprise” setup at home. (Depending on the definition of “enterprise” of course.)
1. Whether you want both methods for authentication or just one can be controlled by just flipping the basic button on/off (as shown in the LAN side article: http://mobilitydojo.net/2010/05/19/securing-exchange-activesync-with-client-certificates-lan-access/). But keep in mind that if you enable basic auth it will not apply just the first sync, and then users will have to re-enter the password but keep the cert (for the duration of its validity).
2. Now, I wasn’t entirely technically accurate on this point. The iOS devices don’t need to communicate with a CA to use client certificates for EAS. But the devices will need to enroll certificates if you will be using the MDM API. I haven’t tested Profile Manager in Lion (laziness I guess since I have access to a Mac Mini running Lion Server), but if you want to use it for things like remote wipe you will need MDM. There might be an option to deploy profiles without MDM, (then it’s more of a fire and forget installation of profiles), and then you wouldn’t need the CA.
Now of course, access to a CA for management is one thing, for enrolling client certs it’s another thing. For a small biz it could be feasible to go with your approach and manually export each user’s cert and load into profile manager (or iPCU for that matter). With iOS you should then be able to load up the entire ActiveSync profile so the user just has to enter their password.
3. Maybe my memory is slighly fuzzy in this respect. I don’t find any papers where Outlook Anywhere is secured with user certificates. There is the smart card approach, but perhaps I was thinking of the IPSec solution where you need a machine certificate to bring up the tunnel and then do the actual auth with basic auth.
More info here: http://blogs.technet.com/b/exchange/archive/2010/12/06/3411637.aspx
Still, it’s on a level where I probably wouldn’t implement it for a small biz. Might even make more sense to go for DirectAccess, although that’s also quite a bit of work at present with ForeFront UAG. There are apparently some changes in Windows 8 Server on this part, so I’m currently considering whether I should migrate my own UAG DA setup to Win 8 DA.
Andreas, thak you for the response
I also mapped the client certificate to Active Directory and i also imported the certificate to the user account, but the problem was the same.
I tested with Directory mapping in the web sites properties and also with 1 to 1 mapping in the Microsoft Exchange ActiveSync IIS virtual directory.
I’m start thinking if the problem is with the certificate profile. I’m using a certificate from VeriSign. Do you believe that the certificate must have a specific profile to work with this?
The only way that i managed to make it work is by using both basic authentication and client certificate (required in IIS). In this case, even without setting the certificate in the iphone email client but just importing it to the device, the exchange sync worked. But in this case, i think that the use of this certificate is like a device certificate and not like a client certificate, since it is used only to pass the certificate authentication in the IIS and then the credentials are been used for the client authentication to the exchange.
But the thing is, as Dan said, to avoid using credentials since these are expiring every month according to the domain policy.
Thank you again for your time answering my questions
It could be that it works when both basic and certs are checked because IIS then only sees the correct username and password. IIS7 doesn’t work that way, but I do not know the details of how IIS6 works in this regard.
The client certificates being issued by VeriSign could be an issue. The AD mapping assumes that the public key part of the cert is in AD, but that would most likely be missing with Verisign client certs. I would recommend using an internal CA for issuing client certs; both for reasons of cost (internal ones are more or less free) and the fact that you have complete control over the entire process that way.
Hey Andreas (and Kostas–seems we are aiming for the same thing).
I have finally gotten a chance to set this all up. It’s been quite complicated (mainly the Lion/Profile Manager stuff)… and I think I’m stuck at the same place Kostas is.
Trying to be concise here, I’m using the built in CA on the SBS server. I set up a user for myself in AD on the SBS box, logged in as that user on a workstation and requested a user certificate from the CA. I exported it from IE with the private key and put the passcode on it.
Skipping over all of the Profile Manager setup because it’s boring and not really relevant–it does work though.
I created a profile for myself in Profile Manager and set up an ActiveSync payload. I filled in everything requested–account name, domain, user, email address, password, server name, checked use SSL, and finally added my user certificate to “Authentication Credential” and filled in the passphrase.
As a pre-test I went into Exchange console, set it to require certificates but left basic auth checked.
I then took an iPod touch that had nothing configured on it (not enrolled with profile manager) and went through the motions of setting up an Exchange account the manual way, filling in all the particulars as usual. I got an error message (can’t remember exactly) which I expected since my certificate was not installed on the device.
So then I uncheck Basic Auth in exchange console and get to work on the profile manager end. I enroll the iPod no problem and then I applied my user exchange payload to it. Immediately what comes up is a password prompt. Even filling out my current user password results in the box coming right back up. Leaving password blank does the same thing.
So thinking that maybe it needs basic auth for the setup phase I went ahead and re-enabled basic auth in exchange… and before long the account was being provisioned and everything was working (prompted to set up the device passcode first). So then I unchecked basic auth again and… password box came right back up and would not accept either current password nor blank password.
I thought maybe I could just backspace out the password in the setup screen for the account on the iPod but as soon as you erase everything in the password field the helper text says “Required” and you can’t click the Save button anymore.
So I guess at this point I’m not sure if I overlooked something or if maybe this is a limitation of the iOS ActiveSync client. I also thought I would try disabling the activesync policy on the exchange server to see if it’s something about the passcode requirement that’s causing this (admittedly a super long shot, but not sure what else to try).
Any ideas? Did you actually get this working with iOS, or Android or some other client? It’s a bummer to have come this far for nothing.
Thanks!
Holy crap, I think it’s working. In a last-ditch google search (I really thought I’d already found all of the sites that discuss this) up comes this page:
http://certcollection.org/forum/topic/108261-certificate-based-authentication-exchange-2010-windows-2008-r2-iis-75/
Therein the author describes a crucial manual edit you have to do manually to the ApplicationHost.Config file. Apparently just enabling Active Directory Client Certificate Authentication in IIS manager isn’t quite enough, as it’s apparently still not enabled for the activesync site. He instructs to go to the:
section of the file, find and change it to false, followed by an IISRESET in command prompt.
Like magic, after doing that, it seems to be working. The iPhone still won’t allow a null password but as long as you type anything at all in the box, you get all the checkmarks and everything seems to be working!
Obviously I need to do some more testing, as I just found this 20 minutes ago. But it’s very encouraging to put in a nonsense password and have the iPhone accept it–that’s a lot further than I was getting an hour ago.
Kostas if you’re still around maybe that will solve your issue too? Andreas do you have any comments about this change? Apologies if you already mentioned it somewhere and I overlooked.
So thank Andreas and also to “mashti” over at certcollection.org!
I actually did a fist-pump when it worked. Sigh… the things IT nerds get excited about.
Oops… the sections in the file were enclosed in lessthan/greaterthan brackets and the site parsed them as HTML (of course). Just visit the link to get the scoop!
OK for my fifth-straight comment I just want to report that this is definitely working. In fact, after removing the old payload and starting over I was never even prompted for a password on the devices.
It’s really pretty slick. I have pre-enrolled the serial numbers for all of the iOS devices in the Lion profile manager and it created a .mobileconfig file I can host on the web. All my end users have to do is tap on that file, click Install on a couple of prompts and then their device will automatically provision their exchange account and WPA2-Enterprise auth for our wifi network.
Aside from the setup, the painful part was logging in as each user to request, install, and export the certificate. I only have 30 activesync users and this is a brand new server I haven’t put in place yet, so it was no problem for me to log in as each user to get the needed cert. It was still quite time consuming though, and would be a nightmare for any kind of larger organization or one where users have already changed their passwords. It would be interesting to see if there is some way the process of obtaining the user certificates could be automated somehow.
Anyway, for any one else thinking about this–it does work if you can get all the pieces into place. We are lucky that all of our mobile devices are iOS (and have a Mac server at our disposal) as the Profile Manager part of this is what makes it so convenient… I don’t need to instruct the end users to do anything complicated and they don’t need to bring in their phones to me at all.
Furthermore, now no one can add an activesync device without my being explicitly aware of it. The way I’ve set it up, I need to pre-enroll devices via their serial number before our profile will install on it.
Thanks for the encouragement Andreas!
I am familiar with the setting for enabling client cert authentication in IIS, but it does seem like I didn’t include that in my guide. I can’t remember why I left that out, it probably would make sense to have it included.
Anyways, great that you got it working of course!
It is indeed quite slick when you get things working like that. But as you yourself say it’s only manageable in small scenarios. Once you start adding different Android devices, and a larger number of users it will get more complex