"The listener that is created when you enable PowerShell Remoting is over HTTP. You are able also to configure WinRM over HTTPS"
Doesn't seem like a good idea to default to plaintext.
Doesn't seem like a good idea to default to plaintext.
"Regardless of the transport protocol used (HTTP or HTTPS), PowerShell Remoting always encrypts all communication after initial authentication with a per-session AES-256 symmetric key."
https://docs.microsoft.com/en-us/powershell/scripting/setup/...
It's encrypted, except when it isn't, except on Tuesdays when it is.
https://www.reddit.com/r/PowerShell/comments/97oxox/comment/...
"Just an FYI not all psremoting traffic is encrypted when using http. Message encryption is done using the authenticated context which varies based on what auth was actually used.
For example Basic auth has no authenticated context in SSPI so has no encryption.
NTLM (fallback if kerb is not available) is next to useless as it is based on RC4 which is considered broken today.
Kerberos should be using AES if configured correctly but older environment may have older insecure algorithms set up if the config is mismanaged on the domain level.
CredSSP uses the TLS context that is set up in the auth so is similar to using HTTPS.
When using https you not only get a more consistent and secure encryption mechanism on all auth methods. You also get encryption on the whole TCP packet that is sent to the client, whereas http message only encryption encrypts the message body."
And
"My understanding of the issue is that WinRM can do more than just Powershell Remoting (for example there are also Python libraries that run on Linux machines to interface with WinRM which I'm assuming do something different to PS remoting since PS is not native/required on those platforms). So if you are doing ONLY Powershell Remoting you're probably fine with HTTP, but if you're doing anything else then it could be exposed via HTTP WinRM. So HTTPS is still recommended.
tl;dr - All Powershell Remoting is WinRM, not all WinRM traffic is PS Remoting."
https://www.reddit.com/r/sysadmin/comments/5vph9l/winrm_encr...
And
I think lots of people couldn't get a straight answer on this and it came up on the recent MCP Insider AMA.
First 3 minutes of video 2 "it's secure, use it [...] tell 'em Jeffrey Snover told you, go do it".
"Also, for more information on security when remoting read the powershell.org free e-book, Secrets of PowerShell Remoting.*"
https://www.reddit.com/r/PowerShell/comments/34yzgt/comment/...
What surprises me the most is they could've used the existing (also quite over-engineered, but existing nonetheless) MSRPC infrastructure for this, like what psexec does, but chose to use a completely different set of technologies once again.
A lot of their server side products have weird restrictions or integrate with their other products in strange ways. Nothing is standardised, or simple.
For example, I'm in the middle of a project that needs to log audit data from a front-end service. The service isn't that busy, so doesn't really log that much, however the reporting interface only works with System Center. So to build out the reporting infrastructure I need: 2x System Center Service Manager Management Servers, and 2x System Center Service Manager Data Warehouse Servers, and 2x SQL Servers in a live-sync arrangement. That's six servers, three in each Datacenter. Four of which need 16Gb of RAM. The Management Servers do hardly any work, but due to an artificial restriction placed in the installer, you cannot install them on the same boxes as the Data Warehouse component. Even if you could, MS wouldn't support it.
All this to log no more than 100-200 events a day. To do the reporting any other way, is unsupported. It's nuts. I am starting to believe that Microsoft are now deliberately making their products so complex and so expensive to build on premises, in order to push customers into their Cloud platforms instead. This is certainly true of Exchange Server which is now an absolute nightmare to manage on premises. It's a mail server, why is it so complex?!
To be honest, it wouldn't surprise me if even internal Microsoft product designers and engineers no longer understand how most of the Microsoft server products even work or integrate.
And I say all this as someone who's spent 25 years working with Microsoft products as my day job.