Further benefit is the script on the CLIENT doesn’t need an embedded password or secure-string encrypted text file to lookup the password, this is important if I want to run it as a task or call it from a service. The account on the target server can have an ultra long and complex password which changes frequently as I don’t need to know it for my script to work.
It is also an alternative to using CredSSP for overcoming “second hop” issues. CredSSP, as I understand it, passes the credentials of the user on the CLIENT machine to SERVER allowing the SERVER to authenticate as the CLIENT user for onward calls. Using SSL and mapping means I am using the credentials of the local user on the SERVER, the SERVER does not know the CLIENT users credentials. I am interested in this option for administering servers in a DMZ environment.
I finally have this working, so many thanks for the input. I’ve discovered that the -Subject text in New-Item appears to be case sensitive so if the cert were issued with a SAN stating a principal name of Name@DOMAIN.local it needs to be entered exactly as appears in the cert. Maybe a troubleshooting step in the doc could be to use -Subject * to rule out everything else then experiment with changing the Subject. To do this you need to clear previous mappings:
Then issue the New-Item cmdlet again revising the -Subject value.
One of thing is it might be a good idea to use a specific account on the SERVER for mapping rather than BUILTIN\Administrator just to make things a bit clearer and avoid ambiguity?
I hope you don’t take this in a negatively because your doc is excellent and has helped me get this working when no other such instructions appear anywhere else on the Internet.
[quote=9814]I’ve discovered that the -Subject text in New-Item appears to be case sensitive so if the cert were issued with a SAN stating a principal name of Name@DOMAIN.local it needs to be entered exactly as appears in the cert.
[/quote]
That’s strange; I’m not seeing the same behavior. I just tried removing the client mapping and recreating it with different combinations of capital and lowercase letters, and it worked every time (including the very annoying ‘DlWyAtT@tEsTdOmAiN.lOcAl’). Are you sure there wasn’t just a typo the first time?
If you haven’t done so yet, check the “Windows Remote Management\Operational” event log. There should be errors there from when the failed connections were attempted, and there might be more details on what happened.
Re-tried this evening and it would seem I was making a mistake in the command and that it is NOT case sensitive. I can only assume a trailing space or something in notepad where I was manipulating the -subject parameter.
No problem! This might be useful for my company, as well. In some places, we use SSH with certificate authentication for this same type of scenario (scheduled tasks authenticating to workgroup machines), but going with PS Remoting instead is an option now.
I am a little late in the game so to speak. I am excited that cert mapping is an option for remoting to untrusted domain(s) as I definitely want to avoid sending any credentials clear text - even if CredSSP establishes the SSL/TLS session prior to employing NTLM to send the creds. It is essential that MITM attacks are avoided - as many know, in cloud infrastructures, Admin creds are usually consistent across each box with regular credential rotations.
Dave - thank you for your write up, it will help all us budding Admins out there do things “the right way”. I do have a question: When creating the cert for client machine is it “ok” to use tool such as openssl or should I use AD CS to create a self-signed cert for both CLIENT and SERVER? When setting up PS remoting in my test environment, I created the SERVER cert and private key on my client machine and installed it on SERVER. Is it absolutely necessary to use AD CS in addition to traditional PKI? I could potentially use a class-2 CA if a self-signed cert presents concerns.
Don - I watched your 2013 PS Summit presentation on PS remoting - that was my first glimpse on it, thank you.
Any valid certificate should be fine, so long as it has the right hostnames / key usage / etc. ADCS is just what I had handy in my lab when I did the tests and screenshots.
If so, you technically can use a wildcard there, but you might be creating a security vulnerability by doing so. For instance, if the subject were “*@testdomain.local”, anyone who had a certificate with a matching name (issued by the correct CA) would be allowed to authenticate using this mapping.
I haven’t tried that, personally. If you use a certificate that doesn’t have a CN matching the hostname, you’d normally have to use some extra command-line options on the client side to connect (New-PSSessionOption -SkipCNCheck). I’m not sure if that also applies to wildcard certificates.
I also made several testcases to test the access to a domain joined machine and a workgroup machine. WinRM to the domain joined machine was working as expected but the access to a workgroup machine never worked. At least on one machine the authentication was past the certificate validation but failed then with an url error. The winrm log only shows the error but no explanation why it went wrong. All the machines were running Windows Server 2008 R2 SP1 or W2012 R2 and the firewall was set to off. How to enable a more verbose winrm log?
Server 2012 R2: Getting “Access is Denied” when running command/syntax below. The thumbprint and computer name are fictitious. I’ve been able to get this to work from Win7 to Server 2008 R2, however Server 2102 R2 doesn’t like it. I’ve already set the firewall to allow inbound traffic over 5986.
Error:
Comp1] Connecting to remote server Comp1 failed with the following error message
The WinRM client cannot process the request. The destination computer (Comp1:5986) returned an
access denied’ error. Specify one of the authentication mechanisms supported by the server. If Kerberos mechanism is
sed, verify that the client computer and the destination computer are joined to a domain. Possible authentication
echanisms reported by server: Negotiate For more information, see the about_Remote_Troubleshooting Help topic.
Update: 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?
I am able to connect using cert-auth, however when I connect, it shows the user path on the command prompt of the user that originally created/installed the SSL cert for remoting under his own account. How can we configure the remote session/connection so that the user path shows the correct user path for anyone connecting to the target?
I have been through the steps in the eBook (very helpful btw - thank you) for setting up certificate authentication. The use case is I want to be able to connect (ultimately from Ansible) to WinRM to a newly provisioned EC2 instance (we are blocked from using AWS tools or this would be much easier) in order to change the hostname, install some agents, then join the domain. Presumably after the domain join, we will use kerberos authentication, but for the short time that the VM is not domain joined I need to securely connect to it in order to complete several automation tasks. I would rather not use username/password, so have been testing auth with certificates. I have validated that WinRM works over ssl if I pass username and password. However, when I try to use cert authentication I get the following, which seems to indicate a problem with my user certificate.
“If you are using a user certificate, the Subject Alternative Name extension must contain a UPN name and must not contain a DNS name. Change the certificate structure and try the request again.”
There is a local account on each new EC2 instance (vmadmin). The certificate that I am attempting to use was signed by our own CA, and the trust chain is trusted on both WinRM client and the remote VM. The certificate is in the client’s user store and the remote VM’s trusted people.
– Subject: CN = vmadmin
– Key Usage: Digital Signature, Key Encipherment, Data Encipherment(b0)
– Enhanced Key Usage: Server Authentication (1.3.6.1.5.5.7.3.1), Client Authentication (1.3.6.1.5.5.7.3.2)
– Subject Alternative Name: Other Name: Principal Name=vmadmin@localhost
I don’t want to continue guessing at what the certificate should look like, so if someone has this working and could provide me the details I would really appreciate it.