Windows Server 2012 comes with a new feature that allows you to administrate the server via a PowerShell command line in any modern browser including Smartphones.

This sounds cool and scary at the same time.

I am evaluating this option and are wondering what the risks are?

This is my current setup:

  • Running on Server 2012 Core
  • Stand-alone server no domain involved.
  • The site is running under SSL (required by PowerShell Web Access)
  • It is protected by Windows Authentication (to add another level of security)
  • The url for it is not the default one but a hard to guess deep url.
  • There is a single user set up to use the feature.
  • maxSessionsAllowedPerUser is set to one. This means that even if the password of the single user was sniffed, a second session for the same user is not allowed.
  • After the user is done with his work, he changes his password. This is done via a script on the server. The first half of the password is a constant secret and the second half is typed by the user. This way the full password never goes over the line.
  • Each complex password is used only once.

To get any work done on the server the user has to be an administrator.

PoweShell Web Access is a 1.0 product, so there may be bugs in it.

Considering all this, is it advisable to use this in production on a server expose to the public internet?

  • 1
    Note that "Windows Authentication" outside of a domain, i.e. NTLM as opposed to Kerberos, is not good. If you have to ask, then you shouldn't consider it any more secure than http basic auth. So I wouldn't call it an "extra" layer. You still really want SSL there to encrypt the authentication protocol.
    – sourcejedi
    Commented Oct 19, 2012 at 9:45

2 Answers 2


As with all scenarios it depends on what you are protecting against. Generally speaking, its not wise to host administrative endpoints on public networks. In other words change the site to not be accessible on the internet.

Second, some people have problems with domain-joined servers on the internet. If its breached, then attackers have access to your domain. If you have an open Powershell connection, you've given them a great place to launch an attack. However, some people don't have a problem with it as they mitigate certain risks by limiting what that server can access internally, having a read-only domain controller be the only thing the server can talk to AD-wise, and locking down all ports but 443.

Third, some people don't like Windows auth on the internet, for the same reason as the second.

The problem with Powershell only allowing one user is that its only limited to Powershell. An attacker could potentially just find another place to login. Or they could just drop the connection of the current user before the script has a chance to run. Etc.

I'm not sure it being a v1 product is a security risk per se. There is a fair amount of effort that Microsoft goes through to make sure a new product is secure before launch. However, since it hasn't gone through the full gamut of tests by external security testers, its always a possibility there are security vulnerabilities.


This is Microsoft's version of a SSH server (conceptually, not exactly -- the exact Unix equivalent is Shell In A Box). There is nothing scary there, as long as you trust Microsoft for not botching the implementation (but relying on SSL, thus on existing implementations of SSL, is a smart move).

The bit about using a Web browser could prove a bit risky, though, because Web browsers do not have a good record with regards to security. They routinely execute potentially malicious code (Javascript) and though they try hard to isolate pages from each other, cross-domain attacks have happened and will probably keep on happening. Instead of inventing new ways to make work a living Hell for your users (e.g. forcing password changes), you should rather make them use a specific browser for this access (for instance, if they use Chrome for their usual browsing, make them launch a Firefox for the PowerShell access -- to be used only for that).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .