Customize PowerShell Web Access “for yourself”

We are finishing up working with PowerShell Web Access (PSWA) on Windows Server 2012. In it, we will customize it to fit your needs for use in your domain.
In previous posts we looked at the following:

• PSWA installation
• Configuration
• Testing

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 indicate what you can do next. Details under the cut.

Remove test rules

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

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

')
All rules can be removed by submitting 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 can use it until we set new rules.

Install a domain certificate

We first 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 with graphical IIS management tools. Note: Depending on how you initially set up the web server, you may need to install the IIS Management Tools, the IIS Management Service and configure the server for remote management.
On CHI-WEB01, I will install a web server certificate issued by a certificate authority (CA) for my domain. You must adapt site bindings to use this certificate. In IIS Manager, I’ll select a site and edit bindings.



Now I’ll select https binding and click Edit.



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

All the same can be done immediately when configuring PSWA. Run Install-PswaWebApplication on the web server and then manually configure the certificate. But you will also want to set up an SSL certificate trust 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 remote control (remoting) with Credssp , since the team will need to re-connect (second hop) to access Active Directory.

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

The first rule I 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 I create is the pre-established constrained endpoint. This endpoint, on CHI-FP01, will allow users in the Help Desk group to solve problems with files and folders using PowerShell.

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

Now in PSWA there are three rules. Take a look at them.

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

The output can be seen in the screenshot below.

Testing the rules in PowerShell Web Access

When you created a new rule, PSWA will not complain that you used duplicate names, nor would you “check” any information, except the name of a user or group 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 re-create the rule.
To test the rules, you can use the Test-PswaAuthorizationRule . Specify the username or group name 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:



The first two rules are verified. But the latter for a limited endpoint (what we created for the needs of the Help Desk) was not verified, because nothing returned in return. But I can try again, only this time I will specify the configuration name.

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

The screenshot below shows this rule.



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

PSWA: What's next?

Naturally, before you can fully work with PowerShell Web Access, you need to practice for a while and additionally read something. However, if you (or your colleagues) are already using PowerShell remoting, switching to PSWA is not that difficult. For computers in a domain, everything should just work. For everything else, you need to deal with the following tasks:

• Configure the hosts file on non-domain devices, such as tablets, to allow the use of the server name with PSWA.
• Install a CA domain certificate as a trusted root certification authority on non-domain devices.
• Configure PSWA sharing so that you can remotely manage servers from anywhere.
• Constantly monitor membership in groups that have remote access rights.

But, naturally, the actions that need to be taken depend on the specific situation in a particular organization.
PowerShell Web Access can be very powerful management tools, but in order for it 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.