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?
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.
[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
@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.
@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.
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:
Your certificate isn’t understood or accepted by the remote machine
Your authentication protocol isn’t enabled on the remote machine
(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.
(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
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.
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.
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.