GET-IT: TEAMS DAY | 1-Day Free Virtual Conference all about Teams. Here on - 8/12/20 GET-IT: TEAMS DAY - 8/12/20

PowerShell Web Access: Configuration

We’re back with our look at Powershell Web Access (PSWA), a multi-part series in which I walk you through the installation, configuration, testing, and reconfiguring PSWA for use in the domain. Powershell Web Access — a web-based application — allows you to establish a remote PowerShell session via a web browser. With PSWA you are able to remotely manage servers from a machine that doesn’t even have PowerShell installed on it, such as a Mac or Android tablet.

In the first article I showed how to install PowerShell Web Access remotely on a new web server from a Windows 8 client running Remote Server Administration Tools (RSAT). In part three I’ll show you how to test the PSWA web application, and in the final article we’ll reconfigure PowerShell Web Access for use in the domain.

PSWA and Gateway Configuration

You could run the necessary commands on the server, but I prefer remote management. I’ll open a remote PowerShell session to the server from my Windows 8 desktop.

For now, I’m going to configure the gateway to use a self-signed test certificate. Later the website can be configured to use a valid certificate.

This command assumes I haven’t changed the default web site name (“Default Web Site”) or application name (“pswa”). Figure 1 depicts the result.


Configure Gateway Powershell Web Access

I can’t think of a good reason to modify the application name. The application is secure out-of-the-box.

Configuring Authorization Rules with PSWA

By default, nobody has access to PowerShell Web Access. You must define authorization rules using the Add-PswaAuthorizationRule cmdlet. This too must be run on the web server, so I’ll use my existing remote session. You will need to specify a user name or user group that want to grant access to, the names of computers that you want to allow remote access to (you can also use a group name that contains computer accounts), and the configuration name.

The configuration is the name of a remoting endpoint. The PowerShell Web Access gateway will establish a remote connection to this endpoint. You can use Get-PSSessionConfiguration to enumerate the sessions.

Figure 2 below shows the available endpoints on CHI-DC03.


Configure Powershell Web Access


The session configuration must exist on all computers in your rule. I’m going to create a test authorization rule using the Microsoft.PowerShell configuration. This is essentially the end point you get with a regular remoting session. Optionally, you can define a rule name, as I’ve done here.

But wait a moment — if you try this on a new system, you’ll most likely get an error like this:

If you run the command in an interactive (i.e. not via remoting) session on the server it should work just fine. The problem here is the second hop. The Add-PSwaAuthorizationRule cmdlet needs to make a connection to a domain controller, which by security design is not allowed in PowerShell Remoting. This second-hop limitation can be overcome by enabling CredSSP authentication. Note: This is not be done lightly as there are security ramifications, so research this fully before employing.

But in my situation, since I want to use remoting, I’ll exit out of the remote session and enable CredSSP on my desktop for CHI-WEB01.

Next, I need to enable the server side.

With this in place, I can now re-establish my remote session specifying CredSSP and my credentials.

Now when I run the authorization command, it works as you can see below in Figure 3.


Configure Powershell Web Access

I can also verify the rule:

You can add as many different authorization rules as you need. You can connect to PowerShell v2 machines as long as they have remoting enabled. Here, I’ll add a rule to a domain controller still running PowerShell v2.

To delete a rule use Remove-PwaAuthorizationRule. Specify the rule by id or the rule object.


All of the PowerShell Web Access configuration settings that I’ve covered can also be done manually via the GUI in the IIS manager. But frankly, that is a lot of point-and-click work that is very prone to error. I’m assuming that if you are setting up PowerShell Web Access that you already are comfortable with PowerShell. The configuration cmdlets need to be run on the web server hosting the PSWA application. But you can use PowerShell remoting to effect the changes, although you might need to enable CredSSP for part of the process. In the next part of the series we’ll look at testing and using PSWA.


Related Topics:

  • PowerShell

    Don't have a login but want to join the conversation? Sign up for a Petri Account