I have seen very little regarding this subject on the net, so I thought I’d write some bits on how to configure it and why you’d want to do that.
So, first thing first, using Kerberos as the authentication method should be a goal for all Windows sysadmins. Removing legacy authentication methods and progressing towards tried, proven and secure protocols is really important in providing your organization with a reliable and secure environment. Now, you say, isn’t EAS secure by default? It leverages SSL etc for encryption and that, as they say, should be that. Well, yes and no, SSL encryption will give you confidentiality on the wire while connected to the server — provided you’ve updated your server to prevent from the recent SSL vulnerability. But really, SSL is not the issue here. What we’re concerned with is the way we authenticate to the service and how it, in turn, authenticates to the internal resources.
I would estimate that the majority, or maybe even somewhere in between 90-100%, of all EAS installations uses one or more Microsoft ISA servers for publishing EAS onto the Internet. In it, the default “wizard” for publishing EAS sets up an SSL based publishing rule that does a standard basic authentication inwards towards the /Microsoft-Server-ActiveSync/ directory on one or more client access servers.
The whole idea with this post is to give some guidance on how to enable Kerberos from the ISA server on to the CAS and, in turn, enable it to do Kerberos to other CAS servers or even legacy Exchange 2003 back-end servers. So this is how you’d do it:
Before starting out, you need to realize that for this to work, your ISA server must be a member of your internal AD domain. If this is not an option for you, this post cannot help you and you can stop reading now.
First of all you’ll need to enable form-based authentication on the web-listener! This usually goes against the common way of settings things up when it comes to supporting legacy cell phones — like e.g. SE with roadSync clients, but! you need to set up FBA with the option of “Do not always authenticate users”. By doing so you’ll make sure that phones that cannot do FBA gets an error and then tries HTTP AUTH instead.
Second, on the EAS publishing rule, you need to enable Kerberos constrained delegation. This is done on the Authentication delegation tab. On the same tab you’ll get information about a SPN (Service Principal Name) that you need to configure on the ISA server object in Active Directory. So you go into ADUC and locate your ISA server object, bring up properties and the delegation tab. In it you choose “Trust this computer for delegation to specified services only” and then you add the http service of your CAS server/s.
Third, on your CAS you need to enable Windows integrated authentication and on an Exchange 2007 computer you’d do that from IIS manager on the /Microsoft-Server-ActiveSync/ directory — just add “Windows Integrated” to it.
Fourth, on your CAS Server, you’d need to do the second step for all CAS servers you expect to authenticate to, also the third step must be carried out on each and every one of the “secondary” CAS servers. On your Exchange 2003 servers you need to install a patch that enables you to edit the authentication settings for the actiesync directory. Then in ESM you can edit to enable the integrated authentication. Now, this is important because the MS System Attendant will override any setting done through IIS.
I know this is not exactly straight forward, but it has worked really well for me. There are at least one caveat, and that is that you can’t in ADUC do SPNs for objects in other domains.