I’ve recently been asked by an ex-colleague about configuring automatic sign-in for Active Directory environments that have different domain names for their internal network (Active Directory) and public network (public presence). As the wording can get confusing, I think it’s best to provide the following example environment:
Active Directory domain: contoso.local
Public presence domain: contoso.com
What my ex-colleague experienced was that after setting up the certificates, DNS and SRV records, he would constantly get prompted with the following message when signing into his Lync Client:
Since I know there was an excellent blog post written by Jens Trier Rasmussen which can be found here: http://blogs.technet.com/b/jenstr/archive/2011/02/10/lync-cannot-verify-that-the-server-is-trusted-for-your-sign-in-address.aspx, I simply pointed him to the post telling him he can find the answer there. What ended up happening was he came back to me and told me that DNS wasn’t one of his strengths and simply wanted to know what he was supposed to do so I went ahead and sent him the following:
- Create the following SRV record in the public domain zone: _sipinternal @ port 5060 pointing to lyncpool01.publicDomain.com
- Create the following SRV record in the public domain zone: _sipinternaltls @ port 5061 pointing to lyncpool01.publicDomain.com
- Create the following A record in the public domain zone: lyncpool01.publicDomain.com pointing to the internal IP address of your pool
- Make sure the internal certificate has an entry for lyncpool01.publicDomain.com
Once you’ve configured automatic sign-in to pass the Lync client’s login request from an A & SRV record with a domain that matches the sign-in address, the error will go away.
For a more detailed explanation of why, see the blog post I included above. Hope this helps.