In the first part, we had a quick look at Just Enough Administration (JEA) and discussed some use cases. In this part, we are going to implement a JEA example to solve a common problem we have had for years: assigning appropriate rights to DNS admins.
Follow me:

Anil Erduran

Anil Erduran is a principal consultant and subject matter expert for Hitachi Data Systems EMEA, based in London, UK. He is also a dual category Microsoft Most Valuable Professional in Cloud and Datacenter Management and Microsoft Azure. Anil can be found on Twitter @anil_erduran.
Follow me:

Latest posts by Anil Erduran (see all)

I’m sure that the majority of DNS implementations in Windows environments are co-located with Active Directory domain controllers. That brings a lot of flexibility when it comes to DNS management, troubleshooting, integrated zones, and secure replication. But it’s also quite difficult to separate Active Directory and DNS management layers. In most cases, our domain administrators are also responsible for DNS. The main reason for this is that to have separate DNS admins, you need to grant "Domain Admin" rights to them.

But in some environments governed by strict regulations, you may want to have DNS operators who are responsible for just clearing your DNS cache, restarting the DNS service, or doing maintenance on your DNS zones.

In this case, JEA helps you to provide appropriate rights to your DNS admins without giving them full Active Directory access.

In this blog, we will create JEA configuration/session files and make sure that our non-admin DNS operators group can run just a few PowerShell DNS cmdlets with limited scope.

Before starting to implement JEA in your infrastructure, it’s important to check its requirements, including supported operating systems. As of today, the following operating systems support JEA:

  • Windows Server 2016 Technical Preview 4 and higher
  • Windows Server 2012 R2, 2012, and 2008 R2* with Windows Management Framework 5.0 installed
  • Windows 10 with the November Update (1511) installed
  • Windows 8.1, 8, and 7* with Windows Management Framework 5.0 installed

As JEA leverages PowerShell remoting under the hood, you need to make sure that PowerShell Remote is enabled on target machines:

Detailed planning is crucial for JEA implementation, as you might end up with bunch of configuration files, capabilities, and endpoints configured. We have some limited reporting capabilities about which we will talk next, but it’s recommended to plan your users, groups, and configuration files upfront for each endpoint.

In my case, I would like to provide limited DNS cmdlets and functionality to my DNS operators group. So I quickly created:

  • One domain local group called "JEA_NonAdmin_DNSOperator"
  • One user called "OperatorUser"

and added this user to the "JEA_NonAdmin_DNSOperator" group:

I will use this non-admin group and user in my endpoint configuration settings. It is important here that the user and group have "no permission" at all on my Active Directory and DNS server. They will leverage a "VirtualAccount" in a JEA session.

As we discussed in the first part, our Role Capability files should be created inside a "RoleCapabilities" folder inside a valid PowerShell module so that they can be resolved once the session starts. Therefore, I created a new folder called Demo_Module in the default PowerShell Modules directory. Then I added a module manifest with the .psd1 extension to host metadata for this module. Finally, I added a new directory under the new module called RoleCapabilities. This folder will host my Role Capability files.

A Role Capability file briefly defines what an admin or user can do at the endpoint. In a Role Capability file, you can define:

  • Modules to import
  • Visible aliases
  • Available cmdlets
  • Available functions
  • External commands to make visible when applied to a session
  • Scripts to run when applied to a session
  • Assemblies to load when applied to a session

In our case, I simply defined some parameters such as author, description, company name, and visible cmdlets. Visible cmdlet is the most important one, as it lists all available cmdlets that will be visible when an admin connects to an endpoint. I defined a couple of basic DNS PowerShell cmdlets here.

Lastly, I’m creating a new .psrc file using these defined parameters.

You can see the content of the .psrc file below.

I would like to make a quick change for the visible cmdlets. My first defined cmdlet was Restart-Service. But this command can be run for each and every service in the local machine. I will make an exception here and restrict this command’s name parameter to be run only for "DNS."

Change the line below:

to this line:

That’s a great example that shows the power of JEA. By using JEA, you are not only limiting available cmdlets or functions but you can also restrict parameters for each cmdlet. Another example would be to restrict the -targetcomputer parameter for other cmdlets to make sure that this command can only be run on a particular server.

The next step is to create a new session configuration file. Session configuration is a file with the .pssc extension that defines who can connect to an endpoint. Within the .pssc file, you can configure users, groups, virtual accounts (one-time privileged accounts), and policies.

Here is the content of the session configuration file I created:

There are a couple of important points here:

  • A SessionType of RestrictedRemoteServer is a JEA property that creates a minimal mode environment with a couple of default cmdlets. With this setting, you will find yourself in a session that exposes only the Get-Command, Get-FormatData, Select-Object, Get-Help, Measure-Object, Exit-PSSession, Clear-Host, and Out-Default You can add additional commands to that session using a capability file.
  • RoleDefinition is the parameter that assigns our role capabilities for a non-admin group. Our non-admin group is JEA_NonAdmin_DNSOperator. We assigned this group to the "DNSRoleCapability" file we created earlier.
  • TranscriptDirectory enables PowerShell transcripts. Each and every action you take on this session will be recorded under the specified directory. We will take a look this file in the next part.
  • VirtualAccount is another important property. As I mentioned at the beginning of this blog, my operator group and user have no admin access on DNS or DC servers. By default, VirtualAccount is a member of a built-in administrators group on the target server. For each remote session, a new VirtualAccount will be created and leveraged to take action on behalf of our non-admin user. This way, we can use dummy users to take admin-level actions without having any administrative rights.

The last thing we need to do is register our new session configuration.

Register session configuration

Register session configuration

Now let’s test JEA in action. I’ll retrieve the credentials of OperatorUser using the Get-Credential cmdlet.

Operator user credentials

Operator user credentials

The next step is to start a new PSSession to my target computer (DC in my case), providing configuration name along with non-admin credentials.

Enter PSSession for domain controller

Enter PSSession for domain controller

Now we are in a remote interactive PowerShell session under the OperatorUser security context. Let’s try to list all available commands in that session.

Listing available commands in a JEA Session

Listing available commands in a JEA Session

Figure 4. Listing available commands in a JEA Session

As you see, there are some functions that come along with "RestrictedMode" by default and also with my additional cmdlets that are defined in the Role Capability file. In this case, I can only run these commands and nothing more. I’m restricted in this session with limited cmdlets and functionality.

I can’t even use the restart-service cmdlet for current local services. For instance, if I try to restart the Active Directory service, I will receive an error that indicates that NTDS is not an acceptable argument for this command.

Restricted cmdlets in JEA session

Restricted cmdlets in JEA session

JEA is a great way to restrict the access of your admins in your infrastructure. There are many more use cases in which you can leverage JEA, such as: service provider scenarios in which tenants can delegate restricted access to virtualization admins, first-level troubleshooting tasks for which you can give access to a particular resource on the target machine, and maintenance tasks for which you can grant specific permissions to operators to start and stop services, apply updates, or restart servers.

In the next part, we will quickly cover logging and reporting capabilities in JEA.

Win the monthly 4sysops member prize for IT pros


Related Posts


Leave a reply

Your email address will not be published. Required fields are marked *



Please ask IT administration questions in the forum. Any other messages are welcome.

© 4sysops 2006 - 2018

Log in with your credentials


Forgot your details?

Create Account