Go Premium for a chance to win a PS4. Enter to Win

x
?
Solved

AD, DNS & Exchange 2010

Posted on 2013-01-07
8
Medium Priority
?
957 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 44

Expert Comment

by:Amit
ID: 38751558
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:James H
ID: 38751588
0
 
LVL 58

Accepted Solution

by:
tigermatt earned 1000 total points
ID: 38751710
>> 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
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

 
LVL 27

Expert Comment

by:DrDave242
ID: 38751729
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
 

Author Comment

by:87scully
ID: 38751748
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
ID: 38751757
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
ID: 38752052
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
ID: 38753345
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

Windows Server 2016: All you need to know

Learn about Hyper-V features that increase functionality and usability of Microsoft Windows Server 2016. Also, throughout this eBook, you’ll find some basic PowerShell examples that will help you leverage the scripts in your environments!

Question has a verified solution.

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

It’s time for spooky stories and consuming way too much sugar, including the many treats we’ve whipped for you in the world of tech. Check it out!
Eseutil Hard Recovery is part of exchange tool and ensures Exchange mailbox data recovery when mailbox gets corrupt due to some problem on Exchange server.
Are you ready to implement Active Directory best practices without reading 300+ pages? You're in luck. In this webinar hosted by Skyport Systems, you gain insight into Microsoft's latest comprehensive guide, with tips on the best and easiest way…
This video shows how to use Hyena, from SystemTools Software, to update 100 user accounts from an external text file. View in 1080p for best video quality.
Suggested Courses

926 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