Implementing Just Enough Administration
Just Enough Administration, also known as JEA, is a security framework providing you with the ability to implement fine-grained administrative delegation. With JEA, you enable a user to have just enough administrative power to do their job, and no more. JEA is a more secure alternative to just adding users to the Domain Administrator or Enterprise Administrator groups.
With JEA, you could enable a domain user to access your domain controllers for the purposes of administering the DNS Service on the server. With JEA, you constrain what the user can do on the protected server. For example, you could allow the user to stop and start the DNS Service (using Stop-Service
and Start-Service
) but no other services.
JEA makes use of a number of objects:
- JEA role capabilities file (
.psrc
): This file defines a role in terms of its capabilities. The JEA roleRKDnsAdmins
is allowed access to a limited set of cmdlets on the Domain Controller (those related to the role of administering DNS). - JEA Role module: This is a simple module that holds the JEA role capabilities file within the module's
RoleCapabilities
folder. The module could be calledRKDnsAdmins
. - JEA session configuration file (
.pssc
): This file defines a JEA session in terms of who is allowed access to the session and what they can do in the session. You could allow anyone in theRKDnsAdmins
domain security group to access the server using the JEA endpoint. The session configuration file defines the actions allowed within the JEA session by reference to the role capabilities file. The JEA protected session can only be used by certain people who can do whatever the role capabilities file dictates.
Once you have these files and the module in place, you register the JEA endpoint to the server (and test the configuration).
Once the JEA endpoint is registered, a user who is a member of the domain security group called RKDnsAdmins
can use Invoke-Command
or Enter-PssSession
, specifying the remote server and the JEA-protected endpoint to access the protected server. Once inside the session, the user can only do what the role capabilities file allows.
The following diagram shows the key components of JEA:
Getting ready
Before you use the recipe, you need to create the domain accounts and groups that you use in this recipe. This includes a user (JerryG
) and a security group (RKDnsAdmins
) which contains the user, with both of these under an Organizational Unit (IT
). You installed the RSAT tools in the Installing RSAT Tools on Windows 10 recipe on CL1
—so you can run this step on either CL1
or on DC1
. Creating these AD objects looks like this:
# Create an IT OU $DomainRoot = 'DC=Reskit,DC=Org' New-ADOrganizationalUnit -Name IT -Path $DomainRoot # Create a user - JerryG in the OU $OURoot = "OU=IT,$DomainRoot" $PW = 'Pa$$w0rd' $PWSS = ConvertTo-SecureString -String $PW -AsPlainText -Force $NUHT = @{Name = 'Jerry Garcia' SamAccountName = 'JerryG' AccountPassword = $PWSS Enabled = $true PasswordNeverExpires = $true ChangePasswordAtLogon = $false Path = $OURoot } New-ADUser @NUHT # Create ReskitDNSAdmins security universal group in the OU $NGHT = @{ Name = 'RKDnsAdmins ' Path = $OURoot GroupScope = 'Universal' Description = 'RKnsAdmins group for JEA' } New-ADGroup -Name RKDnsAdmins -Path $OURoot -GroupScope Universal # Add JerryG to the ReskitAdmin's group Add-ADGroupMember -Identity 'RKDNSADMINS' -Members 'JerryG' # Create JEA Transcripts folder New-Item -Path C:\foo\JEATranscripts -ItemType Directory
How to do it...
- On
DC1
, create a new folder for theRKDnsAdmins
JEA module:$PF = $env:Programfiles $CP = 'WindowsPowerShell\Modules\RKDnsAdmins' $ModPath = Join-Path -Path $PF -ChildPath $CP New-Item -Path $ModPath -ItemType Directory | Out-Null
- Define and create a JEA role capabilities file:
$RCHT = @{ Path = 'C:\Foo\RKDnsAdmins.psrc' Author = 'Reskit Administration' CompanyName = 'Reskit.Org' Description = 'Defines RKDnsAdmins role capabilities' AliasDefinition = @{name='gh';value='Get-Help'} ModulesToImport = 'Microsoft.PowerShell.Core','DnsServer' VisibleCmdlets = ("Restart-Service", @{ Name = "Restart-Computer"; Parameters = @{Name = "ComputerName"} ValidateSet = 'DC1, DC2'}, 'DNSSERVER\*') VisibleExternalCommands = ('C:\Windows\System32\whoami.exe') VisibleFunctions = 'Get-HW' FunctionDefinitions = @{ Name = 'Get-HW' Scriptblock = {'Hello JEA World'}} } # End of Hash Table New-PSRoleCapabilityFile @RCHT
- Create the module manifest in the module folder:
$P = Join-Path -Path $ModPath -ChildPath 'RKDnsAdmins.psd1' New-ModuleManifest -Path $P -RootModule 'RKDNSAdmins.psm1'
- Create the role capabilities folder and copy the role configuration file into the module folder:
$RCF = Join-Path -Path $ModPath -ChildPath 'RoleCapabilities' New-Item -ItemType Directory $RCF Copy-Item -Path $RCHT.Path -Destination $RCF -Force
- Create a JEA session configuration file:
$P = 'C:\Foo\RKDnsAdmins.pssc' $RDHT = @{ 'Reskit\RKDnsAdmins' = @{RoleCapabilities = 'RKDnsAdmins'} } $PSCHT= @{ Author = 'DoctorDNS@Gmail.Com' Description = 'Session Definition for RKDnsAdmins' SessionType = 'RestrictedRemoteServer' Path = $P RunAsVirtualAccount = $true TranscriptDirectory = 'C:\Foo\JEATranscripts' RoleDefinitions = $RDHT } New-PSSessionConfigurationFile @PSCHT
- Test the JEA session configuration file:
Test-PSSessionConfigurationFile -Path C:\foo\RKDnsAdmins.pssc
- Register the JEA session definition:
Register-PSSessionConfiguration -Path C:\foo\RKDnsAdmins.pssc -Name 'RKDnsAdmins' -Force
- Check what the user can do with configurations like this:
Get-PSSessionCapability -ConfigurationName rkdnsadmins -Username 'reskit\jerryg'
- Create credentials for the user
JerryG
:$U = 'Reskit\JerryG' $P = ConvertTo-SecureString 'Pa$$w0rd' -AsPlainText -Force $Cred = New-Object System.Management.Automation.PSCredential $U,$P
- Define two script blocks and an invocation hash table:
$SB1 = {Get-HW} $SB2 = {Get-Command -Name '*-DNSSERVER*'} $ICMHT = @{ ComputerName = 'LocalHost' Credential = $Cred ConfigurationName = 'RKDnsAdmins' }
- Invoke the JEA defined function (
Get-HW
) in a JEA session and do it asJerryG
:Invoke-Command -ScriptBlock $SB1 @ICMHT
- Get the
DNSServer
commands in the JEA session that are available toJerryG
:$C = Invoke-command -ScriptBlock $SB2 @ICMHT | Measure-Object "$($C.Count) DNS commands available"
- Examine the contents of the JEA transcripts folder:
Get-ChildItem -Path $PSCHT.TranscriptDirectory
- Examine a transcript:
Get-ChildItem -Path $PSCHT.TranscriptDirectory | Select -First 1 | Get-Content
How it works...
This recipe sets up a JEA endpoint on DC1
and then uses that to demonstrate how JEA works. The recipe relies on a user (JerryG)
, who is a member of a group (RKDnsAdmins
) in the IT organizational unit within the Reskit.Org
domain. The recipe provides the user with the commands necessary to do the job of a DNS administrator, and no more.
In step 1, you create a temporary folder on DC1
that is to hold the role capabilities file, which you define in step 2. In step 3, you create a module manifest in the module folder. Then, in step 4, you create a folder for the Role Capacities folder inside the module and copy the previously created .PSRC
file into this new folder. In step 5, you create the JEA session configuration file. There is no output from these five steps.
In step 6, you test the session configuration file, as shown here:
This step returns a value of True
, which means the session configuration file can be used to create a JEA session.
With all the prerequisites in place, in step 7 you register the JEA endpoint, like this:
In step 8, you check to see what commands (including aliases, functions, cmdlets, and applications) a user would have if they used this JEA endpoint. Because the role capabilities folder was set up to enable the user to have access to all the DNS server commands, there are a large number of DNS cmdlets available which are not shown simply to conserve space, like this:
The final task is to discover what a user can do in a JEA session. In step 9, you create a credential object for the JerryG
user and in step 10 you define hash tables for later use. These two steps produce no output.
In step 11, you invoke a script block that invokes the JEA-defined function Get-HW
, which looks like this:
In step 12, you calculate how many DNS commands are available within an RKDNSAdmins
JEA session, like this:
In step 13, you examine the contents of the JEA transcripts folder, which you defined as part of the session configuration file (for example in step 5). You can see the two transcripts created in response to the two calls to Invoke-Command
(in step 11 and step 12), like this:
In step 14, you examine the contents of the first transcript (a result of step 11). In the transcript header, you can see that user RESKIT\JerryG
remoted in as a virtual RunAs
user using the RKDnsAdmins
JEA endpoint on DC1
. In the body of the transcript, you can see the call to the Get-HW
function and the response. This transcript looks like this:
If you compare this output with the output of step 11, you can see that the transcript is a more detailed examination of precisely what happened in the remote JEA session.
There's more...
The DNSServer
module, which the recipe gives the RDDnsAdmins
JEA endpoint access to, includes three aliases. Since these aliases are not explicitly allowed in the role capabilities file, they are not available in the JEA session.
In this recipe, you used Invoke-Command
to run two simple script blocks in a JEA session. Once you have JEA set up on DC1
(or any other server for that matter), you can enter a JEA session like this:
# Enter a JEA session and see what you can do $ICMHT = @{ ComputerName = 'Localhost' Credential = $Cred # Reskit\JerryG ConfigurationName = 'RKDnsAdmins' } Enter-PSSession @ICMHT
Once in the remoting session, you can explore what commands are available to the JerryG
user.
See also
In this recipe, you examined the transcripts generated by each remoting session. In addition to transcripts, PowerShell also logs the use of a JEA endpoint in the event log. For more information on event log entries and the general topic of auditing and reporting on JEA, see: https://docs.microsoft.com/en-us/powershell/jea/audit-and-report.
In this recipe, you used some of the key lock-down features provided by JEA. But there is more! For a fuller look at the things you can do with JEA and how to go about them, look at the JEA documentation beginning at: https://docs.microsoft.com/en-us/powershell/jea/overview.