Solved

AD, DNS & Exchange 2010

Posted on 2013-01-07
8
907 Views
Last Modified: 2013-01-07
I'm trying to understand better the effects of the new SSL restrictions where internal, and .local are no longer allowed in an SSL certificate. I have a couple of clients who are currently using SSL for outlook anywhere and owa access. The current certificates use:

autodiscover.mydomain.com
mail.mydomain.com
internalmailservername.mydomain.local

Everything works great for internal and external access to exchange services via outlook and mobile devices, iPhones, etc.

I have one of the clients who had to renew their SSL certificate and since we can no longer get the internal server name on the certificate outlook internally generates a certificate error every time they try to open something in outlook. (almost every time) with the internal name of the server saying it does not match the certificate.

I did a little research and digicert is saying that from now one the internal dns structure has to match the external dns naming conventions. So my AD domain needs to be a .com or .net. To accomplish this the AD domain name would need to be changed, which does not sound thrilling to me.

Does anyone have a solution or effective work around for this issue?

Thanks,
Scott
0
Comment
Question by:87scully
8 Comments
 
LVL 41

Expert Comment

by:Amit
Comment Utility
Did your client purchased the same cert with same old domain names or anything changed?
Did you enabled the new Cert? for IIS,SMTP,POP,IMAP etc. If not enable it for these services.
0
 
LVL 17

Expert Comment

by:Spartan_1337
Comment Utility
0
 
LVL 58

Accepted Solution

by:
tigermatt earned 250 total points
Comment Utility
>> digicert is saying that from now one the internal dns structure has to match the external dns naming conventions

Yes, that would certainly work, but the advice is really masking what is happening behind the scenes.

Exchange publishes a number of HTTP services for Outlook and other client devices to connect to. Most of these URLs are configured at the server and can be modified. One example is the setting known as the Autodiscover Service Connection Point (SCP), which Outlook clients joined to the domain on the internal network will use to communicate with Autodiscover.

By default, Exchange will set the value in the SCP to:

https://MailServer.MyInternalADDomain/Autodiscover/Autodiscover.xml

If your internal Active Directory domain is company.com, then the FQDN in the above URL becomes MailServer.company.com. Assuming you own the company.com namespace, you can now obtain a certificate which lists MailServer.company.com and prove ownership of the domain.

With a .local or some other non-public TLD, the FQDN part of the above URL is set - by default - to MailServer.company.local, again, where company.local is the internal Active Directory domain.

Much online advice stated that an SSL certificate must include the MailServer.company.local name for Exchange to work properly. This advice is not inaccurate; it would work, but on the basis that the default configuration for the various URLs is the internal name of the server, so listing it on the certificate gives everyone an easy life without additional DNS and Exchange changes required.

Now that .local names are not permitted on SSL certificates beyond 2015/16, this will no longer work. You certainly don't need to go through an AD namespace upheaval to fix this though. Just change the default URLs in Exchange and list the public names on the certificate.

As public names are going to be used internally, you will need to ensure they can be resolved and routed correctly. This will depend on your network architecture. In a typical network, the Exchange environment is on the same LAN behind the same firewall as the internal clients. In addition, when mail.company.com is resolved, it will (by default) return the public IP. Most firewalls won't allow access to a public IP from the private LAN. Some can be configured to do so, but it is better to maintain two DNS namespaces and resolve the appropriate company.com names internally to the internal Exchange IPs, a configuration known as split DNS.

You will need to create a company.com forward lookup zone on your internal DNS infrastructure (probably on the DCs, but not necessarily). Add to this the ability for mail.company.com and autodiscover.company.com to resolve to the internal Exchange IP. A CNAME record is normally appropriate here, aliasing the names to MailServer.company.local. The benefit of this configuration vs relying on the public DNS & firewall change is continuity of service in the event of an Internet connection failure. If you were to rely on the public DNS, that is most likely hosted by a third-party on all but the largest of enterprise networks. If you lose Internet, you take a full or partial service hit to email, even internally.

When split DNS is properly configured, update the various URLs in Exchange:

Get-ClientAccessServer | Set-ClientAccessServer -AutodiscoverServiceInternalUri https://autodiscover.company.com/Autodiscover/Autodiscover.xml
Set-OWAVirtualDirectory -Identity "OWA (Default Web Site)" -InternalUrl https://mail.company.com/owa -ExternalUrl https://mail.company.com/owa
Set-ECPVirtualDirectory -Identity "ECP (Default Web Site)" -InternalUrl https://mail.company.com/ecp -ExternalUrl https://mail.company.com/ecp
Set-WebServicesVirtualDirectory -Identity "EWS (Default Web Site)" -InternalUrl https://mail.company.com/EWS/Exchange.asmx -ExternalUrl https://mail.company.com/EWS/Exchange.asmx
Set-ActiveSyncVirtualDirectory -Identity "Microsoft-Server-ActiveSync (Default Web Site)" -InternalUrl https://mail.company.com/Microsoft-Server-ActiveSync -ExternalUrl https://mail.company.com/Microsoft-Server-ActiveSync

Open in new window


You are now in a position to eliminate the use of .local names on your public SSL certificate, as Exchange will use public company.com names for all accesses regardless of location of the Outlook client.

-Matt
0
 
LVL 25

Expert Comment

by:DrDave242
Comment Utility
Check the links at the bottom of the Digicert page that describes the new cert requirements.  They've made a tool available to reconfiguring Exchange servers and have also provided the manual process in case you'd rather not use the tool.  Be sure to read the prerequisites if you choose to run the tool.
0
Why do Marketing keep bothering you?

Is your marketing department constantly asking for new email signature updates? Are they requesting a different design for every department? Do they need yet another banner added? Don’t let it get you down! There is an easy way to manage all of these requests...

 

Author Comment

by:87scully
Comment Utility
Matt,
I was thinking this was the case I just did not have the Exchange url pieces. That makes total sense. Going to give it a shot and thank you very much for your help!
0
 

Author Comment

by:87scully
Comment Utility
I'll check that out as well Dave. It looks like Matt listed the manual process of doing the same thing listed on the digicert page?

Thanks guys!
0
 
LVL 58

Expert Comment

by:tigermatt
Comment Utility
I wasn't aware of the tool Dave has posted on the Digicert page. I certainly wouldn't recommend using that on anything more than the simplest of Exchange environments, but then, my instructions don't really cater for those environments either.  It would require more understanding of the specifics of the set up to give the proper advice as to the URLs to specify where and the underlying DNS changes to make to ensure uninterrupted service in all but the simplest of environments.

Still, the good news is there are ways around this, and you aren't required to do a complete AD domain rename or overhaul in the process!

-Matt
0
 

Author Comment

by:87scully
Comment Utility
Matt,
 I could not get the first exchange command to work:

Get-ClientAccessServer | Set-ClientAccessServer -AutodiscoverServiceInternalUri https://autodiscover.company.com/Autodiscover/Autodiscover.xml

I did the split DNS and I ran the remaining exchange commands however and it seems to have resolved the problem.

Thanks for your help!

Regards,
Scott
0

Featured Post

PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

Join & Write a Comment

Easy CSR creation in Exchange 2007,2010 and 2013
Find out how to use Active Directory data for email signature management in Microsoft Exchange and Office 365.
The video tutorial explains the basics of the Exchange server Database Availability groups. The components of this video include: 1. Automatic Failover 2. Failover Clustering 3. Active Manager
To add imagery to an HTML email signature, you have two options available to you. You can either add a logo/image by embedding it directly into the signature or hosting it externally and linking to it. The vast majority of email clients display l…

744 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

Need Help in Real-Time?

Connect with top rated Experts

16 Experts available now in Live!

Get 1:1 Help Now