Part 2: Configure Just Enough Admin to Manage Domain Joined Servers from Windows Admin Center

Part 1, covered setting up Windows Admin Center (WAC) as a gateway on Server Core. (Click here to read.)  This particular topic is a fun topic and one that I talk to Admins about frequently,  “How can I give someone enough rights to view logs, restart services, etc.. without having to give Administrator rights on a server?” is a question I get all the time.  This is something that is difficult to do in Windows, easier to set up in PowerShell using JEA, and because the Windows Admin Center is built on top of PowerShell it is possible to leverage the same capability.  To make this even better the WAC Product group created the JEA and DSC configuration files needed to do this out of the box.  This post is going to outline the steps on how to set JEA using instructions already published  and combined with my lessons learned.

Apply role-based access control to a single machine

Role-based access control

Enable Kerberos Delegation to Use Windows Admin Center

Because a gateway is being used, Kerberos Delegation has to be enabled in order to connect to a remote server that an account does not have built-in\Admin rights to. This cmdlet will query all of the non Domain Controllers that are online and will set up delegation to the gateway server.  In large organizations multiple gateways can be used and populated.

 $gateway = "WACGATEWAYSERVER"
 $gatewayObject = Get-ADComputer -Identity $gateway
 Get-adcomputer -filter {operatingsystem -like "*server*" -and iscriticalsystemobject -ne $true} `
      -properties ipv4address  | where {(!($_.ipv4address -eq $null))} | `
         Set-ADComputer -PrincipalsAllowedToDelegateToAccount $gatewayObject

Create Domain Groups to Delegate Rights to

Decided to leverage domain groups instead of local groups as its easier to manage the domain groups. *as long as it doesn’t get out of control

Start by creating three new groups in Active Directory.

• ServerWACAdmins
• ServerWACHypervAdmins (only if managing Hyper-v servers)
• ServerWACReaders

 New-ADGroup -GroupScope Global -Name "ServerWACAdmins" -path "OU=Groups,OU=Tier 1,OU=Admin,DC=contoso,DC=com"
 New-ADGroup -GroupScope Global -Name "ServerWACHyperVAdmins" -path "OU=Groups,OU=Tier 1,OU=Admin,DC=contoso,DC=com"
 New-ADGroup -GroupScope Global -Name "ServerWACReaders" -path "OU=Groups,OU=Tier 1,OU=Admin,DC=contoso,DC=com"

Set up JEA

Download the role based access control configuration package from the Windows Admin Center Gateway.

 #change this to preferred location
 $path = $env:temp
 $WindowsAdminCenterGateway = 'https://windowsadmincenter.contoso.com'
 Invoke-RestMethod -Uri "$WindowsAdminCenterGateway/api/nodes/all/features/jea/endpoint/export" `
     -Method POST -UseDefaultCredentials -OutFile "$path\WindowsAdminCenter_RBAC.zip"
 #validate the file exist
 test-path  "$path\WindowsAdminCenter_RBAC.zip"

Expand the zip file, and copy to the required locations.

 #change this to your preferred location
 $wacpath = "$env:temp\wac"
 #Expand the zip file to the directory of choice
 Expand-Archive -Path "$path\WindowsAdminCenter_RBAC.zip" -DestinationPath $wacpath -Force
  
 dir $wacpath
 cd $wacpath
  
 #copy modules to one of PowerShell's default Module locations
 copy "$wacpath\JustEnoughAdministration" -Destination "C:\Program Files\WindowsPowerShell\Modules\" -Recurse
 Get-ChildItem "$wacpath\Modules\" | copy -Destination "C:\Program Files\WindowsPowerShell\Modules\" -Recurse

Modify the InstallJeaFeature.ps1 File

Run: psedit .\InstallJeaFeature.ps1 or notepad .\InstallJeaFeature.ps1to open the file.

In the file scroll down until you see the 3 Group Resources and remove them.

Remove the 3 Group Resources from the JeaEndpoint Depends on section.

Update the JEAEndPoint RoleDefinition:

• '$env:COMPUTERNAME\Windows Admin Center Administrators' change to 'contoso\ServerWACAdmins'
• '$env:COMPUTERNAME\Windows Admin Center Hyper-V Administrators' change to 'contoso\ServerWACHyperVAdmins'
• '$env:COMPUTERNAME\Windows Admin Center Readers' change to 'contoso\ServerWACReaders'

Next this code needs to be copied to the bottom of the installJeaFeature.ps1 script.

 Copy-Item "$PSScriptRoot\JustEnoughAdministration" "$env:ProgramFiles\WindowsPowerShell\Modules" -Recurse -Force
 $ConfigData = @{
     AllNodes = @()
     ModuleBasePath = @{
         Source = "$PSScriptRoot\Modules"
         Destination = "$env:ProgramFiles\WindowsPowerShell\Modules"
     }
 }
 InstallJeaFeature -ConfigurationData $ConfigData | Out-Null
 Start-DscConfiguration -Path "$PSScriptRoot\InstallJeaFeature" -JobName "Installing JEA for Windows Admin Center" -Force

Save and Close the file

Deploy the JEA files to multiple Servers

Copy the modules and script to the machines that need to be managed. The files need to go into the following locations:

• .\JustEnoughAdministration\* to C:\Program Files\WindowsPowerShell\Modules
• .\Modules\* to C:\Program Files\WindowsPowerShell\Modules
• .\InstallJeaFeature.ps1 to .\temp\wac\

This will copy the files to the right location on all domain joined Windows Servers.  I opted to copy the files to two locations on each machine.

 $wacpath = "$env:temp\wac"
 #if the activedirectory module is installed this will copy files out to Windows machines
 #change the filter or add a scopebase to only copy to select machines.
 Get-adcomputer -filter {operatingsystem -like "*server*" -and iscriticalsystemobject -ne $true} `
      -properties ipv4address -PipelineVariable computer | where {(!($_.ipv4address -eq $null))} | foreach{
         if(Test-Connection -ComputerName ($_).dnshostname -Quiet -Count 1){
         $session = New-PSSession -ComputerName ($_).dnshostname -ErrorAction Stop
         Copy-Item -Path "$wacpath\JustEnoughAdministration\" `
             -Destination "$env:temp\WAC\" `
             -ToSession $session -Recurse -Force
         Copy-Item -Path "$path\JustEnoughAdministration\" `
             -Destination "$env:ProgramFiles\WindowsPowerShell\Modules" `
             -ToSession $session -Recurse -Force
         Copy-Item -Path "$wacpath\InstallJeaFeature.ps1" `
             -Destination "$env:temp\WAC\InstallJeaFeature.ps1" -ToSession $session -Recurse -Force
         Get-ChildItem "$wacpath\Modules\" | Copy-Item `
             -Destination "$env:temp\WAC\Modules\" `
             -ToSession $session -Recurse -Force
         Get-ChildItem "$wacpath\Modules\" | Copy-Item `
             -Destination "$env:ProgramFiles\WindowsPowerShell\Modules" `
             -ToSession $session -Recurse -Force
         Disconnect-PSSession $session
     }
 }

From one of the servers login with same account used to copy the files onto the server.

Run .\InstallJeaFeature.ps1 on each machine.

 set-location $env:temp\wac 
 .\InstallJeaFeature.ps1

or add the invoke-command to the copy script used above.

Afterwards confirm DSC was applied and the RestrictedRemoteServer was set up:

 Get-dscconfigurationstatus

 Get-PSSessionConfiguration | Where-Object { $_.SessionType -eq 'RestrictedRemoteServer' }

Time to Test

In Active Directory I created three user accounts and added them to one of the groups:

• WACTest1 - Domain Admins, Built-in Administrator
• WACTest2 - member of ServerWACAdmins and Windows Admin Center Access
• WACTest3 - member of ServerWACReaders and Windows Admin Center Access

On one of the servers running the following cmdlet will display what rights to functions, cmdlets, aliases each account will have.

 Get-PSSessionCapability -ConfigurationName 'Microsoft.Sme.PowerShell' -Username 'CONTOSO\WACTEST1'
 Get-PSSessionCapability -ConfigurationName 'Microsoft.Sme.PowerShell' -Username 'CONTOSO\WACTEST2'
 Get-PSSessionCapability -ConfigurationName 'Microsoft.Sme.PowerShell' -Username 'CONTOSO\WACTEST3'

Here is a consolidated view of the number of cmdlets/functions WACTest2 and WACTest3 have rights to. WACTest1 doesn’t have JEA applied so it has rights to everything.

WACTest2

WACTest3

With each one of the accounts logged into a client machine, connect to Windows Admin Center and note the differences, Here was my experience.

WACTest1 - Notes:

• This account is a full admin on the server, I am able to view every extension available and do everything as expected.

WACTest2 – Notes:

• This account is only a Domain User and Assigned to the ServerWACAdmins Group
• Missing the PowerShell and Remote Desktop Extension
• Unable to restart the computer.
• Able to stop and start Services, change Network settings, kill Processes, create Registry Keys, View Logs, etc as expected

WACTest3 – Notes:

• This account is only a Domain User and Assigned to the ServerWACReaders Group
• Missing the PowerShell and Remote Desktop Extension
• Unable to restart the computer, change Network settings,change registry entries or kill Processes.
• Able to view state of all major components (example Network, Services, or Registry )
• Was able to create a folder in system32 but unable to upload any files into it..

Whenever something is attempted the user doesn’t have rights to perform a red box appears in the top right corner notifying that the action was blocked.

Auditing Windows Admin Center Activity

One last thing to cover as part of this blog is the auditing for when something is successful or blocked. Here what was found.

Auditing and Reporting on JEA

Use event logging in Windows Admin Center to gain insight into management activities and track gateway usage

With the ServerWACReader member account (WACTest3) tried to stop w32time service, with no luck (Expected).

In the Microsoft-Windows-PowerShell Event Log.

Event 4103 was really the only thing useful. This only shows that User was logged in and ran the function.

In the Security Logs the following events are in sequence

#1 4624 An account was successfully logged on.

#2 4717 System security access was granted to an account.

#3 4648 A logon was attempted using explicit credentials.

#4 4624 "WinRM VA_343_CORP_WACTEST3" - An account was successfully logged on.

#5 4672 Special privileges assigned to new logon.

#6 4688 A new process has been created.

Enabled PowerShell Transcripts via GPO to see if this gave anymore insight. The answer is no, it only records the cmdlets that successfully ran. Since the user isn't able to run the cmdlet only the get cmdlet events exist.

Next, With the ServerWACAdmins member account (WACTest2) account. Stopped w32time Service.

Found the following in PowerShell transaction logs

In the Microsoft-Windows-PowerShell Event Log.

Found event 4103, this shows the final cmdlet that was run.

And found event 4104

In regards to the the PowerShell transaction logging, one thing that was observed is each click of the mouse or refresh when enabled results in a new file. This directory grows quickly.

That is all that I have for this post Stay tuned for Part 3.

- Chad