locked
Unable to login to SFB On-Prem after reboot of Win 10 workstations RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    Long time viewer, seldom poster here.


    We have an on premises SFB 2015 deployment (running latest CU) with on Prem Exchange 2010 as well as on Prem AD. From time to time when a client reboots their workstation, they receive an error message: Can't sign in to Skype for Business - There was a problem verifying the certificate from the server. When this error occurs, no Skype user can sign in using the current windows profile. If I sign on with another windows profile the same error will occur. for all Skype users. To resolve the issue I simply reboot the PC having the issue, sometimes a 2nd reboot is needed. My workstation experiences the issue as well, as of now I am in the broken state. I have not had patches installed on my laptop in over a week. OS is windows 10 pro. Our FE Skype server uses certificates issued from our internal root CA server, the intermediate and root CA is installed on all workstations including my own.

    Here are some of the errors in the UccApi log on my workstation:

    02/26/2018|14:55:44.618 1E10:2468 ERROR :: 
    SECURE_SOCKET: negotiation failed: 80090325, principal name: [sip.xxx.xx.ca]

    02/26/2018|14:55:44.618 1E10:1F74 ERROR :: 
    CSIPTransportLayerSecurity::OnTlsNegotiationComplete (1293DA70) failed with 0x80ee00ca. Raising OnConnect with the same error

    02/26/2018|14:55:44.618 1E10:1F74 ERROR :: 
    CSIPClientConnection::OnConnect (80ee00ca) this: 12D29B38

    02/26/2018|14:55:44.618 1E10:1F74 ERROR :: 
    CSIPClientConnection::AttachLyntrix no instance of CLyntrixClient

    02/26/2018|14:55:44.618 1E10:1F74 ERROR :: 
    CSIPClientConnection::Initialize AttachLyntrix failed hr=80004005

    02/26/2018|14:55:44.620 1E10:1F74 ERROR :: 
    CSIPAsyncSocket::Connect: HRESULT API failed: 80072733 = hr


    02/26/2018|14:55:44.627 1E10:2468 ERROR :: SECURE_SOCKET: negotiation failed: 80090325, principal name: [sip.xxx.xx.ca]

    02/26/2018|14:55:44.627 1E10:1F74 ERROR :: 
    CSIPTransportLayerSecurity::OnTlsNegotiationComplete (1293D9D0) failed with 0x80ee00ca. Raising OnConnect with the same error

    02/26/2018|14:55:44.627 1E10:1F74 ERROR :: 
    Releasing connection and notifying transactions

    02/26/2018|14:55:44.627 1E10:1F74 ERROR :: 
    SIP_MSG_PROCESSOR::NotifyRequestConnectionConnectComplete - Error: 80ee00ca

    02/26/2018|14:55:44.628 1E10:1F74 ERROR :: 
    OUTGOING_TRANSACTION::OnRequestConnectionConnectComplete - connection failed error 80ee00ca

    02/26/2018|14:55:44.628 1E10:1F74 ERROR :: 
    HRESULT API failed: 80ee0061 = hr. DisableServManager


    I am hoping that someone has come across this issue before. I thought for awhile that it was related to desktop patching, but I am able to reproduce this issue from time to time by simply restarting my workstation without installing any patches.

    Thanks in advance to anyone who wishes to help.



    • Edited by stoyles13 Monday, February 26, 2018 10:42 PM
    Monday, February 26, 2018 6:48 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote
    Through a case that was opened with MS, the issue was found to be with the way we had our internal root CA certificate assigned to all workstations via GPO. We assigned the cert differently using Group Policy to resolve the issue.

    Andy Stoyles

    • Proposed as answer by mercenarygod Thursday, March 28, 2019 8:24 PM
    • Marked as answer by stoyles13 Tuesday, August 20, 2019 2:29 PM
    Thursday, November 1, 2018 3:32 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi stoyles13,

    For this issue, have you sign in successfully before?
    Did all users had the issue or specific user had the issue?
    Is that appear on the specific PC, the PC client is domain joined or non-domain joined?

    For this issue, please double check if the Root CA where you have request the certificate for the SFB server is also a trusted root CA on your client.

    It looks like the client didn't trust the certificate from the SFB server.

    If all users can’t sign in SFB, please try to renew the certificate for SFB server, the following document is for your reference
    https://blogs.technet.microsoft.com/uclobby/2013/09/16/renewing-lync-server-20102013-certificates/

    Also check if there are any event IDs in the server side.

    Hope the information is helpful to you.

    Best Regards,
    Alice Wang

    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.


    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Tuesday, February 27, 2018 1:56 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    Thanks for your reply. Sign-in did work before. Sometimes when users are on the corp network they cannot sign-in. If their workstation is rebooted once, sometimes twice they can sign-on again. All PC's are domain joined. Multiple users have the issue, but not all users. New piece of info: when I put my laptop on an internet only connection, I am able to sign-on from the Edge. If I connect to corp network again, I get the same error the certificate couldn't be verified. There are no corresponding application server error logs. The Root CA and intermediate CA certs of the issuing certificate server is installed on both Skype Server and client.

    Andy Stoyles

    Tuesday, February 27, 2018 4:55 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi stoyles,

    Thanks for your response.

    For this issue, it looks like caused by the certificate.

    Please try to renew the certificate of your SFB server.

    Best Regards,
    Alice Wang

    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.


    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    • Proposed as answer by Alice-Wang Monday, March 5, 2018 9:28 AM
    Thursday, March 1, 2018 2:16 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi, the majority of SFB users do not receive the error - a reboot of the workstation fixes the issue temporarily. For this reason I believe it is not the Server certificate causing the issue. It seems the error is on the workstation, in system event log each time the Skype login fails I get Event 36882: The certificate received from the remote server was issued by an untrusted certificate authority. Because of this, none of the data contained in the certificate can be validated. The TLS connection request has failed. The attached data contains the server certificate.

    I have confirmed that the Trusted root CA is in the proper location and the issuing intermediate cert also.

    Andy Stoyles

    Monday, March 5, 2018 11:43 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    We have some user reported the same issue, and moved user to other SFB pool resolve the login issue. Please note this user has logged on to SFB successfully before on the same workstation.

    I also asked the user log on from other workstation and the user can log in to skype. All these workstations are on corporate network.

    Any idea why this happened? Our SFB use a hardware load balancer (F5) and the autodiscover use the virtual IP in this F5 hardware load balancer.

    Tuesday, October 30, 2018 5:41 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Through a case that was opened with MS, the issue was found to be with the way we had our internal root CA certificate assigned to all workstations via GPO. We assigned the cert differently using Group Policy to resolve the issue.

    Andy Stoyles

    • Proposed as answer by mercenarygod Thursday, March 28, 2019 8:24 PM
    • Marked as answer by stoyles13 Tuesday, August 20, 2019 2:29 PM
    Thursday, November 1, 2018 3:32 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Andy, could you elaborate on what you did differently with group policy? I'm currently facing the same issue. Thank you,
    Thursday, March 28, 2019 8:24 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    I have the same issue. Andy, is it possible to tell what you did diffenrently with gpo?
    Wednesday, July 31, 2019 6:41 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi, I can't recall exactly how our cert admin assigned the Root CA that was causing the grief. Whichever way it was done, all workstations could not read it properly from time to time. Instead of removing the old Root CA, he deployed the same Root CA cert to all workstations using a GPO. This resulted in a duplication of Root CA certs on workstations located under the "Trusted Root Certification Authorities", but there was no harm done in doing this as directed by the MS representative assigned to our case.

    I hope this helps

    Andy Stoyles

    Tuesday, August 20, 2019 2:35 PM