[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
?
Solved

Exchange 2010, Autodiscover, CName record, Name Mismatch issue

Posted on 2013-11-05
7
Medium Priority
?
3,113 Views
Last Modified: 2013-11-15
So I searched for a while and can't seem to find an answer that applies to me through here or even with my best google-fu.

My issue is as follows:

I have an Exchange 2010 server that hosts a few dozen completetly different domains. At one point I used to add those domains to a UCC cert. I would add autodiscover.domain.com to the certificate plus the DNS record for autodiscover.domain.com to point at my CAS server. Everything worked great.

One day I found that Office 365 was using a simple CName record to redirect autodiscover.domain.com to autodiscover.outlook.com. For those Office 365 hosted exchange users, they worked great. I have never seen a certificate name mismatch prompt on their side.

Here is where I am at now:
I have setup the same CName record of autodiscover.domain.com and pointed it at my Exchange 2010 CAS server. The cname entry for autodiscover.domain.com is to my external, let's call it, autodiscover.hosted.com. That autodiscover.hosted.com name is on my SSL certificate. Autodiscover tests from testexchangeconnectivity.com fail due to certificate name mismatch. My Outlook users get a popup regarding the same, certificate name mismatch issue. I have verified all CAS based web directories internal and external for OAB, Autodiscover, ECP, EWS, etc point to my external DNS name that is on my SSL certificate.

HOWEVER, I continue to get a prompt about a name mistmatch. Running the autodiscover test from Outlook returns all expected values. There isn't an internal (.local) URL entry there.

I suppose finally, my question is how to resolve this. I have found 3 or 4 references here that were of no help. Adding them to the UCC defeats the purpose as the ease of usage is missing when I had new domains, which I do frequently.
0
Comment
Question by:LSeven
  • 3
  • 2
  • 2
7 Comments
 
LVL 60

Expert Comment

by:Cliff Galiher
ID: 39625478
There is no way around it. The certificate name must match the domain name that Outlook uses. CNAME records *do NOT* redirect. They provide an alternate name, but if you use that alternate name then the certificate must still contain that alternate name.
0
 
LVL 63

Assisted Solution

by:Simon Butler (Sembee)
Simon Butler (Sembee) earned 1332 total points
ID: 39626999
What Office365 is doing is a HTTP redirect, not a HTTPS redirect.
The HTTP host name redirects to the actual source of the Autodiscover information. You can do similar with SRV records.

If you want to do a HTTP redirect you need to have a unique IP address, which has no HTTPS services bound to it.

This article on the Exchange WIKI at Microsoft explains how to set it up:
https://social.technet.microsoft.com/wiki/contents/articles/5787.exchange-2010-multi-tenant-autodiscover-and-dns-configuration.aspx

Simon.
0
 

Author Comment

by:LSeven
ID: 39638679
Sembee2, thanks for the response. I will try this out and see how I fair.
0
Free learning courses: Active Directory Deep Dive

Get a firm grasp on your IT environment when you learn Active Directory best practices with Veeam! Watch all, or choose any amount, of this three-part webinar series to improve your skills. From the basics to virtualization and backup, we got you covered.

 

Author Comment

by:LSeven
ID: 39639563
Sembee2, are you saying for every O365 Hosted Exchange solution they offer, MSFT uses a completely unused (HTTP/HTTPS) IP address?!
0
 
LVL 60

Accepted Solution

by:
Cliff Galiher earned 668 total points
ID: 39639615
O365 does not allocate a unique IP address per host, no. But they don't JUST use CNAME records either. Being hosted in Azure, they can leverage the entire virtual network that azure offers, and they use a bit of reverse proxy magic to make sire initial https autodiscover requests fail, so clients fall back to HTTP. Then the http autodiscover request issues an HTTP redirect (not a cname, not DNS), and the subsequent request is done via https and proxies to a service with a certificate that matches.

A third party hosted could replicate this behavior, but it'd take an intelligent reverse proxy setup, and ideally separate dedicated IIS machines for the HTTP redirect. Provisioning new clients would also not be trivial, and some custom automation would likely be desired to avoid easy mistakes.
0
 
LVL 63

Assisted Solution

by:Simon Butler (Sembee)
Simon Butler (Sembee) earned 1332 total points
ID: 39641702
"Sembee2, are you saying for every O365 Hosted Exchange solution they offer, MSFT uses a completely unused (HTTP/HTTPS) IP address?! "

No, that is not what I am saying.

You need two IP addresses - one for HTTP and one for HTTPS.
They point everything for Autodiscover using the CNAME and HTTP redirection method at the HTTP IP address.

The key point being that HTTP address doesn't listen to HTTPS as well.

Simon.
0
 

Author Comment

by:LSeven
ID: 39652029
It seems a srv record works as expected. Add in a note to tell them to uncheck the pop up box is, while not the cleanest, probably the easiest solution.
0

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

As much as Microsoft wants to kill off PST file support, just as they tried to do with public folders, there are still times when it is useful or downright necessary to export Exchange mailboxes to PST files. Thankfully, it is still possible to e…
Mailbox Corruption is a nightmare every Exchange DBA wishes he never has. Recovering from it can be super-hectic if not entirely futile. And though techniques like the New-MailboxRepairRequest cmdlet have been designed to help with fixing minor corr…
This tutorial will walk an individual through setting the global and backup job media overwrite and protection periods in Backup Exec 2012. Log onto the Backup Exec Central Administration Server. Examine the services. If all or most of them are stop…
This Micro Tutorial hows how you can integrate  Mac OSX to a Windows Active Directory Domain. Apple has made it easy to allow users to bind their macs to a windows domain with relative ease. The following video show how to bind OSX Mavericks to …
Suggested Courses

834 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question