WinRM connection over SSL fails Win7 client to Server 2012 R2

This topic contains 10 replies, has 3 voices, and was last updated by Profile photo of Jason Colotario Jason Colotario 8 months ago.

  • Author
    Posts
  • #36127
    Profile photo of Jason Colotario
    Jason Colotario
    Participant

    I got cert mapping to work from Win7 client to Server 2008 R2 target, however from Win7 client to Win 2012 R2, it appears WinRM has had a major overhaul and does not allow cert mapped connections unless requestor and requestee are within the same subnet!!!

    I've ensure the appropriate firewall exception is enabled for WinRM over HTTPS. I've ensure my client does not have a firewall enabled.

    Has anyone else had this issue and are there any solutions? Is there a registry tweak for WinRM that forces it to allow SSL connections over WinRM from clients that are not part of the target machine's subnet?

  • #36193
    Profile photo of Don Jones
    Don Jones
    Keymaster

    There's always been a thing in WinRM that maybe you're running into. If a network interface is configured as "public," then access to remote computers is always limited to the same subnet. This can get vexing when you have a hypervisor that sets up virtual NICs, because those end up "public" without you realizing it.

    It'd be helpful to see any errors, you're getting, though.

  • #36456
    Profile photo of michalis anto
    michalis anto
    Participant

    I'm wondering if the -SkipNetworkProfileCheck parameter could make any difference on this.

  • #36768
    Profile photo of Jason Colotario
    Jason Colotario
    Participant

    @Michalis: I did not see a -SkipNetworkProfileCheck parameter listed for Invoke-Command parameters when remoting to a computer.

    @Don: The error message I am receiving is below:

    [destcomp.domain.tld] Connecting to remote server destcomp.domain.tld failed with the following error message : The WinRM client cannot process the request. The destination computer
    (destcomp.domain.tld:5986) returned an 'access denied' error. Specify one of the authentication mechanisms supported by the server. If Kerberos mechanism is used, verify that the client computer and
    the destination computer are joined to a domain. Possible authentication mechanisms reported by server: Negotiate For more information, see the about_Remote_Troubleshooting Help topic.
    + CategoryInfo : OpenError: (destcomp.domain.tld:String) [], PSRemotingTransportException
    + FullyQualifiedErrorId : AccessDenied,PSSessionStateBroken

    The command I am running:

    PS C:\Users\Me> Invoke-command -computername destcomp.domain.tld -SessionOption (New-PSsessionOption -SkipCACheck) -ScriptBlock {get-wmiobject Win32_PerfRawData_Tcpip_NetworkInterface} -CertificateThu
    mbprint 086db319165g08ta151r790b243982679v93ecmq

  • #36769
    Profile photo of Jason Colotario
    Jason Colotario
    Participant

    @Don: You mentioned "There's always been a thing in WinRM that maybe you're running into. If a network interface is configured as "public," then access to remote computers is always limited to the same subnet."

    Q: I don't have a problem with WinRM cert-mapping from Win7 to server 2008 R2 when the adapter is configured as public.

  • #36770
    Profile photo of Jason Colotario
    Jason Colotario
    Participant

    @Don: I was also wondering if the host firewall exception for WinRM has to be configured for both inbound and outbound WinRM requests from some client so that the request can not only be received but the result data of the request and make its way back to the requesting client.

  • #36772
    Profile photo of Don Jones
    Don Jones
    Keymaster

    Jason, the problem is when one of the RECEIVING computer's NICs are "public." If you don't have a -SkipNetworkProfileCheck on Enable-PSRemoting, then you're using 2.0.

    The Windows Firewall will not normally block outgoing connections of any type, no. However, it can be configured to do so.

    The error you're getting indicates that either the receiving computer does not support the authentication you're attempting to use (by default, it uses Kerberos; is it in a domain? is the client?), or that you aren't authorized. By default, Remoting endpoints only permit local Administrators and members of the Remote Management user group to connect.

    You don't indicate what kind of certificate you're attempting to use. However, WinRM by default only enables Kerberos on the receiving machine – so you may need to enable a different authentication type on the receiving machine. If you're attempting to use a machine certificate, that won't work, as it doesn't identify _you_.

    Your error, in short, means one of two things – and ONLY these – there's no point troubleshooting anything else:

    1. Your certificate isn't understood or accepted by the remote machine

    2. Your authentication protocol isn't enabled on the remote machine

  • #36887
    Profile photo of Jason Colotario
    Jason Colotario
    Participant

    Hi Don,

    (responding with my details – I appreciate all feedback and options if my configuration just will not work in Win7 -> Server 2012 R2)

    – In my case, I am not using "enable-psremoting", rather I am attempting a non-interactive (see command/statement below) exchange with Win7 (client) to Server 2012 R2 (target).
    -The client computer is domain-joined whereas the target is a stand-alone computer.
    – I verified that my account is added to groups "remote desktop users" and "remote management users". My account is in the administrators group on both machines.
    – I verified the target computer has the necessary firewall exceptions.
    – I verified Test-wsman responds over SSL (see wsman response below)
    – I verified the certificates are stored properly on client and target and I am using the correct thumbprint.
    – I verified UAC is controlled via LocalAccountTokenFilterPolicy registry key.

    (see command/statement below)

    Invoke-command -computername host-test.domain.com -SessionOption (New-PSsessionOption -SkipCACheck -SkipCNCheck) -ScriptBlock {get-wmiobject Win
    32_PerfRawData_Tcpip_NetworkInterface} -CertificateThumbprint 0b7ga369175f08ea111c890b846982b7cb93ahfd

    (error message)
    [host-test.domain.com] Connecting to remote server host-test.domain.com failed with the following error message : The WinRM client cannot process the request. The
    destination computer (host-test.domain.com:5986) returned an 'access denied' error. Specify one of the authentication mechanisms supported by the server. If Kerberos mechanism
    is used, verify that the client computer and the destination computer are joined to a domain. Possible authentication mechanisms reported by server: Negotiate For more
    information, see the about_Remote_Troubleshooting Help topic.
    + CategoryInfo : OpenError: (host-test.domain.com:String) [], PSRemotingTransportException
    + FullyQualifiedErrorId : AccessDenied,PSSessionStateBroken

    (see wsman response below)

    jcolotario 2016-03-22_15:15:05> test-wsman -computer host-test.domain.com -usessl -port 5986

    wsmid : http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd
    ProtocolVersion : http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
    ProductVendor : Microsoft Corporation
    ProductVersion : OS: 0.0.0 SP: 0.0 Stack: 3.0

    Both client and target $PSversiontable output:

    Name Value
    —- —–
    PSVersion 4.0
    WSManStackVersion 3.0
    SerializationVersion 1.1.0.1
    CLRVersion 4.0.30319.34209
    BuildVersion 6.3.9600.16406
    PSCompatibleVersions {1.0, 2.0, 3.0, 4.0}
    PSRemotingProtocolVersion 2.2

    ============================================================

    I find it very curious that I can get this to work Win7 to Server 2008 R2, whereas Win7 to 2012 R2 just does not want to "play ball". I am also wondering if there is anyone else out these who has gotten this configuration to work.

  • #36888
    Profile photo of Don Jones
    Don Jones
    Keymaster

    Since both machines aren't in the domain, Kerberos, which is the only default protocol, won't work. You need to use Basic, and either add the server to TrustedHosts on the client, or add an SSL certificate to the server and force us of SSL. Read "Secrets of PowerShell Remoting," my free e-book on the subject.

    -CertificateThumbprint has nothing to do with SSL, just so we are clear. It is specifying a client certificate that will authenticate you to the server. You aren't specifying an auto mechanism, and you aren't specifying -UseSSL. So it's trying to use Kerberos, which can't work.

    I would consider, as a temporary test, using Basic authentication, -UseSSL, and -Credential. Instead of a client certificate. Specify a server-local Admin account for that credential. And, again, the server must have an SSL certificate, and a self signed certificate is not acceptable. If you're using -SkipCa and -SkipCn, then you're absolutely doing it wrong.

  • #36889
    Profile photo of Don Jones
    Don Jones
    Keymaster

    And as a specific note, you need to ENABLE something other than Kerberos on the server for incoming connections, and ensure the same alternate protocol is enabled on the client for outbound connections.

  • #37323
    Profile photo of Jason Colotario
    Jason Colotario
    Participant

    Update: I got Win7 to Server 2012 R2 to work. PS remoting is the best thing since sliced bread....

    Take care,

    JRC

You must be logged in to reply to this topic.