Compartilhar via

Step by Step: Creating a JEA endpoint for DNS management

  • Artigo

Just Enough Administration (JEA) provides a way for administrators to delegate certain admin tasks to non-administrators using PowerShell. Unlike some of the other built-in delegation solutions in Windows, JEA is not tied to a particular product or service. You can create custom roles in JEA that allow users to manage any software on the system. In this blog post, we'll show you how to create a JEA endpoint for managing a DNS server that is co-located on an Active Directory Domain Controller.

For a quick refresher on JEA and the scenario we're solving for, check out the 6 minute video below.

[embed]https://www.youtube.com/watch?v=xnBrbkY9P20[/embed]

Prerequisites

Before you get started, ensure you have an instance of Windows Server running the Microsoft DNS Server role available to you. We recommend Windows Server 2016, but the same steps apply if you're using Windows Server 2012 or 2012 R2 and have Windows Management Framework 5.1 installed. You will also need a domain administrator account to register the JEA endpoint on the server.

Note: JEA supports Windows Server 2008 R2 as well, but the DNS Server PowerShell module is not available for 2008 R2.

Planning for JEA

Before you can create a JEA endpoint, you need to know two things:

  • Which commands do users need to run on this system?
  • Who are the users that should be able to run those commands?

To determine this information, you should meet with your operations team (DNS admins) and security team to figure out the right balance of convenience and security for your particular organization. The following DNS-related tasks probably come to mind when figuring out what DNS admins need to do:

  • Checking the DNS server state and configuration
  • Creating, Reading, Updating, and Deleting DNS records and forwarders
  • Clearing the DNS server cache
  • Restarting the DNS service
  • Viewing DNS events in the event log

With those tasks clearly defined, you then need to find the PowerShell modules, functions, scripts, and command line executables admins need to use to accomplish the tasks. For the DNS server, these are usually handled by:

  • dnscmd.exe
  • DnsServer PowerShell module
    • Get/Set-DnsServer
    • Add/Get/Set/Remove-DnsServerResourceRecord
    • Add/Get/Set/Remove-DnsServerForwarder
  • net.exe or the Restart-Service PowerShell cmdlet
  • Get-WinEvent

Next, we need to filter the list of commands to remove any potentially dangerous commands. This includes any commands which could give a DNS admin the ability to control things outside of the DNS server on the system and special invocations of seemingly-good commands which could have unintended side effects.

  • net.exe should not be allowed in a JEA session, because it could allow a DNS admin to add themselves to a privileged security group, open up a file share, and more
  • Restart-Service should only allow the DNS admin to restart the DNS Server, not any other services on the machine
  • dnscmd.exe is appropriate for DNS admins, but allows users to both read and change the DNS server configuration. When you allow non-PowerShell programs in a JEA session, users can use any parameters they want, potentially allowing those in a "viewer" role to make changes.
  • Get-WinEvent should only let DNS admins review DNS logs, not arbitrary application event logs. Sensitive information can sometimes be logged, especially on a domain controller, so it is best to limit the DNS admins to only viewing relevant logs to them.

Lastly, we need to consider the various roles a DNS admin may need. Should all users with access to the DNS server be treated as admins, or are there also people who just need to view the configuration or make small changes? For this example, we'll assume there are two types of DNS admins: those who just need read access to the data, and those who can make changes to the DNS server. We'll group the commands under each role, and use those in the next step to create 2 role capability files.

DNS Viewers - need access to the "Get" commands from the DnsServer PowerShell module. They also should be able to review the DNS events in the event log.

DNS Admins - need access to all DnsServer commands, including Add/Set/Remove. Additionally, they should be able to restart the DNS service.

Creating role capability files

Now that we have the list of commands defined, it's time to create JEA roles that represent the set of allowable commands. This is trivial to do using the New-PSRoleCapabilityFile cmdlet. The below lines should be run in an elevated PowerShell prompt on the DNS server. You can also create the role capability files on another computer and copy them to a PowerShell module folder on the DNS server when you are ready to deploy JEA.

[snippet slug=jea-step-by-step-creating-role-capabilities lang=bsh]

These commands will perform the following changes:

  1. Create a new PowerShell module named "JEARoles" in the Program Files directory. You can change this name if you'd like.
  2. Create a RoleCapabilities subdirectory, where Role Capabilities can be found by JEA.
  3. Define a new custom function, called Get-DnsServerLog, which gets the DNS events from the event log.
  4. Create the DnsViewer role capability file, which allows any "Get" command from the DnsServer module as well as the custom Get-DnsServerLog function we defined.
  5. Create the DnsAdmin role capability file, which allows all commands from the DnsServer module as well as Restart-Service (but only for the DNS service).

You can add, remove, or change role capabilities at any time. They just need to be uniquely named and located in a subfolder named "RoleCapabilities" inside a valid PowerShell module.

Creating a session configuration file

After creating your roles, you're ready to define the mapping between users and roles. To complete this step, you'll need to create two security groups: one holding users who should have view-only rights and one for users who should be full DNS admins. We'll also set up transcripts in the session configuration file so that users' actions are logged on the system for review during security audits.

Lastly, we'll register the session configuration on the computer. This will create a new PowerShell endpoint that users can connect to and manage the DNS server. This process will restart WinRM and disconnect any users currently managing the system, so be sure to do this during a scheduled maintenance window.

[snippet slug=jea-step-by-step-creating-session-configuration lang=bsh]

The session configuration file has a few important settings:

  • SessionType determines whether PowerShell should provide all or none of its regular features to users. Since JEA operates under a whitelist model, we use RestrictedRemoteServer to instruct PowerShell to take away all commands except those explicitly permitted by role capabilities. Additionally, the file system, registry, certificate store, and other providers are removed and the PowerShell language is turned off to prevent users from pasting in their own code to bypass JEA restrictions.
  • TranscriptDirectory instructs PowerShell to save a full log of every command a user enters when managing the server with this JEA endpoint to a file in the specified folder. This is particularly useful when you need to audit what users did on a server.
  • RunAsVirtualAccount is what tells JEA to use a temporary, privileged account (virtual account) to execute the commands on the user's behalf. This is how a non-admin is able to run elevated commands.
  • RoleDefinitions specifies the mapping between users/groups and JEA roles. JEA roles are specified by their file name, without the .psrc file extension (DnsViewer and DnsAdmin, in our case). You should ensure role capabilities are named uniquely on your system to avoid conflicts.

Use JEA

Once JEA is registered on the server, you're ready to use it! On another machine, substitute in your server's name and run the following command to enter an interactive PowerShell session using the DnsAdministration endpoint created in the last step.

Enter-PSSession dc01.contoso.com -ConfigurationName DnsAdministration

You will only be able to connect successfully if your user account belongs to the JEA-DNS-Viewers or JEA-DNS-Admins security group. You can then run Get-Command to see the limited set of commands available to you.

Learn more

That's it! Once you figure out who your admins are and what commands they need access to, setting up JEA is straightforward. To learn more about JEA and start creating endpoints for your own environment, check out the JEA documentation and GitHub samples for further inspiration. You can also download the DnsViewer and DnsAdmin role capabilities created in this blog from the GitHub repository.

Comments

  • Anonymous
    December 11, 2018
    The comment has been removed
    • Anonymous
      December 11, 2018
      Absolutely! You can have as many JEA endpoints on a machine as you want. Just create a different session configuration file (and role capability files, if the commands are different) for each endpoint and use unique names when running Register-PSSessionConfiguration. When possible, we like to recommend using role capabilities instead of multiple JEA endpoints to make it easier on your end users to not have to remember each endpoint name, but there are certainly situations where you want to entirely isolate the use cases.
  • Anonymous
    December 16, 2018
    Great job, Ryan! Brief, to the point, and 100% working.