Back to Home

Customizing PowerShell Web Access for you / Netwrix Blog

powershell web access

Customize PowerShell Web Access for you

Original author: Jeff Hicks
  • Transfer
  • Tutorial

We are finishing the review of working with PowerShell Web Access (PSWA) on Windows Server 2012. In it we will configure it “for ourselves”, for the needs of use in our domain.
In previous posts, we looked at the following:

In this post, we will look at how to remove test rules, install a domain certificate, create domain rules for PSWA, test them and briefly outline what you can do next. Details under the cut.

Delete test rules


To start, I'm going to delete all the test rules I created. Later I will configure a few rules for the domain, but now I'm going to double-check the configured rules using the Invoke-Command cmdlet to remotely run the command on a web server with a running PSWA.

PS C:\> invoke-command {Get-PSwaAuthorizationRule} -comp chi-web01


image

All rules can be removed by passing to Remove-PswaAuthorizationrule .

PS C:\> invoke-command {Get-PSwaAuthorizationRule | Remove-PSwaAuthorizationRule -force } -comp chi-web01


The PSWA Gateway will still be running, but no one will be able to use it until we set new rules.

Install a domain certificate


First, we installed PowerShell Web Access using a test certificate for SSL. (see the post “ PowerShell Web Access: Installation Guide ”). I need to reconfigure this web service to use a valid certificate from my domain certificate service. Although IIS can be managed through PowerShell, it’s easier to do this using the IIS graphical management tools. Note: Depending on how you initially set up the web server, you may need to install IIS Management Tools, IIS Management Service and configure the server for remote management.
On server CHI-WEB01, I will install a web server certificate issued by my domain certification authority (CA). You must adapt site bindings to use this certificate. In IIS Manager, I will select a site and edit the bindings.

image

Now I will select https binding and click Edit.

image

In the screenshot above, I selected the CHI-WEB01 certificate I installed. Then open the browser and go to https: //chi-web01/pswa/en-US/logon.aspx . No security warnings appeared (see the post about PSWA testing ).

All the same can be done immediately when configuring the PSWA. Run Install-PswaWebApplicationon the web server and then manually configure the certificate. But you also want to set up an SSL trust certificate for users in your domain.

Create domain rules in PSWA

At the next stage, we create the necessary authorization rules. These rules must be installed on the web server. I will use remoting with Credssp , as the team will need to reconnect (second hop) to access Active Directory.

PS C:\> enter-pssession chi-web01 -Authentication Credssp -Credential globomantics\jeff


The first rule I will create will allow members of the Domain Admins group to access any computer using the Microsoft.PowerShell endpoint.

[chi-web01]: PS C:\> Add-PswaAuthorizationRule -rulename DomainAdmins -usergroupname "globomantics\domain admins" -computername * -configurationname microsoft.powerShell -force


This command will give domain administrators full remote access to PowerShell.
I would also like to give the DBA group access to SQL Server - but only to this server.

[chi-web01]: PS C:\> Add-PswaAuthorizationRule -rulename SQLDBA -usergroupname "globomantics\chicago dba" -computername CHI-DB01 -configurationname microsoft.powerShell -force


The last rule that I create is the pre-established constrained endpoint. This endpoint, on CHI-FP01, will allow users in the Help Desk group to resolve file and folder problems using PowerShell.

[chi-web01]: PS C:\> Add-PswaAuthorizationRule -rulename HelpDesk -usergroupname "globomantics\help desk" -computername CHI-FP01 -configurationname FileMgmt -force


PSWA now has three rules. Take a look at them.

[chi-web01]: PS C:\> get-PswaAuthorizationRule


The conclusion can be seen in the screenshot below.

image

Testing Rules in PowerShell Web Access


When you create a new rule, PSWA will not complain that you used duplicate names, nor will it check any information you “wrote”, unless the user name or group is in Active Directory. There is also no cmdlet to modify existing rules (for example, if you make a mistake), so use Remove-PswaAuthorizationRule to delete, and then recreate the rule.
To test the rules, you can use Test-PswaAuthorizationRule . Specify the username or group and optionally the endpoint configuration name.

[chi-web01]: PS C:\> Test-PswaAuthorizationRule -username "globomantics\jeff" -computer chi-dc02


If a valid rule is found, the output will be as follows:

image

The first two rules are checked. But the last for the limited endpoint (that we created for the needs of the Help Desk) was not checked, since nothing returned. But I can try again, only this time I will clarify the configuration name.

[chi-web01]: PS C:\> Test-PswaAuthorizationRule -username "globomantics\adeco" -computer * -configuration *


The screenshot below shows this rule.

image

However, let me make it clear: all we did now was check for the existence of a rule for a given user or group. It does not check the correctness of entering a specific point, the availability of the server or the existence of sufficient rights for the account. You need to separately (and manually) test all of this using the Enter-PSSession cmdlet . If it works here, it should work in PowerShell Web Access.

PSWA: What next?

Naturally, before you fully work with PowerShell Web Access, you need to work out for some time and read something else. However, if you (or your colleagues) are already using PowerShell remoting, switching to PSWA is not so difficult. For computers in a domain, everything should just work. For everything else, you must deal with the following tasks:
  • Configure the hosts file on devices outside the domain, such as tablets, to allow the use of the server name with PSWA.
  • Install a CA domain certificate as a trusted root certificate authority on devices that are not in a domain.
  • Set up PSWA sharing so you can remotely manage servers from anywhere.
  • Constantly monitor membership in groups that have remote access rights.


But, of course, the actions that need to be taken depend on the specific situation in a particular organization.
PowerShell Web Access can be a very powerful management tool, but in order to become one, you need to spend time setting up domain rules and procedures. Use Test-PswaAuthorization to resolve access problems. And Enter-PSSession can be used to solve other configuration problems.

Read Next