14

SBS 2008 running Exchange 2007 and IIS6.0

CompanyA has two other companies that operate under the same roof. To accommodate email, we have 3 Exchange accounts per user to manage this. All users use their CompanyA account to log into the domain.

  • CORP\user user@companyA.com
  • CORP\user-companyb user@companyB.com <-- only used for email
  • CORP\user-companyc user@companyC.com <-- only used for email

Email works fine internally and via OWA. The problem exist when setting up Outlook for remote users who need access to companyB and companyC emails, Outlook pops up the certificate error.

The SSL cert SAN has the following DNS names:

  • webmail.companyA.com
  • www.webmail.companyA.com
  • CORP-SBS
  • CORP-SBS.local
  • autdiscover.companyA.com

I was told by the users who access companyC email address remotely that this never used to happen before. This started with the CEO changed DNS providers on his own and in the process the original DNS settings were lost. He mentioned something about an SRV record being created which corrected this issue but that's about it.

Looking for guidance on how to properly address this.

HopelessN00b
  • 53,385
  • 32
  • 133
  • 208
Mike66350216
  • 277
  • 1
  • 5
  • 12

2 Answers2

26

This issue is most likely caused by Outlook's Autodiscover service, part of the Outlook Anywhere functionality. Autodiscover provides various information to the end-user's Outlook client on the various services offered by Exchange and where these can be located; this is used for a variety of purposes:

  • Autoconfiguration of Outlook profiles on first-run of Outlook, which can configure an Exchange account using only the user's email address and password, since the other information is automatically located and retrieved.

  • Dynamic location of web-based services accessed by the Outlook client, including the out-of-office assistant, Unified Messaging functionality, location of the Exchange Control Panel (ECP) and so forth.

This is Microsoft's proprietary implementation of RFC 6186. Unfortunately, they didn't really follow the recommendations of that RFC in Outlook Anywhere's design, but that is perhaps to be expected since Exchange and RPC over HTTPS functionality is not a traditional IMAP/SMTP server.


How does Autodiscover work (for external* users)?

Autodiscover communicates with a web service on a Client Access Server (in this case, all roles are on the SBS server) at the path /Autodiscover/Autodiscover.xml, rooted off its default web site. To locate the FQDN of the server to communicate with, it removes the user portion of the email address, leaving the domain (i.e. @companyB.com). It attempts to communicate with Autodiscover using each of the following URLs, in turn:

  • https://companyB.com/Autodiscover/Autodiscover.xml
  • https://autodiscover.companyB.com/Autodiscover/Autodiscover.xml

If these fail, it will attempt a non-secure connection by disabling SSL and attempting to communicate on port 80 (HTTP), typically after prompting the user to confirm this is an acceptable action (a flawed option in my opinion, since clueless users will typically approve this and risk sending credentials over plain text -- and clueless sysadmins who don't require secured communication of credentials and business-sensitive data are a risk to business continuity).

Finally, a follow-on check is made using a service record (SRV) in the DNS, which exists at a well-known location off the companyB.com namespace and can redirect Outlook to the proper URL where the server is listening.


What can go wrong?

One of several issues can arise in this process:

No DNS entries

Typically, the root of the domain (companyB.com) might not resolve to a host record in the DNS. Improper DNS configuration (or a conscious decision not to expose the Outlook Anywhere service) might mean the autodiscover.companyB.com record does not exist either.

In these cases, there is no major issue; Outlook simply continues to communicate with Exchange using the last known configuration, and may be degraded with respect to certain web-based functions for which it needs to retrieve URLs via Autodiscover (such as the out-of-office assistant). A workaround is to use Outlook Web Access to access such functions.

Automatic configuration of Exchange accounts in new Outlook profiles is also not automated, and requires manual configuration of the RPC over HTTPS settings. However, this will not cause the issue you describe.

Faulty SSL certificates

It is entirely possible that the URL Outlook uses to attempt to contact the Exchange Server resolves to a host, which may or may not be a Client Access Server. If Outlook can communicate with that server on port 443, certificates will of course be exchanged to set up a secure channel between Outlook and the remote server. If the URL Outlook believes it is talking to is not listed on that certificate -- be it as the common name or a subject alternative name (SAN) -- this will elicit Outlook to present the dialog you describe in your initial post.

This can happen for several reasons, all down to how DNS is configured and how the URLs I described above are checked by Outlook:

  • If the https://companyB.com/... URL resolves to a host record, and the web server at that address listens on port 443, and it has an SSL certificate which does not list companyB.com in the common name or Subject Alternative Name, then the issue will occur. It matters not whether the host is an Exchange Server or not; it might be a web server hosting a company website which is not properly configured. Corrige either:

    • Disable the host record at the root of the companyB.com zone (requiring visitors to the website or other service to enter www.companyB.com, or equivalent; or
    • Disable access to the machine at companyB.com on port 443, causing Outlook to reject the companyB.com URL before certificates are exchanged and move on; or
    • Fix the certificate at companyB.com to ensure companyB.com is listed on that certificate, and that attempts to visit https://companyB.com in a standard browser do not fail.

The above applies regardless of whether companyB.com resolves to the Exchange Server; if Outlook can communicate with it, it will later discover that the /Autodiscover/Autodiscover.xml path yields an HTTP 404 error (does not exist) and move on.

  • If the https://autodiscover.companyB.com/... URL resolves to the Exchange Server (or any other server) but, again, autodiscover.companyB.com is not listed as the common name or a subject alternative name, you will observe this behaviour. It can be fixed as above by fixing the certificate, or as you rightly indicate, you can use a SRV record to redirect Outlook to a URL which is listed on the certificate and which Outlook can communicate with.

Your probable fix to this issue

In this case, the typical fix is to do the latter; create SRV records in the new DNS provider to ensure Outlook is redirected to autodiscover.companyA.com, which (any other issues aside) will work successfully since it is listed on the certificate as a SAN. For this to work, you need to:

  • Configure an _autodiscover._tcp.companyB.com SRV record in accordance with the documentation.
  • Delete the autodiscover.companyB.com host record, if it exists, to prevent Outlook resolving this and attempting to reach Autodiscover in that way.
  • Also resolve any issues with HTTPS access to https://companyB.com as above, since Outlook will enumerate the URLs derived from the user's email address before falling over to the SRV record approach.

*How does Autodiscover work (for internal, domain-joined clients)?

I add this merely for completeness, as it is another common reason for these certificate prompts to occur.

On a domain-joined client, when it is local to the Exchange environment (i.e. on the internal LAN), the above techniques are not used. Instead, Outlook communicates directly with a Service Connection Point in Active Directory (listed in Exchange Client Access settings), which lists the URL where Outlook can locate the Autodiscover service.

It is common for certificate warnings to occur in these circumstances, because:

  • The default URL configured for this purpose refers to the internal URL of Exchange, which is often dissimilar from the public URL.
  • SSL certificates may not list the internal URL on them. At present, yours does, but this may become an issue in the future for Active Directory domains which use .local and similar non-global gTLD domain name suffixes, since a decision by ICANN prohibits SSL certificates for such domains being issued post-2016.
  • The internal address might not resolve to the proper server.

In this case, the matter is resolved by correcting the recorded URL to refer to the proper, external address (listed in the certificate), by running the Set-ClientAccessServer cmdlet with the -AutodiscoverServiceInternalUri switch. Parties doing this typically also configure split-horizon DNS, either because they are required to do so by their network configuration and/or for continuity of resolution in the event of an upstream resolver/connection outage.

Cosmic Ossifrage
  • 1,610
  • 14
  • 23
  • 2
    Excellent write-up! Although I believe that in the last section it should be Service Connection Point (SCP) rather than Service Locator Point (SLP). – BlueCompute Sep 11 '14 at 16:27
  • @BlueCompute indeed, you're right, I've had my head in System Center land for too long recently! (SLPs used to exist in SCCM 2007 and served a remotely-related purpose to the SCP). Fixed in the above – Cosmic Ossifrage Sep 11 '14 at 16:28
  • Thanks for the thorough write up! I did just notice that autodiscover.companyA.com is an A record and not a CNAME record. Will this have any impact on the SRV record working properly for companyB.com? – Mike66350216 Sep 11 '14 at 17:43
  • No, that's fine. In fact, it *should* be a host (A/AAAA) record, rather than an alias (CNAME) record, as CNAMEs as targets of SRV records are expressly forbidden in [RFC 2782](https://tools.ietf.org/html/rfc2782): *"Target: The domain name of the target host. There MUST be one or more address records for this name, the name MUST NOT be an alias..."* – Cosmic Ossifrage Sep 11 '14 at 20:56
  • Worked like a champ - thank you so much! One thing to note though. When using MXToolbox to view the SRV record for domain companyB, it returns nothing. I contacted the DNS provider who said the proper way to view if the record existed (since I knew the name) was to: nslookup, set type=all, _autodiscover._tcp.companyB.com to view and ensure it pointed to autodiscover.companyA.com – Mike66350216 Sep 12 '14 at 04:13
  • 1
    Public support for SRV records is still somewhat lacking, even among DNS providers. Sounds like you got it sorted out though! – Cosmic Ossifrage Sep 12 '14 at 14:28
  • 3
    I just want to point out that your wonderful write up + the following link solved my problem. http://superuser.com/questions/770308/outlook-shows-certificate-security-warning-in-local-lan-although-certificate-is. Just wanted to leave this note here for anyone who was in the same boat as me. – James Watt Mar 26 '15 at 14:46
3

You need to create an SRV record in domains B and C that matches one of the names in the cert (autodiscover.companyA.com). This tells Outlook that that name handles autodiscover for Domains B and C.

Have a read here of the SRV records in DNS section:

https://jaapwesselius.com/2011/08/28/autodiscover-redirect-srv-record/

joeqwerty
  • 108,377
  • 6
  • 80
  • 171