Leverage PowerShell Just Enough Administration for your Helpdesk

[Today's guest post was authored by Dan Cuomo based on a real-world application of JEA]

Hi Folks -- Platforms PFE Dan Cuomo here to talk about one method to enable the use of Just Enough Administration for your helpdesk administrators.

If you're security conscious, you're no doubt in a constant struggle to try and lower the number of administrators on a system. This is a constant battle between good and evil -- you want to enable users to perform their work while at the same time prevent them from gaining too much access where they can break something, or worse, view, delete, or modify sensitive information. One approach to solve this problem is through Just Enough Administration (JEA), a security feature included with PowerShell 5. JEA is one component in a multi-phased approach to securing privileged access.

With JEA, you empower your users to perform specific tasks through PowerShell without providing them elevated rights. You can control the available commands and parameters, validate input for the specified parameters, and have full auditing capabilities with over-the-shoulder transcripts, module logging, and deep script block logging. For a quick visual example, please see our earlier blog post.

This sounds fantastic but there are a couple of challenges preventing adoption:

1. Heterogenous client versions
2. End-user skillset to initiate the connection

Heterogeneous Client Versions

Many environments today choose to allow administrators to perform work-related tasks from their favorite device. This could be a workstation, tablet, or mobile device running Windows, Linux or macOS. This means that members on your team may each have a slightly different experience when making a connection to a server that needs to be managed. Most importantly, however, they are not PowerShell gurus and, as such, are prone to frustration.

In addition, managing all of this can become quite cumbersome; testing different environments and documenting connection procedures is a time consuming and manual process. To avoid having a helpdesk for your helpdesk, a standardized approach is warranted.

End-user skillset to make the connection

Imagine you want to allow helpdesk administrators to create new Active Directory accounts. There are several solutions for this today, each with their own downsides. I've seen anything from group-based delegation to adding a bunch of admins to a domain admins group  *cringe* ...this time around, you choose to create a JEA endpoint that only enables one scenario: creating a new user.

To do this, User1 logs into their workstation with a non-privileged account (e.g. CONTOSO\User1) and are given an "admin" account (e.g. CONTOSO\User1-Admin) for completing their user creation-related activities.

In the upper left corner of the screenshot below, you can see User1 has logged into the workstation. User1 then opens a PowerShell prompt and attempts to connect to the domain controller (DC01) and receives an Access Denied message. CONTOSO\User1 was only granted domain user rights and does not have access to connect to the DC.

"Oh, right! I need to use my admin credentials -- I always do that..." User1 says.

In the next screenshot, User1 stores the admin account credentials into the variable  $UsrAdminCred and reattempts the connection, once again receiving the access denied message.

As a Tier 1 Administrator, User1-Admin should have rights to connect to DC01 through a Tier1 group membership. Frustrated, User1 calls the helpdesk only to find out that the account is in the appropriate Tier1 group.

After considerable delay, User1 searches through the Tier 1 Administrators help manual and realizes that he needs to specify the JEA constrained endpoint provided to all Tier 1 administrators.

User1-Admin now specifies the connection to DC01 using the session configuration we set up for this exact scenario.

To summarize the steps required for a successful connection, User1 must:

1. Open PowerShell
2. Use Enter-PSSession with the  -ComputerName parameter to create a session to another computer
3. Use the  -ConfigurationName parameter to specify the name of the JEA endpoint on the remote computer that CONTOSO\User1-Admin can connect to
4. Use the  -Credential parameter to specify the alternate credentials used to make the connection

If successful, CONTOSO\User1-Admin is now presented with a session that is restricted to the following commands. Note that New-ADUser is the only application command allowed in this session, aside from the 8 default JEA functions.

User1 no doubt makes a number of wrong turns along the way. Multiply this by the number of admins intended to do this work and you'll need that second helpdesk for your helpdesk staff. Let's look at a more user-friendly alternative.

Enter the web-based PowerShell Console

One way to solve both problems outlined above is by using PowerShell Web Access (PSWA). PSWA provides a form-based, SSL certificate secured IIS website that users can sign into and run PowerShell.

Clients can log in from any device on the network that can reach the website using a variety of supported browsers.

In the screenshot below, User1-Admin browsed to the PSWA login page for the helpdesk staff and specifies the necessary login credentials and computer name.

To connect to the custom JEA endpoint, User1 only needs to click the Optional connection settings drop-down and replace the default configuration name (Microsoft.PowerShell) with the one configured for JEA.

To reiterate, CONTOSO\User1-Admin has no administrative rights on DC01. User1-Admin is only allowed to use PSWA to connect to the JEA endpoint on domain controllers. Beyond the web portal itself, PowerShell will again enforce that only Tier 1 Admins can access the JEA endpoint and restrict them to running only the New-ADUser cmdlet.

The screenshots below show that CONTOSO\User1-Admin only belongs to Domain Users and the Tier 1 administration group. The Tier 1 group does not belong to any other privileged groups itself.

After clicking Sign In, CONTOSO\User1-Admin is connected to a remote PowerShell session on DC01 and can use the limited cmdlets shown previously.

From here, JEA operates as it normally would, allowing the New-ADUser cmdlet to perform the user creation on behalf of User1-Admin.

Now you might be asking yourself if you need to go scrolling through IIS logs to identify the connection that somehow correlates that action to...

Let me stop you right there. Since we've enabled PowerShell Script Block and Module logging, when the command is run on DC01, a new event (with ID 4103) is added to the PowerShell operational log. Some of the interesting aspects of that event are:

• CommandInvocation - the command the user ran
• ParameterBinding - any options that were included with that command
• User - the temporary identity (virtual account) used by JEA during that session. Active Directory logs would show this user as being the one who added NewUser01.
• ConnectedUser - the non-privileged account (User1-Admin) that connected to the JEA endpoint and ran the command

That's awesome! How do I get started?

There are a few moving parts to set this all up, but it boils down to the following steps:

1. Create a JEA Role Capability file
   This file defines the capabilities granted to your users and is placed inside a PowerShell module on the machine(s) being managed. In our example above, the role capability file only granted access to the New-ADUser cmdlet.
2. Create the JEA Session Configuration file
   This file defines the parameters for the PowerShell session configuration. For example, a JEA session configuration correlates the users or groups that can use the role capability file for creating new user accounts. It also instructs PowerShell to use a temporary admin account on the machine to execute the commands on behalf of the connecting users.
3. Register the JEA Session Configuration
   The session configuration file is registered on the target node and given a friendly name (JEA_AccountGeneration in our example) which users provide to Enter-PSSession or the PSWA connection info. Session configurations must be registered on each machine that should be manageable through JEA.
4. Install PowerShell Web Access
   Install the PowerShell Web Access feature on a gateway server. In our scenario, this was the server named PSWA01.contoso.com
5. Configure the PowerShell Web Access Gateway
   Configure an IIS web application on PSWA01.
    
   NOTE:  As a best practice, it is recommended that you DO NOT  make the PSWA site accessible outside your company's intranet. Under no circumstance should you expose a direct connection to your domain controllers from the Internet!
6. Configure authorization rules
   This is the only task that changes if you're combining PSWA and JEA. In this step, you add an authorization rule to PSWA allowing a user or group to connect to a computer or group. In our scenario, we also specify the JEA session configuration name configured on the target node (DC01).To set the custom authorization rule, we use Add-PswaAuthorizationRule as shown below. Since we want the users to be able to connect using the custom session configuration, we add the  -ConfigurationName parameter along with the name selected when registering the endpoint in step 3.
7. Lock down the PowerShell Web Access Gateway
   As the central entry point for management of a domain controller, it's important to make sure that the PowerShell Web Access Gateway is properly locked down to prevent malicious users from changing the authorization policies or launching attacks on other machines. Check out our blog on securing jump servers for some tips on how to lock down gateway servers in general and be sure to follow all best practices when configuring the PSWA Gateway.

As previously noted, JEA is one in a multi-phased approach to securing privileged access. JEA does this by reducing the number of elevated rights required to administer systems. In some cases, JEA may be all that you need to enable your helpdesk or other administrators to perform their duties in a more secure manner.

If you're attempting to implement JEA but find yourself struggling due to the hurdles associated with some of the mechanics, combining JEA with PowerShell Web Access can simplify this process for you by providing users with a less error-prone, forms-based mechanism for them to connect to their constrained sessions.

Thanks for reading,

Dan Cuomo

Comments

• Anonymous
  April 24, 2017
  Interesting post, Dan! Thx!
  • Anonymous
    April 25, 2017
    Glad you enjoyed it! Thanks Peter :-)