none
Client Connector for WSE fails: "General: Failed to open Networking\ClientDns registry key" RRS feed

  • Question

  • Been trying to setup a PC in a Domain with the Client Connector (as we would like the PC to be RDP-connectable via the WSE website). Install fails, local log file calls: 

    [9732] 190615.132402.6253: ClientSetup: Running Task with Id=ClientDeploy.ValidateUser
    [9732] 190615.132402.6273: ClientSetup: Entering ValidateUserTask.Run
    [9732] 190615.132402.6273: ClientSetup: Validating User
    [9732] 190615.132402.6283: ClientSetup: Call MachineIdentityManager.GetMachineStatus
    [9732] 190615.132402.6373: General: Failed to open IDENTITY registry key.
    [9732] 190615.132402.6373: General: Failed to open IDENTITY registry key.
    [9732] 190615.132402.6373: General: Failed to open IDENTITY registry key.
    [9732] 190615.132402.6373: General: Failed to open IDENTITY registry key.
    [9732] 190615.132402.6383: General: Failed to open IDENTITY registry key.
    [9732] 190615.132402.6403: General: Failed to open IDENTITY registry key.
    [9732] 190615.132402.6922: ClientSetup: MachineIdentityManager.GetMachineStatus had errors: ErrorCatalog:NetworkError ErrorCode:-1
    BaseException: Microsoft.WindowsServerSolutions.Devices.Identity.MachineIdentityException: MachineIdentityManager.GetMachineStatus ---> System.ServiceModel.Security.SecurityNegotiationException: Kan geen vertrouwde relatie met het veilige SSL/TLS-kanaal maken met autoriteit server:65500. ---> System.Net.WebException: De onderliggende verbinding is gesloten: Kan geen vertrouwde relatie met het beveiligde SSL/TLS-kanaal maken. ---> System.Security.Authentication.AuthenticationException: Het externe certificaat is ongeldig volgens de validatieprocedure.
       bij System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception exception)

    But that seems not to be the real issue. In the Serverlog (ConnectWebsite.log) we find:

    [30092] 190615.132326.1883: ClientSetup: Key: Throttle_IPv6,  Hit number: 1

    [30092] 190615.132326.1894: ClientSetup: Key: Total_Request_for_Connect_Website,  Hit number: 2

    [30092] 190615.132326.1894: ClientSetup: Servicing Get Request: /connect/default.aspx?Get=Setup.cab&LanguageId=1043&64bit=1

    [30092] 190615.132326.1904: ClientSetup: Getting setup cab

    [30092] 190615.132326.1904: ClientSetup: Native Resource not present for Culture Name = nl-NL

    [30092] 190615.132326.1914: ClientSetup: Setup files will be in default Culture: en-US

    [30092] 190615.132326.2563: DomainManagerObjectModel: DomainSignupManager ctor called. InstanceID=51354130

    [30092] 190615.132326.2583: ClientSetup: DomainDnsName Domain, DomainNetBiosName Domain ServerFQDN OutsideWebDomain

    [30092] 190615.132326.2773: General: Failed to open Networking\ClientDns registry key.

    [30092] 190615.132326.2773: DomainManagerObjectModel: DomainSignupManager ctor called. InstanceID=34074445

    [30092] 190615.132326.2783: ClientSetup: IsRoamingClient() - url request host: HostNamel

    [30092] 190615.132326.2783: General: Failed to open ClientDeployment\Internal registry key.

    [30092] 190615.132326.3714: ClientSetup: Transmit file from C:\Windows\TEMP\egtf4cyq.w4p\Setup.cab

    Two lines of interest:

    "General: Failed to open Networking\ClientDns registry key"
    "General: Failed to open ClientDeployment\Internal registry key"

    What is it trying to do, and what is failing here?

    If this is not the issue, it may be an issue of internal server name (server.domain.local) and external website domain name (remote.domainname.com)? But running the connector with either name, results in the same logs..

    Been looking into this already some time, DNS checked, naming checked, connectivity checked... Any clues appreciated.

    Rgds, Huibert.

    Saturday, June 15, 2019 11:55 AM

All replies

  • Hello Huibert,

    Without any specific knowledge of these components and just using my general intuition, I would not ignore the SecurityNegotiationException as just a probable by-product of an earlier problem on the server. I would want to at least know what was wrong with the server certificate. How deeply did you investigate that aspect of the problem?

    You could just save a copy of the server certificate in a .cer file, copy that to the client and open it there and verify that certmgr regards it as OK.

    Gary

    Saturday, June 15, 2019 12:35 PM
  • The cert can be investigated when it is extracted from the ConnectComputer download.  The certificate is the one for server.domain.local and is okay for this PC as the PC is already connected to the same domain. With starting the connector software by hand you can command it even to use that computer name (server.domain.local) explicitly and you will see it (apparently!) verifying the username/password.

    I am aware of the two paths to the server, via remote internet www.webdomain.com and internally via server.domain.local.  And also i see in the xml (Filename ServerInfo, also available after extraction of the ConnectComputer download the software is aware of the two routes, alas it appears to understand it.

    With the two names the corresponding routes are okay both for IPv4 and IPv6. For IPv4, internally direct via subnet and externally via public IP numbers and NAT port forwarding. IPv6, same numers obviously.

    -Huibert.


    -Technet-Huibert.

    Sunday, June 16, 2019 11:28 AM
  • Hello Huibert,

    It is my impression that the software expects the call to "MachineIdentityManager.GetMachineStatus" to succeed but it is failing due to a problem with validating the certificate.

    One certificate validation step that often causes problems is validating certificate revocation. This is a validation step that can (and often is) disabled, but if it is enabled and the path to the CRL is not reachable (perhaps because it is an LDAP path to an internal directory service) then things won't work. Have you checked things like that?

    Gary

    Sunday, June 16, 2019 3:31 PM
  • Seen/read this one:

    https://social.msdn.microsoft.com/Forums/expression/en-US/ac20990a-e4f5-412a-ac3b-da3c874a804c/the-remote-certificate-is-invalid-according-to-the-validation-procedure?forum=csharpgeneral

    The local cert should be pretty okay, the PC is connected successfully to the servers' domain before, but I better recheck again the certificate stores for both the local machine and the admin user. Will do and report.


    -Technet-Huibert.

    Sunday, June 16, 2019 6:37 PM
  • Checked local machine certificate store and 'current user' (aka Administrator) cert store. Both have the CA from the server in the trusted root cert list. So, I will agree the message identifies a cert-not-good, but I see it is set properly and available. And btw, reading the logging, actually the software will insert the CA in the stores if it is missing.

    -Technet-Huibert.

    Sunday, June 16, 2019 7:06 PM
  • Hello Huibert,

    As I mentioned, my guess would be that revocation checking is the cause of the validation failure. If this problem was affecting me, I would invest my efforts in understanding and resolving this error. The "General: Failed to …" messages look less threatening and don't stop the progress of the process in quite the same way as the certificate validation problem.

    I would probably investigate the problem with the .NET "Mdbg" debugger and by editing the .exe.config file of the application to increase the diagnostic logging of System.Net and System.Net.Sockets namespaces. If you want to pursue this line of investigation and need any help then just ask.

    You posted your question on Saturday and the level of activity in the TechNet forums over weekends is much lower than that during the week, so contributions from people with actual experience of this product/problem might increase tomorrow.

    Gary

    Sunday, June 16, 2019 7:30 PM
  • Hi,

     

    Please provide below information:

    1. On both Windows client and WSE system, please open Run, type "winver" and end with enter, then, capture a screenshot about the system info.
    2. Please provide the complete log file. You may upload file to OneDrive (https://onedrive.live.com/) share it and provide me the access link. Please note that, log file may include private information, due to security consideration, you may choose to not share me the log files. And I will try to provide you other possible suggestion about the problem.
    3. Have this problematic client system connected to this WSE before? Or, other client system on the same network can successfully connect to WSE using connector.exe?

     

    Best Regards,

    Eve Wang



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

    Monday, June 17, 2019 5:15 AM
    Moderator
  • Hi Eve, have no onedrive, but take this one: https://www.opdepc.nl/p938502649571946gye74g/CompConn.zip.

    It has been anonymized.

    This is a new setup and it is the first PC we try to connect. Regards, Huibert.


    -Technet-Huibert.

    Monday, June 17, 2019 7:16 PM
  • Hi,

    On WSE, launch the IIS manager:
    1. Select <server name> -> Sites -> WSS CERTIFICATE WEB SERVICE.
    2. Double-click ISAPI filters feature to enter configuration.
    3. Verify if we have the following listed and pointed to correct path:


    Besides, if possible, please disable IPv6 via TCP/IP Properties temporarily on both client and WSE. If WSE is your internal DNS server, please assign only one WSE’s IP address as Preferred DNS server on Windows 10. 

    Then, try to connect again to check the result. If problem persists, I want to confirm with you if other windows client system can successfully connect to WSE using Connector? 

    Best Regards,
    Eve Wang

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

    Tuesday, June 18, 2019 8:55 AM
    Moderator
  • Hi Eve, will do, but I might have to wait for a series of updates Windows and exchange first, prb coming weekend. Will keep you informed.

    -Technet-Huibert.

    Tuesday, June 18, 2019 10:00 AM
  • Hi,

    Please feel free to let me know if there is any update about the thread.

    Best Regards,
    Eve Wang

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

    Wednesday, June 19, 2019 8:56 AM
    Moderator
  • Hi Eve,

    Had a moment and checked this one:

    

    Should be okay I guess.

    What role does this site (WSS CERTIFICATE WEB SERVICE) perform with respect to the ComputerConnector?

    -Huibert.


    -Technet-Huibert.

    Wednesday, June 19, 2019 9:07 AM
  • I have found that this IIS site (WSS CERTIFICATE WEB SERVICE) had only an external certificate available for all requests.  I now have added the internal cert servername.domainname.local besides remote.webdomain.com. Using SNI to make the difference here.  Testing did not yet result in success, but seems temp problem (connect failed completely, so firewall issue of some kind). Will have to fix that one first.

    As per Best Practices Analyzer we also changed the RPC proxy Registry key HKLM\SOFTWARE\Microsoft\RPC\RpcProxy\Website from "Exchange Back End" to "Default Web Site" (mind not including the dot at the end as suggeste by BPA..).  I expect however it is conflicting with the Exchange Admin (https://127.0.0.1/ecp) as that one no longer has content...

    Btw the BPA still complans about the certificate to be incorrect, but I suspect is does not check for SNI-selection.


    -Technet-Huibert.

    Tuesday, June 25, 2019 8:40 AM
  • For all to learn, SNI does not work with the Exchange Back End site, it should be needed also. The service behind the site reports there are two bindings, hence it stops so it did not understand SNI. An the other hand it is used only internally end thus only the internal self signed cert was needed.

    The suggestion of the BPA is pretty useless, as "something" periodically resets the Registry key back to "Exchange Back End". No use trying to change thus.

    Then back to that WSS Cert Web Service... OK, let's consider SNI is a no-go at Microsoft, so I removed the external web certificate remote.webdomain.com, disabled SNI and tried it again. All errors not somewhat gone, yet.. the important one is still there:

    [9128] 190626.173910.8998: ClientSetup: MachineIdentityManager.GetMachineStatus had errors: ErrorCatalog:NetworkError ErrorCode:-1
    BaseException: Microsoft.WindowsServerSolutions.Devices.Identity.MachineIdentityException: MachineIdentityManager.GetMachineStatus ---> System.ServiceModel.Security.SecurityNegotiationException: Kan geen vertrouwde relatie met het veilige SSL/TLS-kanaal maken met autoriteit servername:65500. ---> System.Net.WebException: De onderliggende verbinding is gesloten: Kan geen vertrouwde relatie met het beveiligde SSL/TLS-kanaal maken. ---> System.Security.Authentication.AuthenticationException: Het externe certificaat is ongeldig volgens de validatieprocedure.

    Fun part: I read servername:65500 and not servername.domain.local:65500 here, as is the name of the certificate connected to port 65500 in IIS. Can imagine it still is not OK. Btw. in English the err is sortof: "Unable to create a trusted relationship with the secure SSL / TLS channel with authority" and "The underlying connection is closed: Cannot create a trusted relationship with the secure SSL / TLS channel" and "The external certificate is invalid according to the validation procedure".

    -Huibert.

    Unable to create a trusted relationship with the secure SSL / TLS channel with authority
    Unable to create a trusted relationship with the secure SSL / TLS channel with authority
    Unable to create a trusted relationship with the secure SSL / TLS channel with authority

    -Technet-Huibert.

    Wednesday, June 26, 2019 4:08 PM