Jens Trier Rasmussen

The odd bit of information about Lync Server 2013, Lync 2010, Exchange 2013, SharePoint Server 2013, Exchange 2010 SP1, OCS 2007 R2, Exchange 2010 and OC 2007 R2

Lync cannot verify that the server is trusted for your sign-in address

Lync cannot verify that the server is trusted for your sign-in address

  • Comments 12
  • Likes

In most environments you won’t see this, but depending on your infrastructure you might get a prompt when signing in to Lync similar to the one in the picture below. You might be asking yourself why do I get this prompt?

TrustPrompt

Background

Microsoft Lync 2010 adds enhanced trust checking when connecting to automatically discovered servers Lync servers or Exchange servers. The additional trust checking has been implemented to enhance the protection against DNS spoofing attacks. Automatically discovered servers are servers found by looking up SRV or A records in DNS based on the SIP URI or primary SMTP address domains as well as DHCP Option 120. Servers specified manually in the Lync client are assumed trusted by the fact that you manually specified them. The same is true for any servers Lync is re-directed to by trusted servers in another domain.

Checking trust

When Lync has discovered a server in DNS it checks it against the list of trusted domains. If the check is successful the server is trusted and the connection is established. If the check is not successful, the above trust prompt is shown, and the user gets the ability to see the certificate being presented by the server and decide if he/she should trust the server. The user can chose to trust the server and connect to it, always trust the server or try to connect to another server. Always trusting a server adds the domain of the server to the list of trusted domains.

The list of trusted domains are compiled using the follow rules:

  • Any trusted domains (created by always trusting a server)
  • The users SIP URI domain (via AD, the usual sign-in page or manually configured)
  • The domain of the Lync server, which  Lync successfully connected to last

When Lync checks a server against the list of trusted domains it loops through the saved domains and test if the server is a member of the domain, either directly or as sub-domains. For example say the list of trusted domains contains d.e and h.i.j. A check for server s1.b.c.d.e will be successful, because b.c.d.e is a sub-domain of d.e. A check for server s2.i.j will not be successful, since i.j is not equal to or a sub-domain of either d.e or h.i.j.

Trust and Certificates

The check of trust is not directly connected to certificates and their subjects or subject alternate name (SAN) entries. It is a pure test against the list of trusted domains. However it is clear that the FQDN of any server Lync connects to needs to be presented in that servers certificate subject and/or SAN. Otherwise the TLS connection can’t be made.

Examples

It might be easier to understand this by way of a couple of examples. Let’s assume the following environment:

  • The SIP URI of the user is jeff@fabrikam.com
  • server.contoso.com is a Lync SE server in the environment
  • There is a DNS A record for server.contoso.com with the IP address 192.168.101.20
  • There is a DNS SRV record _sipinternaltls._tcp.fabrikam.com with target server.contoso.com on port 5061
  • The user has never before connect to Lync server on this PC
  • Automatic configuration is selected in Lync

In the above environment the list of trusted domains will contain fabrikam.com. When Jeff signs in Lync will find the DNS SRV record _sipinternaltls._tcp.fabrikam.com and it will attempt to connect to server.contoso.com on port 5061. However before it does that it will check if the server is trusted against the list of trusted domains. In this case the check fails and a trust prompt will be shown for server.contoso.com

Let’s now assume that the environment is changed to the following:

  • The SIP URI of the user is jeff@fabrikam.com
  • server.contoso.com is the Lync director in the environment
  • There is a DNS A record for server.contoso.com with the IP address 192.168.101.20
  • There is a DNS SRV record _sipinternaltls._tcp.fabrikam.com with target sip.fabrikam.com on port 5061
  • There is a DNS A record for sip.fabrikam.com with the IP address 192.168.101.20
  • The user has never before connect to Lync server on this PC
  • Automatic configuration is selected in Lync

The list of trusted domains is still fabrikam.com. When Jeff signs in Lync will find the DNS SRV record _sipinternaltls._tcp.fabrikam.com and it will attempt to connect to sip.fabrikam.com on port 5061. First Lync checks it against the list of trusted domains. The test is successful and the trust prompt is NOT shown. The certificate of the Lync director server.contoso.com is checked to verify that it covers sip.fabrikam.com.

Let’s add automatic discovery for Exchange servers to the mix and assume that the environment is changed to the following:

  • The SIP URI of the user is jeff@fabrikam.com
  • Jeff has an Exchange 2010 mailbox and the primary SMTP address jeff@contoso.com
  • There is a DNS A record for autodiscover.contoso.com with IP address 192.168.101.30
  • There is a DNS A record for cas.contoso.com with IP address 192.168.101.30
  • The Exchange 2010 Client Access Server is running on cas.contoso.com
  • server.contoso.com is the Lync director in the environment
  • There is a DNS A record for server.contoso.com with the IP address 192.168.101.20
  • There is a DNS SRV record _sipinternaltls._tcp.fabrikam.com with target sip.fabrikam.com on port 5061
  • There is a DNS A record for sip.fabrikam.com with the IP address 192.168.101.20
  • The user has never before connect to Lync server on this PC
  • Automatic configuration is selected in Lync

The list of trusted domains is still fabrikam.com. When Jeff signs in Lync connect as before. However Lync will also try to access Exchange Autodiscover service to get information about how and where it can access Jeff’s mailbox. Lync will use the primary SMTP address domain and try to access the autodiscover service by using the URL’s https://contoso.com/autodiscover/autodiscover.xml and https://autodiscover.contoso.com/autodiscover/autodiscover.xml. In our case it will find the DNS A record for autodiscover.contoso.com and Lync checks it against the list of trusted domains. The check fails and a trust prompt will be shown for autodiscover.contoso.com.

Let’s now assume that the environment is changed to the following:

  • The SIP URI of the user is jeff@fabrikam.com
  • Jeff has an Exchange 2010 mailbox and the primary SMTP address jeff@contoso.com
  • There is a DNS SRV record for _autodiscover._tcp.contoso.com with target autodiscover.fabrikam.com on port 443
  • There is a DNS A record for autodiscover.fabrikam.com with IP address 192.168.101.30
  • There is a DNS A record for cas.contoso.com with IP address 192.168.101.30
  • The Exchange 2010 Client Access Server is running on cas.contoso.com
  • server.contoso.com is the Lync director in the environment
  • There is a DNS A record for server.contoso.com with the IP address 192.168.101.20
  • There is a DNS SRV record _sipinternaltls._tcp.fabrikam.com with target sip.fabrikam.com on port 5061
  • There is a DNS A record for sip.fabrikam.com with the IP address 192.168.101.20
  • The user has never before connect to Lync server on this PC
  • Automatic configuration is selected in Lync

The list of trusted domains is still fabrikam.com. When Jeff signs in Lync connect as before. Lync will try to access Exchange Autodiscover service as above, but will fail since there is no A record for autodiscover.contoso.com. Lync will then try to find a SRV record for _autodiscover._tcp.contoso.com and it will get the target autodiscover.fabrikam.com returned. Lync will check autodiscover.fabrikam.com against the list of trusted domains and it will find a match. This means the server is trusted and the prompt above is NOT shown.

Best practices

When configuring DNS to support automatic discovery of Lync and Exchange servers for Lync please follow these best practices:

  • Make sure that the target of any SRV record is in a domain, which will be automatically trusted by Lync per the rules above
  • Make sure that the target of any SRV record is an A record. Using CNAME records as targets is not supported by Lync and is not allowed per RFC2782 – A DNS RR for specifying the location of services (DNS SRV)
  • Make sure certificates used on Lync and Exchange servers includes all the FQDN’s used as targets for the SRV records. Otherwise Lync won’t be able to setup a TLS connection to the server

Thanks to Brian for background information and review.

Comments
  • You're missing a key piece in the examples.  An environment that has multiple SIP Domains and therefore multiple autodiscover.domain.com but the Exchange environment can't also have a dedicated InternalURL/ExternalURL for EWS for each domain.

    Jens>I'm not sure I fully understand your comment. The autodiscover FQDN is constructed by appending the primary SMTP domain of the user, not the SIP domains. The examples were also not meant to be a complete list of possible variations.

  • What is the list of trusted Domains?

    Jens>In the post it refers to the trusted domains known by Lync.

  • Do you know how can I clear the checkbox "Always trust this server..." once I pressed and don't appears anymore?

    Jens>Unfortenately there is no way to do this from the UI.

  • Thanks for this clear article.

  • Hi Jens. I am currently troubleshooting one of these problems with 4.0.7577.4061 (empty registry, flushed DNS cache). When reviewing the DNS-queries at logon, I can firstly only see a query for the zone itself, then for the A-record autodiscover.default-smtp.domain. But no query for the SRV-record and therefore the prompt appears.

    Am I missing something?

    Jens>It seems strange that it won't ask for the SRV record. I just tried it in my lab with the same build and it does ask for SRV record when it can't find the A record for autodiscover.default-smtp.domain.

  • Hey Jens, thanks for the article. I have a question. I have two Front End Servers in the child domain a.domain.com (pool.a.domain.com) and clients in the domain a.domain.com can sign in automatically with the according SRV record. But users in the child domain b.domain.com get the 'Lync cannot verify that the server...' message when they try to connect to the Front End servers pool.a.domain.com. Which is right according to your article. The SRV record for those user is: _sipinternaltls._tcp.b.domain.com with target pool.a.domain.com on port 5061 in the b.domain.com zone. What is the best way to solve this issue? Thanks!

    Jens>I believe your scenario is the same as the first example in the post, i.e. your b.domain.com is the same as my fabrikam.com, so the same solution should work for you.

  • Nice article. Im just confused. You say that it is not related to certificates but rather a direct issue with the Trusted Domain list.

    But in your Best Practices, I don't understand about that regarding certificates. Can you give a sample scenario? I did in mine, and I did not change anything in certificates (did not add CAS FQDN to Lync cert or even autodiscover.mail.com to Lync cert) but it still works (no Trust error and successful connection with Lync / Exchange).

    Can you help clarify? Thank you!

    Jens>You don't need to add Exchange related FQDN's (such as CAS or autodiscover) to the Lync certificates. They need to be on the Exchange certificate. What I'm saying is that every FQDN Lync connects to needs to present the FQDN in the certificate sent back to Lync client.

  • How do I add trusted domains into Lync from the server side? I see I can do it by regkey on the client but I would prefer a global setting on the server. Pushing out a regkey to 15k desktops seems like a hack:)

    support.microsoft.com/.../2531068

    Thanks,

    Pete

    Jens>It is not possible to do it from server side, other than configuring the environment such that the prompts are not coming (if that is possible).

  • I'm having exactly the same issue as Pete.  I think the question he is asking is HOW do you configure the environment such that the prompts are not coming.  Let's say your sip domain is im.contoso.com...NOT just contoso.com, and your Exchange mailboxes are all contoso.com.  Autodiscover is autodiscover.contoso.com.  How do you configure the environment so that contoso.com is a trusted domain?  It keeps prompting because the SIP domain is im.contoso.com.

    Jens>I believe your scenario is basical the same as in my example. You need to have a DNS SRV record for _autodiscover._tcp.contoso.com with target autodiscover.im.contoso.com on port 443 and then a A record for autodiscover.im.contoso.com.

  • One question, how does is come that in Office 365 you can signin with your own domainname without this domain listed in de SAN on the Microsoft certificates that are on these directors?

    Jens>Your own domain name does not need to be on the certificate, only the target used for the DNS SRV records.

  • The Lync 2010 Multi-tenant deployment guide says: The FQDNs listed in the tenant-specific DNS Records table must be added as subject alternative names to the certificates used by those servers because the certificates used within the Lync Server infrastructure must match those used in the request.

    Without domains listed in the certificate, sign-in will still work but federation will NOT because of these requirements..

  • Does this issue occur with OCS 2007 R2 clients connecting to Lync 2013?

    Jens>No, I believe this is only for Lync 2010 client and beyond.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment