Signing into Lync 2013 client presents the warning message: “Lync cannot verify that the server is trusted for your sign-in address. Connect anyway?”

I’ve been meaning to blog about an issue I noticed in environments with disparate namespaces (internal domain name is different than external) where no matter how I configured the DNS for the internal or public forward lookup zones, I could not get around the following warning message presented to users signing into Lync 2013 clients:

The connection to the server is encrypted.

View Certificates

Lync cannot verify that the server is trusted for your sign-in address. Connect anyway?

As noted in Jeff Schertz’s post:

http://blog.schertz.name/2012/12/lync-2013-client-autodiscover/

… the new Lync 2013 client now attempts to lookup the 2 new Lync Discover records introduced in Lync Server cumulative update 4 for supporting mobility clients:

• lyncdiscoverinternal.domain.com
• lyncdiscover.domain.com
• _sipinternaltls._tcp.domain.com
• _sip._tls.domain.com
• sipinternal.domain.com
• sip.domain.com
• sipexternal.domain.com

Prior to the introduction of the 2 new records when the first record that the Lync 2010 looks up was _sipinternaltls._tcp.domain.com, I was able to get around the mismatch between the sign-in address which uses the public domain that does not match the FQDN of the internal Lync front end server as described in my previous post:

Quick note about Lync Server 2010 automatic sign-in for environments with different external and internal domain names
https://blog.terenceluk.com/2011/04/quick-note-about-lync-server-2010.html

However, making the same change to the lyncdiscoverinternal CNAME record:

… so that it points to an A record that uses the public domain name:

… did not work.  So just as Jeff demonstrated on his blog, I went on to try doing traces with Wireshark as well.

Confirming Ordering of Lookup Records

First, I tested signing in with my Lync 2010 client and as expected, the order DNS records are as follows:

• _sipinternaltls._tcp.domain.com
• _sip._tls.domain.com
• sipinternal.domain.com
• sip.domain.com
• sipexternal.domain.com

Signing with the Lync 2013 client confirmed the 2 new records that are now ahead of the old ones:

• lyncdiscoverinternal.domain.com
• lyncdiscover.domain.com
• _sipinternaltls._tcp.domain.com
• _sip._tls.domain.com
• sipinternal.domain.com
• sip.domain.com
• sipexternal.domain.com

Testing in Production Environment

With the ordering of the records confirmed, I went ahead and tried signing into the Lync 2013 client and review the Wireshark packet captures which appeared to do the following:

The client queries the record lyncdiscoverinternal.domain.com:

Although I have a lyncdiscoverinternal CNAME set up the in public domain forward lookup zone, it looks like the Lync 2013 client still continues to query for the next lyncdiscover.domain.com record regardless of whether it receives a reply or not:

Another entry for the lyncdiscoverinternal query is shown in the packet capture:

Then as expected, the DNS server replies with a CNAME record for the initial query (0xeeb3) of lyncdiscoverinternal and as shown in the response, the CNAME record that the DNS responds with is the internal Lync server name with the public domain FQDN mapped to the internal IP address of the Lync front end server address:

Notice that the next entry is the DNS server responding with No such name for the lyncdiscover record query (0x3c75) which is expected because that record does not exist in the DNS server:

The next entry continues the DNS server to the Lync 2013 client response for the lyncdiscoverinternal query which continues to list the internal Lync server name with the public domain FQDN mapped to the internal IP address of the Lync front end server:

The next entry is what confuses me because the previous entries appear to suggest that the Lync 2013 client queries for lyncdiscoverinternal.domain.com, receives the CNAME record <name of Lync front end server>.publicDomain.com with the A record address pointing to the internal IP address but rather than attempting to sign into the server with the returned IP address, it continues to query the DNS server for the Lync server internal FQDN record:

<name of Lync front end server>.internalDomain.internal

I originally thought the Lync 2013 client was performing a reverse lookup of the previous CNAME record <name of Lync front end server>.publicDomain.com but the next entry shows that the client is clearly performing a query (0x5f56) for the internal FQDN of the Lync server:

From here, the client proceeds to sign into the IP address of the Lync server’s internal FQDN which brings us to the warning message shown at the beginning of this post.

Unfortunately, I’ve tried modifying the DNS records in different ways (i.e. using A records instead of CNAME records for lyncdiscoverinternal) but would continue to run into the same issue.  The only 2 ways I could think of was either to completely remove the lyncdiscoverinternal record so that the Lync client falls back to the _sipinternaltls._tcp.domain.com record but that means breaking the mobility clients that sign in while on the internal network.  The only option available that I could think of was to use the TrustModelData registry key to explicitly force the client to trust public domain.  More information about this registry key can be found in one of my previous posts here:

Location of the “TrustModelData: registry key for the Lync 2013 Client
https://blog.terenceluk.com/2013/02/location-of-trustmodeldata-registry-key.html

Note that I did all the tracing shown above probably more than 2 months ago so I may have forgotten a few items I noticed while writing this post now so please excuse any mistakes I may have made during the analysis.