通过

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

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

  • Anonymous
    January 01, 2003
    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.

  • Anonymous
    June 09, 2011
    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.

  • Anonymous
    September 14, 2011
    What is the list of trusted Domains? Jens>In the post it refers to the trusted domains known by Lync.

  • Anonymous
    September 19, 2011
    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.

  • Anonymous
    December 27, 2011
    Thanks for this clear article.

  • Anonymous
    February 21, 2012
    The comment has been removed

  • Anonymous
    April 20, 2012
    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.

  • Anonymous
    May 22, 2012
    The comment has been removed

  • Anonymous
    May 24, 2012
    The comment has been removed

  • Anonymous
    July 26, 2012
    The comment has been removed

  • Anonymous
    August 10, 2012
    The comment has been removed

  • Anonymous
    September 27, 2013
    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.

  • Anonymous
    May 21, 2014
    Pingback from Deploying Lync Standard Edition in a failed Pilot environment | Joe Hatton

  • Last updated on