I have been taking a look at the “secrets of powershell remoting” but would like some clarification on a couple of points.
In our desktop environment the vast majority of machines reside in a single forest comprised of multiple domains so this shoud be fairly simple to set up and manage.
Our server environment however has globally over a hundred separate forests (no trusts between them) and several hundred workgroup servers.
I’m aware that when you remote between machines that are not in the same forest kerberos is no longer used. In this scenario:
Is it NTLMv2 doing the actual authentication? If not what?
No username and password can be sniffed?
Will the traffic still be encrypted?
I’m aware from the guide that you can set up https but it suggests that this cannot be automated and as we have over 15000 servers and several hundred new servers being provisioned a week this would not seem to be a practical solution.
You have to enable an alternate form of communication, but NTLMv2 isn’t one of them. Basic, Digest, and CredSSP are options. Basic is of course clear-text transmission of usernames and passwords - so yes, sniffable. Which is why you also set up HTTPS, so encrypt that channel.
Setting up HTTPS can be automated - but it’s hard (depending on the environment specifics). But it’s worth it. And you don’t have a ton of alternatives if you want to remain secure. How automated you can make it depends a lot on what kind of PKI you have. With ADCS, it’s entirely possible to set up auto-enrollment for servers’ certificates, for example. I’m not the expert on doing so, but I know folks who’ve done it.
A sub-alternate might be to install, in each domain, a “gateway server” that you remote into. Put SSL on it, and use it as a jumping-off point to other servers within the same domain. That might be more manageable. The authentication remains tricky; you’d connect to it using a credential from THAT domain, and then have to enable delegation or CredSSP to go from that gateway server to the actual server you wanted.
You have to enable an alternate form of communication, but NTLMv2 isn’t one of them. Basic, Digest, and CredSSP are options. Basic is of course clear-text transmission of usernames and passwords - so yes, sniffable. Which is why you also set up HTTPS, so encrypt that channel.
Setting up HTTPS can be automated - but it’s hard (depending on the environment specifics). But it’s worth it. And you don’t have a ton of alternatives if you want to remain secure. How automated you can make it depends a lot on what kind of PKI you have. With ADCS, it’s entirely possible to set up auto-enrollment for servers’ certificates, for example. I’m not the expert on doing so, but I know folks who’ve done it.
A sub-alternate might be to install, in each domain, a “gateway server” that you remote into. Put SSL on it, and use it as a jumping-off point to other servers within the same domain. That might be more manageable. The authentication remains tricky; you’d connect to it using a credential from THAT domain, and then have to enable delegation or CredSSP to go from that gateway server to the actual server you wanted.
I think one of the problems with ADCS is that if your servers are outside a forest it can be complicated to set up and not particularly firewall friendly which is what we are trying to get away from with PowerShell remoting.
I think the second option would be the better but not without its challenges.
It would be good to see some whitepaper from Microsoft to see how best to work through some of these challenges for businesses that are running multiple separeate forests and workgroup environments. We have to adhere to PCI compliance but I haven’t seen anything regards Powershell remoting.
The connection is made using Kerberos or NT LAN Manager (NTLM). The server uses Kerberos to authenticate a domain account and NTLM for local computer accounts. The user name should be specified in the form domain\username for domain users or servername\username for a local users on a server computer. This field is introduced in Windows PowerShell 2.0.
I hope this isn’t a daft question but the scenario where machines are in the same domain and using kerberos is all remoting traffic on the wire encrypted or is it just the authentication part? I’m sure in the recent Powershell Jumpstart they compared it to a secure telnet session.
Well, doing anything in bulk with machines outside a domain - meaning they don’t, by definition, trust each other - is challenging. No question. But that’s what forests solve; if you can’t use that solution, there isn’t really much of an alternative one.
I can’t speak to white papers from Microsoft :). You’d have to suggest that to them. In terms of PCI (or other) compliance, WS-MAN is just a protocol. I don’t think it has any special security considerations - no more so than, say, RDP or RPCs you probably already use. But WS-MAN itself is pretty well documented. In and of itself, it doesn’t carry anything sensitive. It’s what you put on the channel, which MS can’t predict.
NTLM might be an option; it’s not one I’ve used and I’m not in front of a machine I can check. The environments I work in are typically more built around machines all being in domains.
In terms of “is all traffic encrypted,” the authentication protocol doesn’t matter. Application-level shared-secret encryption is used by default in PowerShell, though there’s an option to disable it. That isn’t “all traffic on the wire;” it’s WinRM application traffic. You’d need to still use HTTPS if you wanted a completely encrypted, asymmetric-key encrypted session. In terms of whether you’d need to do that - well, it depends on what you’re transmitting between machines. You could also configure IPSec encryption around the whole thing if you wanted, but that’d be higher-impact, I believe, than HTTPS.
Authentication with Kerberos isn’t “encrypted” per se; encryption isn’t how Kerberos protects your credentials. Kerberos simply never transmits your credentials - it transmits tickets which are digitally signed. The signature is what validates them; they don’t contain anything sensitive that specifically would require the privacy of encryption.
Some of the Powershell help files seem to be a little “light” around these areas.
Still not clear what authentication protocol it falls back to if kerberos cannot be used and no option is explicity used (uses deafault whatever that is)but we can do some testing.
If Powershell is carrying out application encryption and we can stay away from basic authentication then I’m hoping we won’t need to use SSL internally.