If you have deployed on your organization a firewall/proxy with Deep Packet Inspection (DPI), some of your Lync (SfB) users might have questioned you about a certificate popup similar to picture on the right. By now they probably are not having it anymore.
You will also get much more similar popup if you like to control/restrict the desktop trusted certificates on your environment (check the last paragraph on the blog)
Here’s the ‘deconstruction’:
If you were an earlier adapter of the KB3114351 – security update for Lync 2013 (Skype for Business): December 8, 2015 (this also applies to security update for Skype for Business 2016: KB3114372), you didn’t find by that time on one ‘functionality’ that was introduced.
KB3114351 was later updated on 23 Dec 2015 – “This security update contains the following improvements: •Adds Cloud-based Discovery •Uses SSO to autodetect SIP address and start sign in” – But no more details.
On the 12 of January, KB3114687 was published:
“”The address type is not valid” error when you sign in to Lync 2013 (Skype for Business) by using domain\username format”.
“This issue occurs because if Lync 2013 (Skype for Business) client fails to detect lyncdiscover and lyncdiscoverinternal services. In this case, the new DNS-less discovery (also known as Cloud-based discovery) redirects you to the Microsoft Lync Online Discovery services in Office 365″
The KB points two other two KB (also initially released on the same date):
- The issue is fixed by January 12, 2016, update for Lync 2013 (Skype for Business).
- Cloud Based Discovery, UPN Enforcement for OrgID, and SIP Autodetection from Azure for Skype for Business Client.
What impact does it had to your Lync on-premises environment?
The December 8, 2015 security update added a new ‘fallback/DNS-less autodiscover’. If your client doesn’t resolve any of the lyncdiscover* DNS addresses it will then query odc.officeapps.live.com and only after an answer (or failure to connect) it will continue the other SRV/DNS fallback discovery.
Besides the issue KB3114687 issue, if your clients don’t receive the lyncdiscover* records (either because you don’t use it or there was some issue connecting to the DNS, they are going to the internet and there’s where the users get warning picture from at the top of the post.
If you don’t get (or the user press the ‘connect’) you might get your user trying to authenticate and query Office365 Cloud. It will fail, and then continue throw the SRV autodiscover and login back to the on-premises Lync.
The January 12, 2016, update for Lync 2013 (Skype for Business) changed (fixed) the previous autodiscovery priority (1)lyncdiscover* (2)SRV records (3)sip* (4) DNS-less odc.officeapps.live.com
The probability for a on-premise user to ‘fallback’ to the cloud is now very little. But in any case, if you have a on-premise-only deployment of Lync, my advice is to disable Cloud based discovery on your clients either by a GPO (if it exists) or setting the following registry key:
reg add HKLM\Software\Policies\Microsoft\Office\15.0\Lync /v DisableCloudBasedDiscovery /t REG_DWORD /d 1 /f
After setting this key, the Lync (Skype for Business) client will no longer query (and connect to) the odc.officeapps.live.com.
You will still catch some Lync network traffic going to MS servers, but that’s another story 🙂
The other ‘Cloud based functionalities also are causing other issue refered on my previous post “Users are being asked for credentials after applying KB3114351 or KB3114502”
____________________________________
Extra info:
If you still have the only the December 8, 2015 security update installed, here’s a ‘quick trick’ to get the certificate popups on your desktop client:
(1) delete the trusted CA installed by Lync client in both user and local machine (might need to restart your PC)
(it seems that Lync will install the certificate when you start it)
(2) point your lyncdiscover* records to a dummy IP. ex: create on the hosts file something like: 127.0.0.1 lyncdiscoverinternal.<yoursipdomain> lyncdiscover.<yoursipdomain>
(3) delete the EndpointConfiguration.cache file from %localappdata%\Microsoft\Office\15.0\Lync\sip<yoursipuseraccount> alternatively you can just press the ‘delete my sign-in info on the main Lync login screen’
When you login with your user again you should be prompt for a ‘certificate trust issue’
IT based Communications 