Summary: Guest blogger Windows PowerShell MVP Don Jones talks about remote Windows PowerShell authentication.
Microsoft Scripting Guy, Ed Wilson, is here. Today, I have a special treat for you. Windows PowerShell MVP Don Jones just had a new book released for publication and we have a sample from that book to share.
 | Learn Windows PowerShell 3 in a Month of Lunches, Second Edition By Don Jones Folks tend to think of authentication as a one-way process: you want to access some remote machine, and you have to provide it with your credentials before it will let you in. But, Windows PowerShell remoting uses mutual authentication. In this article, based on chapter 23 of Learn Windows PowerShell 3 in a Month of Lunches, Second Edition, author Don Jones goes deeper into remoting authentication.
|
Digging Deeper into Remoting Authentication
Windows PowerShell remoting employs mutual authentication, which means the remote machine must also prove its identity to you. In other words, if you run Enter-PSSession -computerName DC01, the computer named DC01 has to prove it’s really DC01 before the connection will complete.
Why? Normally, your computer will resolve a computer name (like DC01) to an IP address by using the Domain Name System (DNS). DNS isn’t invulnerable to spoofing, so it’s not unthinkable that an attacker could get in and modify the entry for C01 to point to a different IP address—an IP address that the attacker controls. You could unknowingly connect to DC01, wind up on an imposter computer, and then start delegating your credential to it—bad news! Mutual authentication prevents that from happening: if the computer you connect to cannot prove it’s the one you intended to connect to, then remoting will fail. That’s a good thing—you don’t want to turn that protection off without careful planning and consideration.
Defaults for mutual authentication
Microsoft expects most Windows PowerShell usage to occur in an Active Directory domain environment. Provided you connect to computers by using their real computer names, as listed in Active Directory, the domain will handle the mutual authentication for you.
This even happens when you access computers in other, trusting domains. The trick is that you need to provide Windows PowerShell with a computer name that will accomplish both of these requirements:
- The name must resolve to an IP address.
- The name must match the computer’s name in the directory.
Providing a computer name from the same domain that you’re in, or a fully qualified name (computer and domain name, like DC01.COMPANY.LOC) for a trusting domain, usually accomplishes both of these tasks. But if you need to provide an IP address, or if you need to provide a different name for DNS to work (such as a CNAME alias), then the default mutual authentication won’t work. That leaves you with two choices: SSL or TrustedHosts.
Mutual authentication via SSL
For this technique, you’ll need to obtain an SSL digital certificate for the destination machine. The certificate must be issued to the same computer name that you’ll type to access the computer. That is, if you’re running Enter-PSession –computerName DC01.COMPANY.LOC -UseSSL -credential COMPANY\Administrator, then the certificate installed on DC01 must be issued to “dc01.company.loc” or the entire process will fail. Note that the -credential parameter is mandatory in this scenario.
After getting your certificate, you need to install it into the Personal certificate store for the computer account—something best accomplished with the Certificates snap-in in the Microsoft Management Console (MMC) GUI. Simply double-clicking a certificate file will usually put it in your user account’s Personal store, but that won’t work.
With the certificate installed, you’ll need to create an HTTPS listener on the computer, telling it to use the newly installed certificate. The step-by-step directions are quite extensive, and because this isn’t something a lot of people will probably do, we’re not going to cover them all here. Take a look at Don’s Secrets of PowerShell Remoting guide (it’s free), and you’ll find step-by-step instructions including screenshots.
Mutual authentication via TrustedHosts
This is a slightly easier technique than using an SSL certificate, and it requires a lot less setup. But it’s a bit more dangerous, because it basically shuts off mutual authentication for selected hosts. Before you try it, you need to be able to confidently state, “it is unthinkable that someone could impersonate one of these hosts, or hack their DNS records.” For internal computers on your intranet, for example, you might feel pretty confident of that.
Then you just need a way to identify the computers you’ll trust without mutual authentication. In a domain, for example, that might be something like “*.COMPANY.COM” for all hosts in the Company.com domain.
This is an instance where you’re likely going to want to configure the setting for your entire domain, so we’ll give you the Group Policy instructions. You can use these same instructions for a single computer’s Local Security Policy.
In any GPO or in the Local Computer Policy editor, follow these steps:
- Expand Computer Configuration.
- Expand Administrative Templates.
- Expand Windows Components.
- Expand Windows Remote Management.
- Expand WinRM Client.
- Double-click Trusted Hosts.
- Enable the policy and add your trusted hosts lists. Multiple entries can be separated by commas, such as “*.company.com,*.sales.company.com.”
Note Older versions of Windows might not have the template needed to display these settings in the Local Computer Policy, and older domain controllers might not have them in their Group Policy Objects. For those situations, you can change the Trusted Hosts list in Windows PowerShell. Run Help about_remote_troubleshooting in the shell for instructions.
Summary
Now you’ll be able to connect to those machines without mutual authentication getting in the way. You must provide a -Credential parameter with all remoting commands used to connect to these computers—failure to do so will result in a failed connection attempt.
That's it for today. Don's book will be available later this month.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy