by Typeo at 2013-04-09 11:44:35
The server environment I work in does not put a lot of the servers in our domain and because of that, I have had to take the long route to be able to use any type of remote administering through PowerShell. What I am talking about is having to add servers or everything (*) as a trusted host on my desktop machine and basically send the username and password out over the network the the following enter-pssession or Invoke command:
Enter-PSSession -computername Name -credentials Username
I would them either hard code the password in the script or just type it out manually into the pop up box.
Basically, I am curious if going this route is actually secure? Are there big security risks in doing this, and should I only use Powershell remote administering from servers that actually reside on the Domain?
by DonJ at 2013-04-09 23:37:28
No, it is not secure. TrustedHosts disables mutual authentication for the specified machines – in your case, all machine. So you're basically handing your administrative credentials to an unverified computer – there's plenty of risk there. Basically, you're putting the keys to your house out on the front lawn for anyone to pick up and use in whatever way they wish. Adding individual servers is better, but still not ideal.
A better alternative would be to deploy SSL certificates to those computers. You can then use "-UseSSL -Credential username" and get the mutual authentication that Kerberos provides inside a domain. See "Secrets of PowerShell Remoting" (free) at PowerShellBooks.com for a lot more on this, including instructions for setting it up.
by Typeo at 2013-04-10 13:47:48
I will have to do some reading into the SSL certificates.
Thanks a bunch for the help / explanation!
by Typeo at 2013-04-12 08:58:32
I have been reading the suggested material and I was curious about a couple things. Doing it this way, I will need to purchase a SSL Cert for each server I want to remotely manage correct?
If that is the case, we currently have a WildCard Cert. Would we possibly be able to use that one instead of making specific ones for each server? Reason I ask is in the book it states the following:
[quote]fill in the information about your organization. This needs to be exact:
The â€œCommon Nameâ€ is exactly what people will type to access the computer on which this SSL certificate will be
installed. That might be â€œdca,â€ in our case, or â€œdc01.ad20082.locâ€ if a fully qualified name is needed[/quote]
So, if my wildcard cert were good for any server with the following name:
would I be able to use this SSL cert for any server that had the .uni.edu? The above statement from the book makes me think I wouldn't be able to, but I wanted to double check and see.
by DonJ at 2013-04-12 19:37:09
You don't need to "purchase" if you set up an internal PKI. Windows includes ADCS for that purpose. And yes, a wildcard cert works somewhat like that, although your CA must offer that type.
by Typeo at 2013-04-17 10:27:32
Just wanted to update and put closure on the thread. I was able to use our WildCard Cert to import into the personal certificates folder, run the winRM command listed in the PDF you linked earlier, and opened up the 5986 port. I am now able to connect to the servers without having anything listed on the trusted hosts on my client machine. I still have to type the credentials, but I am assuming that is fine now since I am using the -UseSSL parameter.
Thanks a bunch for all your help! It took a bit to figure it out and get it setup the first time, but once you run through it the first time it only takes a few minutes to setup.
by DonJ at 2013-04-17 10:31:42
Yup, the credentials are being encrypted by SSL. You have to provide them manually because Kerberos can't delegate your credential across that boundary. Enjoy!