Recently we had a client approach us advising they were no longer able to sign into their Skype Room System v2 devices. After a bit of investigation, it appeared the issue first started occurring after a Cumulative Update (Dec 2017) was applied to their Skype for Business on-premises environment. Testing sign in from an SRS unit of our own to their Skype for Business on-premises environment yielded the same result.
When signing into the SRS unit, you’ll find yourself presented with an error message, advising sign-in has failed. Note that “No meeting scheduled” is presented on the screen when attempting to sign in, which means signin to Exchange via EWS was successful, ruling out a use username/password issue.
A close up of the offending error:
Various blog posts around the internet have pointed out this issue relates to a SHA1 Root Certificate Authority, which has since been deprecated.
Let’s check the certificate on the Front End Server and see:
This would seem to be the cause then. But, I’m never a fan of a How without the Why. Sure, we can brute-force the solution – but it would be more satisfying to actually get a solid answer that yes, SHA1 is the reason.
So, where do we start to try and figure out why SRS devices won’t sign in, yet standard desktop clients do? As my mentor drilled into me on day 1, when in doubt – Trace Trace Trace!
Jumping onto the Front End server, We’ll first run a CLS trace to grab the authentication logs.
There are many ways to achieve this, however I find the easiest is to use the very handy GUI created by James Cussen found here: http://www.myskypelab.com/2013/04/lync-2013-centralised-logging-tool.html
I selected Authentication as the scenario, and started the trace. Then tried another login attempt. Grab these now exported logs and throw them into snooper. With a bit of searching you should be able to isolate the point where a 401 unauthorized is generated with a clear text reason:
Now, given the calendaring works, we know it is isn’t a user/password issue. So with that in mind, we then check the SCHANNEL system logs on the Front End server, which tracks amongst other things, certificate errors. At the time of this 401 unauthorized error we find a matching error:
So, it does appear to be corroborating the theory that SHA1 is the root (pun intended) cause here. Let’s deep dive a little bit further. On the same Front End server, In Event Viewer, Go to Microsoft > Windows > CAPI2 and Enable Operation Logging:
Let’s force another login attempt and get the verbose logs. In this instance, it’s easier to Select All the entries and Find the sip URI to get what you’re after.
You should get something similar to this:
Yet another strike against the current SHA1 certificate.
To finalize our investigation, we’ll check the certificate provisioning service with Chrome installed, which has more stringent security warnings
This is the warning produced when checking the certificate associated with the Frontend server:
The client in question stated that the SRS v2 was previously able to sign into their environment Given this issue first appeared after a Skype for Business Server CU update cycle, it’s likely either the May or Dec 2017 CU has added additional dependencies to the SRS v2 API that only allow SHA256 certificates to be authenticated against.
To test this theory, I found another client with a SHA1 Root CA, but with a Skype for Business Server Cumulative Update prior to May 2017. In this configuration I was able to successfully sign into the Skype Room System device.