There can be several reasons why a Lync 2013 client would continuously prompt for credentials. This article covers one that is pretty rare and will eventually fade away as 3rd party certificates are renewed.
This issue did not appear on Windows 7 with Lync 2010 or Lync 2013 nor does it appear with Windows 8 using Lync 2010. A few moments after logging into the Lync 2013 client on Windows 8 a prompt appears saying Credentials are required to retrieve the calendar data from Outlook.
This prompt will continue until it is canceled; and once it is canceled will not allow for several of the Exchange Web Services features to work. Some of these include saving conversation history to Exchange, pulling meeting information from Exchange and may show that it has an issue connecting to Exchange on the Lync 2013 client.
In the Windows 8 Event Log there should be an SChannel error in the System Logs with the Event ID 36888. You will notice it fails 3 automatically and then there is an error each time you manually tried to enter the Username and Password. The error states TLS protocol defined fatal error code is 43. The Windows SChannel error state is 252.
These errors are a bit cryptic and can be hard to figure out what they mean exactly. Below is a table of all the TLS error codes, however I was not able to locate all of the state codes.
Error Code 0 – Close Notify
Error Code 10 – Unexpected Message
Error Code 20 – Bad Record Mac
Error Code 21 – Decryption Failed
Error Code 22 – Record Overflow
Error Code 30 – Decompression Fail
Error Code 40 – Handshake Failure
Error Code 42 – Bad Certificate
Error Code 43 – Unsupported Cert
Error Code 44 – Certificate Revoked
Error Code 45 – Certificate Expired
Error Code 46 – Certificate Unknown
Error Code 47 – Illegal Parameter
Error Code 48 – Unknown CA
Error Code 49 – Access Denied
Error Code 50 – Decode Error
Error Code 51 – Decrypt Error
Error Code 60 – Export Restriction
Error Code 70 – Protocol Version
Error Code 71 – Insufficient Security
Error Code 80 – Internal Error
Error Code 90 – User Canceled
Error Code 100 – No Renegotiation
Error Code 110 – Unsupported Ext
If you do not see the exact error code of 43 and state of 252, you most likely have a different issue.
After determining that the Exchange certificate was the issue, I then proceeded to look at the Certificate that was being provided by Exchange.
Qualys SSL Labs, https://www.ssllabs.com/ provides a very helpful tool, called SSL Server Test, to check a website and it’s certificate. This test is very thorough and can show all the Root CA Certification Paths, server supported Cyphers in order of preference, and if it is vulnerable to attacks such as the BEAST attack. Using this tool I noticed that although the certificate only showed me 1 Root CA Certification path, there were actually 3 paths being provided by the server.
Seeing that there was an MD2withRSA cert I suspected this was the portion of the “unsupported cert” message that TLS had issues with. The first path is the one I saw when looking at the properties of the certificate, either via a web browser or Certificates MMC on the server. To see if this was being sent by the server I deleted the Trusted Root CA from my computer and sure enough after logging into Lync 2013 the Certificate was repopulated into the Certificate Store.
Note: The SHA1 number shown on the SSL test matches the Thumbprint field on the Certificates properties, not the Serial number.
In an article from January 15th, 2009. Microsoft states they would be phasing out support for MD2, MD4 and MD5 hash certificates, Microsoft Root Certificate Program.
It appears that Lync 2013 on Windows 8 has now dropped support for all MD# certificates; this includes Root CA self signed certificates from Trusted 3rd party vendors.
This may be a Windows issue as I stated earlier in the article, Windows 7 using Lync 2013 does not have this issue, as the error does not appear in the System logs. There is no workaround to stop this behavior without an update to Windows 8 or the Lync 2013 client. To resolve this, on the Exchange server simply renew this certificate or an easier approach is to have the 3rd party CA regenerate the certificate and ensure that it does not include any of the MD# hashes in the Certificate path. Typically they will do this at no charge. Changing the certificate will require a small outage, as you will need to assign the new certificate on Exchange services and restart IIS.
As stated this issue will eventually disappear as no Root CA I know of will issue certificates with MD# hashes.