Author Posts

March 5, 2016 at 5:11 pm

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?

March 7, 2016 at 1:35 pm

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.

March 12, 2016 at 6:22 am

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

March 19, 2016 at 2:05 pm

@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

March 19, 2016 at 2:09 pm

@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.

March 19, 2016 at 2:12 pm

@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.

March 19, 2016 at 2:39 pm

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

March 22, 2016 at 2:40 pm

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.

March 22, 2016 at 2:47 pm

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.

March 22, 2016 at 2:48 pm

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.

April 6, 2016 at 8:15 am

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

Take care,

JRC