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
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.
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
Comments
- Anonymous
December 04, 2018
Will the WAC reader role work on domain controllers?- Anonymous
December 04, 2018
yes it will
- Anonymous