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

  • Article

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.