locked
CX3000 PIN Authentication RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hello,

    We have a strange issue with pin authentication not working after a phone is unplugged or rebooted. When the phone tries to auto-sign in, it mentions that it "Cannot contact certificate web service". After we get that error, if we enter the Extension and PIN manually, it signs right in. I see the 404 mentioned below but i'm not sure where to look.

    When I run Test-CsPhoneBootstrap -PhoneOrExt "3333" -PIN 111111, i get the following:

    Connecting to web service : http://lyncfe.domain.com/CertProv/CertProvisioningService.svc
            Using anonymous authentication
            Successfully created connection proxy and website bindings
            Attempting to download certificate root chain
            request created
            ERROR communicating with GetRootCertChains() service
    System.ServiceModel.EndpointNotFoundException: There was no endpoint listening at http://lyncfe.domain.com/CertProv/CertProvisioningService.svc/anon that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details. ---> System.Net.WebExcep
    tion: The remote server returned an error: (404) Not Found.
       at System.Net.HttpWebRequest.GetResponse()
       at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpCha
    nnelRequest.WaitForReply(TimeSpan timeout)   --- End of inner exception stack trace ---

    Thanks, PK

    Thursday, November 1, 2012 9:51 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    Just to update this,

    Like Jeff mentioned above, the error message above has nothing to do with the auto-login failing after a reboot. We think this might be because the customer is not using LLDP and using the manual VLAN configuration. The switch ports are configured in trunk mode which is causing the phones to wait a while before getting an IP address. When the switch ports are configured in access mode, the phones get an IP quickly and are able to sign right in.

    For an unknown reason, LLDP refuses to work in this environment. From our packet traces, the switch is sending the right information but the phones seem to be ignoring it. We've got a case open with Polycom and are currently waiting for feedback from them.

    I will update this again when we have resolution.

    Thanks,

    Prashanth

    • Proposed as answer by Lisa.zheng Wednesday, November 7, 2012 7:08 AM
    • Marked as answer by Lisa.zheng Tuesday, November 27, 2012 2:42 AM
    Friday, November 2, 2012 10:39 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    The web service URL is not correct. The right form of the Lync Server pool certificate provisioning service URL is https://lyncsvrWebPoolFQDN:443/CertProv/CertProvisioningService.svc

    Please check you configured DHCP correctly by the following link.

    http://technet.microsoft.com/en-us/library/gg412988.aspx

    Friday, November 2, 2012 8:47 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I doubt that is the issue as a malformed CerProv URL would prevent PIN Authentication from ever working at all. The URL is listed is what is provided in the error log during the initial HTTP connection from the phone were it attempts to download the root certificate. 

    If the process is intermittent then the first question I have is what firmware version is installed on the CX3000?

    Jeff Schertz | Microsoft Solutions Architect - Polycom | Lync MVP

    Friday, November 2, 2012 10:50 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Thanks for the responses.

    Lisa,

    Correct me if I'm wrong but i believe the URL you are describing is what the phone will connect to after downloading the Root CA certificate.

    Jeff,

    The CX3000 is running 4.0.7577.4100, CU6 I think? The process is intermittent in that if I unplug the phone and plug it back in, it will not sign back in. However, when we enter the phone extension and pin, it will sign in every time. I'm going to try and see if this is an issue on the CX600s as well. From what I can remember this was not an issue when we were running 4.0.7577.4047

    Thanks again,

    Prashanth

    Friday, November 2, 2012 1:15 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I tested this on a CX600 and it appears to be behaving in the same manner. I also went ahead and factory reset the device to go back to 4.0.07577.4047 and it did the same thing. I don't think this is an issue on the phone's side as I've got hundreds of these phones deployed at other customers and i have not run into this at those sites. Is it possible to look at the logs from the phone side? Or is wireshark a better option?

    Thanks,

    Prashanth

    Friday, November 2, 2012 2:16 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Just to update this,

    Like Jeff mentioned above, the error message above has nothing to do with the auto-login failing after a reboot. We think this might be because the customer is not using LLDP and using the manual VLAN configuration. The switch ports are configured in trunk mode which is causing the phones to wait a while before getting an IP address. When the switch ports are configured in access mode, the phones get an IP quickly and are able to sign right in.

    For an unknown reason, LLDP refuses to work in this environment. From our packet traces, the switch is sending the right information but the phones seem to be ignoring it. We've got a case open with Polycom and are currently waiting for feedback from them.

    I will update this again when we have resolution.

    Thanks,

    Prashanth

    • Proposed as answer by Lisa.zheng Wednesday, November 7, 2012 7:08 AM
    • Marked as answer by Lisa.zheng Tuesday, November 27, 2012 2:42 AM
    Friday, November 2, 2012 10:39 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Any update?

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Wednesday, November 7, 2012 7:09 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    All,

    This appears to be a bug in the Cisco IOS code base running on the switches. We are working with the network team to get the IOS updated and hopefully it will resolve our issues.

    Thanks,

    Prashanth

    Friday, November 16, 2012 9:26 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I have a customer that is experiencing exactly the same issue.  PIN Auth works great but if you unplug the phone it boots up and you get the web certificate error.  Do Pin Auth again and phone signs on with no issues.  What specifically was the bug on the Cisco side? 

    Thanks,

    Dino

    Dino Caputo, BA | MCSE | MCTS:OCS/Lync http://www.ucguys.com http://www.enableUC.com

    Tuesday, December 4, 2012 8:24 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Dino,

    The code base our customer was running had an issue with advertising TLVs. The code base they were running on the supervisor is 12.2(33)SXI3. They are working toward upgrading to 12.2(33)SXJ1. Cisco has mentioned that it's been fixed in the following versions:

    15.1(3)S
    15.2(1)S
    15.0(1)SY
    12.2(32.8.11)SX467
    15.1(2.16)S0.2
    15.2(0.1)S
    15.0(0)XJR111.134
    12.2(33)SXJ1

     Here are the bug details:

    6500 LLDP Enabled Capabilities not reporting Bridge capabilities

    Symptom:

    A 6500 switch configured for LLDP may not correctly report its enabled capabilities
    as a bridge. This may cause issues with certain advertised TLV's to be ignored.

    Conditions:

    6500 running LLDP with third-party device.

    Workaround:

    none

    Further Problem Description:
    System capabilities are correctly being sent, but the enabled capabilities are
    not being advertised.

    switch>sh lldp entry *

    Capability codes:
    (R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
    (W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other

    < output snipped>

    System Capabilities: B,R
    Enabled Capabilities:

    This may cause problems with 3rd party phones that rely on this LLDP TLV to
    identify the switch.
    Tuesday, December 4, 2012 9:28 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Thanks.  In our case the customer has Dell managed PoE switches.  The switches were not enabled for LLDP.  Customer enabled LLDP and retested.  Same issue. 

    Customer then enabled PortFast Option and retested and this time success!  Spanning Tree was enabled but not the portfast option on the ports designated for workstation, server and phone ports.  This would account for why we would initially see the phones saying they could not connect to the Lync Server before getting the Web Certificate error.

    Regards,

    Dino

    Dino Caputo, BA | MCSE | MCTS:OCS/Lync http://www.ucguys.com http://www.enableUC.com

    • Proposed as answer by Dino CaputoMVP Wednesday, December 5, 2012 3:52 PM
    Wednesday, December 5, 2012 3:51 PM