Office 365 Hybrid Configuration Certificate Planning–ADFS, Exchange Web Services, OWA, OA

I recently wrote about configuring Office 365 hybrid to get cross premises availability working, since that article a number of people have asked me about certificate planning. This is pretty well understood for an Exchange deployment, but what names are required for an Office 365 Hybrid configuration during a migration?

Certificate Requirements in Office 365 Hybrid Configuration

The easiest way to determine your requirements is to make a list of client and service SSL endpoints that will be required on premises. For this example I will continue with my lab namespace of groovycloud.co.uk

Let’s walk through the services and where they are required in more detail…

ADFS 2.0

Active Directory Federation Services (ADFS) is used to provide a single identity to which users can logon and access both Office 365 service and on-premises services. This is generally a desired requirement for most deployments to avoid users having to remember multiple sets of account details. If you are deploying ADFS for Office 365 then you need to plan for a certificate to publish the ADFS 2.0 server externally, even if you only have on-premises clients (this is a relatively complex discussion, however the bottom line is that until SPNEGO is enabled all clients authenticating via ADFS will authenticate directly to Office 365 with basic credentials, Office 365 will then attempt to validate those credentials via your externally published ADFS namespace).

Exchange Web Services

Exchange Web Services (EWS) is used by many clients and services to gain access to Exchange 2010. Office 365 hybrid configurations uses EWS to provide cross premises availability (Free/Busy) and also to perform cross organisation mailboxes moves via the mailbox replication service. If you are planning an Office 365 Hybrid Configuration you must plan for a certificate to publish the EWS endpoint externally.

Outlook Web Access

Outlook Web Access (OWA) is used by many organisations to provide lightweight browser access to the messaging service, both internally and externally. If you are planning to co-exist OWA on-premises with OWA in Office 365 it is highly likely that you will want to plan for a certificate to publish OWA externally to provide a single OWA URL for all users.

Outlook Web Access (Legacy)

Outlook Web Access (OWA Legacy) is used to redirect users hosted on legacy versions of Exchange by Exchange Server 2010. This is required if you will have OWA users on both Exchange 2003 and Office 365. By moving your primary OWA namespace to your Exchange 2010 Hybrid server it is possible for end users to be redirected to both Exchange 2003 OWA and Office 365 OWA depending on where their mailbox is stored. If you are migrating from Exchange Server 2003 and are using OWA it is highly likely that you will require this and should plan for a certificate to publish your OWA Legacy namespace externally.

AutoDiscover

Office 365 uses AutoDiscover to determine the correct EWS endpoints to use for your on-premises infrastructure during the initial organisation relationship creation. Additionally external AutoDiscover aware clients will need an on-premises AutoDiscover service to query during Hybrid coexistence, even if their mailbox is running in Office 365 (The on-premises AutoDiscover service will either service the request locally or redirect the request to Office 365 if the mailbox is not hosted locally). If you are using clients that support AutoDiscover it is highly recommended that you plan for a certificate to publish AutoDiscover namespace externally.

Outlook Anywhere

If you have Outlook Anywhere (OA) clients configured already then you will have already planned for and deployed a certificate for this service. There is no need to change this name during Hybrid Coexistence, however if you are planning to request a new certificate you should ensure that you include your OA namespace on the certificate to ensure that the service continues to function.

Transport

One area that often gets missed during certificate planning is the certificate required to establish secure SMTP transport between on-premises and FOPE for your Office 365 tenant and vice-versa. It is beyond the intended scope of this post to discuss secure transport; however you should plan for it if you intend to run in prolonged hybrid coexistence. I have included a link below to a TechNet section to help with this planning.

Note: For further information see the following links…

OK, so now I know what my Office 365 Hybrid certificate requirements are… where should I install it/them?

This is where things get more interesting. In my lab environment things are really easy… I have a single TMG server that I use to publish my Exchange Services and an ADFS 2.0 Proxy server that I use to publish my ADFS services. So, I requested a single UCC certificate with the following four names…

sts.groovycloud.co.uk
mail.groovycloud.co.uk
legacy.groovycloud.co.uk
autodiscover.groovycloud.co.uk

I then installed the certificate onto my TMG and ADFS Proxy + ADFS 2.0 servers. To make this work I also had to configure an internal Windows Certificate Authority and deploy certificates on my internal servers and ensure that my TMG server trusted the internal Certificate Authority by importing the trusted root certificate from my CA. This deployment obviously requires two public fixed IP Addresses to publish both TMG and ADFS.

Note: It is possible to do this just with TMG, however you will need to disable pre-authentication and HTTPS protocol checking on the publishing rule for ADFS which essentially means that TMG is just passing the TCP request straight through to your internal ADFS 2.0 server. This is potentially acceptable in a PoC Lab but extremely unwise for production.

This is actually how many of my customers have also deployed their certificates. Where things become more complex is if there is no internal CA…

Using the same public certificate for Office 365 Hybrid internally and externally…

OK, so you don’t have an internal PKI or Windows CA to provide you with internal certificates. This means that you are going to need to use the same public certificate on all of the servers… this also means that you need to use the same URL’s for your Exchange services internally and externally so that the requests match the names on the certificates…

If your environment is very simple (like my lab for example) and you have split brain DNS then you could get away with just installing the public certificate onto the internal servers as well. Make sure that if you do this that you change your Exchange Server 2010 Virtual Directory Internal URL’s to match the names on your certificate and create the appropriate DNS entries to point to your Exchange Server 2010 coexistence server, otherwise your clients will get certificate warning errors if they attempt to connect to the internal AutoDiscover service for example… (Not nice!).

If your internal environment is more complex and/or you do not have split brain DNS (this means you cannot use the same URL for your services internally and externally) then you will need to use multiple certificates. If you are in this circumstance I recommend that you plan for your internal certificate requirements first and then add on your Office 365 Hybrid requirements. Once you have a combined list of names it is much easier to plan your certificate locations and generate the requests accordingly.

The most important thing is to determine your requirements and conduct an appropriate planning exercise – a large number of support cases are caused due to inadequate certificate and namespace planning for Exchange and Office 365 Hybrid.

A word of warning about certificates for Office 365 in Hybrid Mode…

I was recently working with a customer who had deployed their user pilot for Office 365 in Hybrid Mode in a very similar way to the configuration that I use in my lab; the one exception was that they had used an internal certificate on their ADFS 2.0 server. This solution had been working for several weeks quite nicely. One Monday morning they called me up and said that nobody could logon to Office 365 via their federated identities. We did some troubleshooting and their ADFS 2.0 server was getting the requests for authentication but not sending back the necessary SAML token. Further analysis showed that their internal certificate authority certificate had expired!

They have since taken steps to monitor this more closely, however it does highlight one extremely important point… if you are using ADFS for federated identities the ADFS service must be available at all times, any interruption of the ADFS server will result in Office 365 service downtime for your end users. In this case the customer had a well drilled high availability solution deployed for ADFS to avoid this situation and yet a simple certificate error still caused them several hours of downtime…

from http://blogs.technet.com/b/msukucc/archive/2011/08/25/office-365-hybrid-configuration-certificate-planning-adfs-exchange-web-services-owa-oa.aspx