Tuesday, 8 April 2008
Mutual authentication and URL Branding with an Outlook Anywhere / RPC over HTTPs connection
With Exchange 2007 not ‘officially’ supporting Forms Based Authentication nor Outlook Anywhere on more than one site (whether that’s the Default Site or not), it has become slightly more difficult to create URL branding for customers that require this within a Hosted environment. With Exchange 2003 you could create multiple sites and FBA was supported in all – Microsofts stance with Exchange 2007 is that if you need FBA on more than one site per CAS then you use ISA Server to support this. And another issue, although the use of ISA allows multiple sites with FBA enabled (albeit offloaded on the ISA server/s) still only one site is supported for the use of Outlook Anywhere (read: RPC over HTTPs). Again with Exchange 2003 it was simply a case of copying the RPC Virtual Directory to your other sites.
The advent of SAN (Subject Alternative Name) certificates have greatly helped our design of a Hosted Exchange 2007 infrastructure here at Cobweb. This has allowed us to implement cost effective Client Access Server design and support URL branding for the customers that require it – whilst minimising costs (dedicated CAS servers for every branding OWA URL we support or indeed take on with new business). For example an Exchange Hoster that wants to stay within a supported solution by Microsoft, that had say, 10 dedicated OWA URL’s would at a minimum have to deploy 10 CAS servers – and that doesn’t even take into account HA. To achieve that (at the most basic level without taking the numbers of users hitting each URL) you would need 20.
This is where SAN Certs come into their own. All branded OWA URLs can be appended to the certificate along with other Exchange services/protocols (autodiscover, POP3, IMAP4 etc). This helps a Hoster significantly as well as give benefits to normal in-house deployments.
There is one ‘gotcha’ however when using a SAN Cert for multiple OWA URLs for Outlook Anywhere access, if you enable mutual authentication for the session, you can’t connect on any of the Subject Alternative Names. This is due the client explicitly looking for a principle name in the certificate (which is matched to the Subject field of the cert):
Mutual Authentication isn’t necessary as all client machines connecting to us are deemed non domain joined (they could very well be in their own domain however) and these clients machines are unlikely to have any certificates published to them from their own Certificate Authorities.
Once this checkbox was removed, Outlook Anywhere worked for any of the branded OWA URLs held in the Subject Alternative Name field of the certificate.
Here is the Subject Alternative Name field of a cert:
Interestingly, the first OS to support Subject Alternative Names was Windows 98.
For Microsoft reference on creating Exchange Certificates and support for SAN certs with Exchange 2007 using the New-ExchangeCertificate PowerShell command see:
‘Certificate Use in Exchange Server 2007’ http://technet.microsoft.com/en-us/library/bb851505(EXCHG.80).aspx
‘Exchange 2007 lessons learned - generating a certificate with a 3rd party CA ‘ http://msexchangeteam.com/archive/2007/02/19/435472.aspx
‘Unified Communications Certificate Partners for Exchange 2007 and for Communications Server 2007 ‘ http://support.microsoft.com/kb/929395
MVP - Exchange Server