Windows Server 2019 Automation with PowerShell Cookbook

Chapter 1. Establishing a PowerShell Administrative Environment

In this chapter, we cover the following recipes:

Installing RSAT tools on Windows 10 and Windows Server 2019
Exploring package management
Exploring PowerShellGet and PSGallery
Creating an internal PowerShell repository
Establishing a code-signing environment
Implementing Just Enough Administration

Introduction

Before you can begin to administer your Windows Server 2019 infrastructure, you need to create an environment in which you can use PowerShell to carry out the administration.

The recipes in this chapter focus on setting up a PowerShell administrative environment, which includes getting the tools you need, setting up an internal PowerShell repository, and (for organizations that require a high level of security) creating a code-signing environment. The chapter finishes with setting up JEA to enable users to perform administrative tasks (but only those assigned to the user).

Installing RSAT tools on Window 10 and Windows Server 2019

In order to manage many of the feature of Windows Server 2019, you need to install and use the Windows Remote Server Administration (RSAT) tools. These tools include PowerShell modules, cmdlets, and other objects that enable you to manage the various features as described in this book.

This recipe configures several hosts: a domain controller (DC1), two domain-joined servers (SRV1, SRV2), and a Windows 10 domain-joined client (CL1).

This recipe enables you to use a Windows 10 computer to manage your Windows 2019 servers remotely. As needed, you can also log in to a server using remote desktop tools to carry out any needed administration locally.

Getting ready

This recipe assumes you have set up the VM farm for this book as described in the Preface to the book. In particular, this recipe uses a Windows Server 2019 host running as a domain controller (DC1), a Windows 10 client computer (CL1), plus two domain-joined servers (SRV1, SRV2).

Your client system should be Windows 10 Enterprise or Professional. Once you have installed the operating system, you should customize it with some artifacts used throughout this book, as follows:

#   Set execution Policy
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Force
#   Create Local Foo folder
New-Item C:\Foo -ItemType Directory -Force
#   Create basic profile and populate
New-Item $profile -Force -ErrorAction SilentlyContinue
'# Profile file created by recipe' | OUT-File $profile
'# Profile for $(hostname)'        | OUT-File $profile -Append
''                                 | OUT-File $profile -Append
'#  Set location'                  | OUT-File $profile -Append
'Set-Location -Path C:\Foo'        | OUT-File $profile -Append
''                                 | OUT-File $profile -Append
'# Set an alias'                   | Out-File $Profile -Append
'Set-Alias gh get-help'            | Out-File $Profile -Append
'###  End of profile'              | Out-File $Profile -Append
# Now view profile in Notepad
Notepad $Profile
# And update Help
Update-Help -Force

These steps create the C:\Foo folder, create a profile, and update the PowerShell help information. You can add other customizations to these steps, such as adding VS Code or other third-party modules.

How to do it...

From CL1, get all available PowerShell commands:

$CommandsBeforeRSAT = Get-Command -Module *
$CountBeforeRSAT    = $CommandsBeforeRSAT.Count
"On Host: [$Env:COMPUTERNAME]"
"Commands available before RSAT installed: [$CountBeforeRSAT]"

Examine the types of command returned by Get-Command:

$CommandsBeforeRSAT | Get-Member |
  Select-Object -ExpandProperty TypeName -Unique

Get the collection of PowerShell modules and a count of modules before adding the RSAT tools:

$ModulesBeforeRSAT = Get-Module -ListAvailable
$CountOfModulesBeforeRSAT = $ModulesBeforeRSAT.Count
"$CountOfModulesBeforeRSAT modules installed prior to adding RSAT"

Get the Windows Client Version and Hardware Platform:

$Key      = 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
$CliVer   = (Get-ItemProperty -Path $Key).ReleaseId
$Platform = $ENV:PROCESSOR_ARCHITECTURE
"Windows Client Version : $CliVer"
"Hardware Platform      : $Platform"

Create a URL for the download file—note this recipe only works for 1709 and 1803:

$LP1 = 'https://download.microsoft.com/download/1/D/8/' +
       '1D8B5022-5477-4B9A-8104-6A71FF9D98AB/'
$Lp180364 = 'WindowsTH-RSAT_WS_1803-x64.msu'
$Lp170964 = 'WindowsTH-RSAT_WS_1709-x64.msu'
$Lp180332 = 'WindowsTH-RSAT_WS_1803-x86.msu'
$Lp170932 = 'WindowsTH-RSAT_WS_1709-x86.msu'
If     ($CliVer -eq 1803 -and $Platform -eq 'AMD64') {
  $DLPath = $Lp1 + $lp180364}
ELSEIf ($CliVer -eq 1709 -and $Platform -eq 'AMD64') {
  $DLPath = $Lp1 + $lp170964}
ElseIf ($CliVer -eq 1803 -and $Platform -eq 'X86')   {
  $DLPath = $Lp1 + $lp180332}
ElseIf ($CliVer -eq 1709 -and $platform -eq 'x86')   {
  $DLPath = $Lp1 + $lp170932}
Else {"Version $Cliver - unknown"; return}

Display what is to be downloaded:

"RSAT MSU file to be downloaded:"
$DLPath

Use BITS to download the file:

$DLFile = 'C:\foo\Rsat.msu'
Start-BitsTransfer -Source $DLPath -Destination $DLFile

Check the download's Authenticode signature:

$Authenticatefile = Get-AuthenticodeSignature $DLFile
If ($Authenticatefile.status -NE "Valid")
  {'File downloaded fails Authenticode check'}
Else
  {'Downloaded file passes Authenticode check'}

Install the RSAT tools:

$WsusArguments = $DLFile + " /quiet"
'Installing RSAT for Windows 10 - Please Wait...'
$Path = 'C:\Windows\System32\wusa.exe'
Start-Process -FilePath $Path -ArgumentList $WsusArguments -Wait

Now that RSAT features are installed, see what commands are available on the client:

$CommandsAfterRSAT = Get-Command -Module *
$COHT1 = @{
  ReferenceObject  = $CommandsBeforeRSAT
  DifferenceObject = $CommandsAfterRSAT
}
# NB: This is quite slow
$DiffC = Compare-Object @COHT1
"$($DiffC.Count) Commands added with RSAT"

Check how many modules are now available on CL1:

$ModulesAfterRSAT        = Get-Module -ListAvailable
$CountOfModulesAfterRsat = $ModulesAfterRSAT.Count
$COHT2 = @{
  ReferenceObject  = $ModulesBeforeRSAT
  DifferenceObject = $ModulesAfterRSAT
}
$DiffM = Compare-Object @COHT2
"$($DiffM.Count) Modules added with RSAT to CL1"
"$CountOfModulesAfterRsat modules now available on CL1"

Display modules added to CL1:
```
"$($DiffM.Count) modules added With RSAT tools to CL1"
$DiffM | Format-Table InputObject -HideTableHeaders
```
That completes adding the RSAT tools to the client; now we add the tools to SRV1 and look at comparisons with tools on other servers via CL1.

Get details of the features and tools loaded on DC1, SRV1, and SRV2:

$FSB1 = {Get-WindowsFeature}
$FSRV1B = Invoke-Command -ComputerName SRV1 -ScriptBlock $FSB1
$FSRV2B = Invoke-Command -ComputerName SRV2 -ScriptBlock $FSB1
$FDC1B  = Invoke-Command -ComputerName DC1  -ScriptBlock $FSB1
$IFSrv1B = $FSRV1B | Where-object installed
$IFSrv2B = $SRV2B  | Where-Object installed
$IFDC1B  = $FDC1B  | Where-Object installed
$RFSrv1B = $FeaturesSRV1B |
              Where-Object Installed |
                Where-Object Name -Match 'RSAT'
$RFSSrv2B = $FeaturesSRV2B |
              Where-Object Installed |
                Where-Object Name -Match 'RSAT'
$RFSDC1B = $FeaturesDC1B |
             Where-Object Installed |
               Where-Object Name -Match 'RSAT'

Display details of the tools installed on each server:

'Before Installation of RSAT tools on DC1, SRV1'
"$($IFDC1B.Count) features installed on DC1"
"$($RFSDC1B.Count) RSAT features installed on DC1"
"$($IFSrv1B.Count) features installed on SRV1"
"$($RFSrv1B.Count) RSAT features installed on SRV1"
"$($IFSrv2B.Count) features installed on SRV2"
"$($RFSSRV2B.Count) RSAT features installed on SRV2"

Add the RSAT tools to the SRV2 server.

$InstallSB = {
  Get-WindowsFeature -Name *RSAT* | Install-WindowsFeature
}
$I = Invoke-Command -ComputerName SRV1 -ScriptBlock $InstallSB
$I
If ($I.RestartNeeded -eq 'Yes') {
  'Restarting SRV1'
  Restart-Computer -ComputerName SRV1 -Force -Wait -For PowerShell
}

Get details of RSAT tools on SRV1 vs SRV2:

$FSB2 = {Get-WindowsFeature}
$FSRV1A = Invoke-Command -ComputerName SRV1 -ScriptBlock $FSB2
$FSRV2A = Invoke-Command -ComputerName SRV2 -ScriptBlock $FSB2
$IFSrv1A = $FSRV1A | Where-Object Installed
$IFSrv2A = $FSRV2A | Where-Object Installed
$RSFSrv1A = $FSRV1A | Where-Object Installed |
              Where-Object Name -Match 'RSAT'
$RFSSrv2A = $FSRV2A | Where-Object Installed |
              Where-Object Name -Match 'RSAT'

Display after results:

"After Installation of RSAT tools on SRV1"
"$($IFSRV1A.Count) features installed on SRV1"
"$($RSFSrv1A.Count) RSAT features installed on SRV1"
"$($IFSRV2A.Count) features installed on SRV2"
"$($RFSSRV2A.Count) RSAT features installed on SRV2"

How it works...

This recipe installs the RSAT tools on both a Windows 10 domain-joined computer (CL1) and on several Windows 2019 servers. The recipe also displays the results of the installation. You begin, in step 1, by getting all the commands available on the Windows 10 host and display a count.

Depending on the specific version of Windows 10 you use and what tools you may have already added to the client, the counts may be different. Here is what the output of this step looks like:

In step 5, you create a URL for downloading the RSAT tools. Different versions exist for different hardware platforms (for example, x86 and amd64) and for major Windows 10 versions (1709 and 1803). In step 6, you display the URL, which looks like this:

In step 12, you display the modules that were added to CL1, which looks like this:

There's more...

In step 1, you saw that there were 1528 commands loaded on CL1 while in step 4 you saw that you had 77 modules on your system. PowerShell gets commands primarily from modules, although older PowerShell snap-ins also contain cmdlets. If you wish to use a command contained in a snap-in, you have to load the snap-in explicitly by using Add-PSSnapin. PowerShell can only auto-load commands found in modules.

In step 4 and step 5, you calculate and display a URL to download the RSAT tools. These recipe steps work for two versions of Windows 10 and for two hardware platforms. The URLs and versions of Windows 10 available may have changed by the time you read this. Also, the recipe caters just for Windows 10 versions 1709 and 1803. Download files for earlier versions are not available in the same way as for later versions. And for versions later than 1893, the mechanism may change again.

In step 15, when you displayed the results of adding features to SRV1, the output looked different if the formatting had been done on the server. On the server, PowerShell is able to display XML that states how to format output from WindowsFeature cmdlets. Windows 10 does not display XML, hence the list output in this step.

Exploring package management

The PackageMangement PowerShell module implements a provider interface that software package management systems use to manage software packages. You can use the cmdlets in the PackageMangement module to work with a variety of package management systems. You can think of this module as providing an API to package management providers such as PowerShellGet, discussed in the Exploring PowerShellGet and PowerShell Gallery recipe.

The key function of the PackageMangement module is to manage the set of software repositories in which package management tools can search, obtain, install, and remove packages. The module enables you to discover and utilize software packages from a variety of sources (and potentially varying in quality).

This recipe explores the PackageManagement module from SRV1.

Getting ready

This recipe uses SRV1—a domain-joined server that you partially configured in the Installing RSAT Tools on Windows 10 and Windows Server 2019 recipe.

How to do it...

Review the cmdlets in the PackageManagement module:
```
Get-Command -Module PackageManagement
```

Review the installed providers with Get-PackageProvider:

Get-PackageProvider |
  Format-Table -Property Name,
                         Version,
                         SupportedFileExtensions,
                         FromtrustedSource

Get details of a packages loaded on SRV1 of the MSU type (representing Microsoft Updates downloaded by Windows Update):
```
Get-Package -ProviderName 'msu' |
  Select-Object -ExpandProperty Name
```
Get details of the NuGet provider, which provides access to developer library packages. This step also loads the NuGet provider if it is not already installed:
```
Get-PackageProvider -Name NuGet -ForceBootstrap
```

Display the other package providers available on SRV1:

Find-PackageProvider |
  Select-Object -Property Name,Summary |
    Format-Table -Wrap -AutoSize

Chocolatey is a popular repository for Windows administrators and power users. You have to install the provider before you can use it, as follows:
```
Install-PackageProvider -Name Chocolatey -Force
```

Verify that the Chocolatey provider is now available:

Get-PackageProvider | Select-Object -Property Name,Version

Display the packages now available in Chocolatey:

$Packages = Find-Package -ProviderName Chocolatey
"$($Packages.Count) packages available from Chocolatey"

How it works...

In step 1, you review the cmdlets contained in the PackageManagement module, which looks like this:

In step 5, you search for additional package providers, like this:

There's more...

In step 6, you installed the Chocolatey package provider. To see more details about what Install-PackageProvider is doing, run this step with the -Verbose flag.

Exploring PowerShellGet and the PSGallery

PowerShellGet is a module that enables you to work with external repositories. A repository is a site, either on the internet or internally, that hosts software packages. You use the cmdlets in this module to access one or more repositories that enable you to find, download, and use third-party packages from a package repository.

PowerShellGet leverages mainly the PSGallery repository. This repository, often referred to as a repo, is sponsored by Microsoft and contains a wealth of PowerShell functionalities, including PowerShell modules, DSC resources, PowerShell scripts, and so on. Many of the recipes in this book utilize PSGallery resources.

To some extent, the PowerShellGet module is similar to tools in the Linux world such as apt-get in Ubuntu or RPM in Red Hat Linux.

The PowerShellGet module implements a number of additional *-Module cmdlets that extend the module management cmdlets provided in the Microsoft.PowerShell.Core module.

It's simple and easy to find and install modules from the PSGallery. In some cases, you may wish to download the module to a separate folder. This would allow you to inspect the module, loading it manually before putting it into a folder in $env:PSModulePath (where commands might be auto-loaded).

Getting ready

This recipe runs on the SRV1 server. The recipe also assumes you have performed the previous recipes in this chapter. In particular, you should have added the latest version of the NuGet package provider to your system. If you have not already done so, ensure the provider is installed by performing the following:

Install-PackageProvider -Name NuGet -ForceBootstrap

How to do it...

Review the commands available in the PowerShellGet module:
```
Get-Command -Module PowerShellGet
```

View the NuGet package provider version:

Get-PackageProvider -Name NuGet |
    Select-Object -Property Version

View the current version of PowerShellGet:

Get-Module -Name PowerShellGet -ListAvailable

Install the PowerShellGet module from PSGallery:
```
Install-Module -Name PowerShellGet -Force
```

Check the version of PowerShellGet:

Get-Module -Name PowerShellGet -ListAvailable

View the default PSGallery repositories currently available to PowerShell:
```
Get-PSRepository
```

Review the package providers in the PSGallery repository:

Find-PackageProvider -Source PSGallery |
  Select-Object -Property Name, Summary |
    Format-Table -Wrap -autosize

Use the Get-Command cmdlet to find Find-* cmdlets in the PowerShellGet module:
```
Get-Command -Module PowerShellGet -Verb Find
```

Get the commands in the PowerShellGet module:

$Commands     = Find-Command -Module PowerShellGet
$CommandCount = $Commands.Count

Get the modules included:

$Modules     = Find-Module -Name *
$ModuleCount = $Modules.Count

Get the DSC resources available in the PSGallery repository:

$DSCResources      = Find-DSCResource
$DSCResourcesCount = $DSCResources.Count

Display the counts:

"$CommandCount commands available in PowerShellGet"
"$DSCResourcesCount DSCResources available in PowerShell Gallery"
"$ModuleCount Modules available in the PowerShell Gallery"

Install the TreeSize module. As this is a public repository, Windows does not trust it by default, so you must approve installation or use -Force:
```
Install-Module -Name TreeSize -Force
```

Review and test the commands in the module:

Get-Command -Module TreeSize
Get-Help Get-TreeSize
Get-TreeSize -Path C:\Windows\System32\Drivers -Depth 1

Uninstall the module:
Uninstall-Module -Name TreeSize

To inspect prior to installing, first create a download folder:

$NIHT = @{
  ItemType = 'Directory'
  Path     = "$env:HOMEDRIVE\DownloadedModules"
}
New-Item @NIHT

Save the module to the folder:

$Path = "$env:HOMEDRIVE\DownloadedModules"
Save-Module -Name TreeSize -Path $Path
Get-ChildItem -Path $Path -Recurse | format-Table Fullname

To test the downloaded TreeSize module, import it:

$ModuleFolder = "$env:HOMEDRIVE\downloadedModules\TreeSize"
  Get-ChildItem -Path $ModuleFolder -Filter *.psm1 -Recurse |
    Select-Object -ExpandProperty FullName -First 1 |
      Import-Module -Verbose

How it works...

This recipe uses the cmdlets in the PowerShellGet module to demonstrate how you can obtain and leverage modules and other PowerShell resources from the public PSGallery site (https://www.powershellgallery.com/).

In step 1, you review the commands contained in the PowerShellGet module, which looks like this:

In step 6, you examine the repositories PowerShell knows about (thus far), like this:

In step 13, you install the TreeSize module from the PSGallery, which generates no output. In step 14, you look at the commands contained in the module (there is only one), then you run the command, which looks like this:

https://github.com/PowerShell/PowerShellGet.

In step 4, you added the latest version of the PowerShellGet module onto your system and in step 5, you saw you now had two versions. PowerShell, by default, uses the later version, unless you explicitly load an earlier version prior to using the commands in the module.

In this recipe, you downloaded, used, and removed the TreeSize module—one of thousands of modules you can freely download and use. Other popular modules in the PSGallery include:

Azure modules (including MSOnline): Azure provides a large number of smaller modules and most of these are frequently downloaded
PowerShellGet and PackageManagement
PSWindowsUpdate
PSSlack
IISAdministration
SQLServer
CredentialManager
Posh-SSH

Creating an internal PowerShell repository

Public galleries such as PSGallery are great sources of interesting and useful modules. You can also create your own PowerShell repository for either personal or corporate use.

There are several ways to set up an internal repository, for example using a third-party tool such as ProGet from Inedo (see https://inedo.com/ for details on ProGet). The simplest way is to set up an SMB file share and use the Register-PSRepository command to set up the repository. Once set up, you can use the Publish-Module command to upload modules to your new repository and then use the repository to distribute organizational modules.

Getting ready

This recipe runs on the SRV1 server.

How to do it...

Create the repository folder:

$LPATH = 'C:\RKRepo'
New-Item -Path $LPATH -ItemType Directory

Share the folder:

$SMBHT = @{
  Name        = 'RKRepo'
  Path        = $LPATH
  Description = 'Reskit Repository'
  FullAccess  = 'Everyone'
}
New-SmbShare @SMBHT

Create the repository and configure it as trusted:

$Path = '\\SRV1\RKRepo'
$REPOHT = @{
  Name               = 'RKRepo'
  SourceLocation     = $Path
  PublishLocation    = $Path
  InstallationPolicy = 'Trusted'
}
Register-PSRepository @REPOHT

View the configured repositories:
```
Get-PSRepository
```

Create a Hello World module folder:

New-Item C:\HW -ItemType Directory | Out-Null

Create a very simple module:

$HS = @"
Function Get-HelloWorld {'Hello World'}
Set-Alias GHW Get-HelloWorld
"@
$HS | Out-File C:\HW\HW.psm1

Load and test the module:
```
Import-Module -Name c:\hw -verbose
GHW
```

Create a module manifest for the new module:

$NMHT = @{
  Path              = 'C:\HW\HW.psd1'
  RootModule        = 'HW.psm1'
  Description       = 'Hello World module'
  Author            = '[email protected]'
  FunctionsToExport = 'Get-HelloWorld'
}

Publish the module to the RKRepo:

Publish-Module -Path C:\HW -Repository RKRepo

View the results of publishing the module:
```
Find-Module -Repository RKRepo
```
Look at what is in the C:\RKRepo folder:
```
Get-ChildItem -Path C:\RKRepo
```

How it works...

You begin this recipe, in step 1, by creating the folder you are going to use to hold your repository, in this case C:\RKRepo, as follows:

Although the module works as-is, you need a manifest in order to publish the module. In step 8, you create a very simple module manifest and store it in the module folder. In step 9, you publish the module. None of these three steps produce any output.

With the module published, in step 10 you can use Find-Module to discover what is in the repository, like this:

There's more...

In step 2, you create a share that allows everyone full access to the repository. In a corporate environment, you should review the access to the repository. Perhaps you should give authenticated users read access, and grant write access to a smaller group of administrators.

As you can see in step 11, a PowerShellGet repository is just a file share that holds NuGet packages. One approach might be to keep your module source in your source code repository and publish it to the internal PowerShellGet repository as needed.

Establishing a code-signing environment

In some environments, it can be important to know that a program or PowerShell script has not been modified since it was released. You can achieve this with PowerShell scripts by digitally signing the script and by enforcing an execution policy of AllSigned or RemoteSigned.

After you digitally sign your script, you can detect whether any changes were made in the script since it was signed. Using PowerShell's execution policy, you can force PowerShell to test the script to ensure the digital signature is still valid and to only run scripts that succeed. You can set PowerShell to do this either for all scripts (you set the execution policy to AllSigned) or only for scripts you downloaded from a remote site (you set the execution policy to RemoteSigned).

One thing to remember—even if you have the execution policy set to AllSigned, it's trivial to run any non-signed script. Simply bring the script into PowerShell's ISE, select all the text in the script, then run that selected script. And using the Unblock-File cmdlet allows you to, in effect, turn a remote script into a local one.

Signing a script is simple once you have a digital certificate issued by a Certificate Authority. You have three options for getting an appropriate certificate:

Use a well-known public Certificate Authority such as Digicert (see https://www.digicert.com/code-signing) for details of their code-signing certificates).
Use an internal CA and obtain the certificate from your organization's CA.
Use a self-signed certificate.

Public certificates are useful but are generally not free. You can easily set up your own CA, or used self-signed certificates. Self-signed certificates are great for testing out signing scripts and then using them. All three of these methods can give you a certificate that you can use to sign PowerShell scripts.

Getting ready

Run this recipe on the Windows 10 client (CL1) you used in the earlier Installing RSAT Tools on Windows 10 and Server 2019 recipe.

How to do it...

Create a code-signing, self-signed certificate:

$CHT = @{
  Subject           = 'Reskit Code Signing'
  Type              = 'CodeSigning'
  CertStoreLocation = 'Cert:\CurrentUser\My'
}
$Cert = New-SelfSignedCertificate @CHT

View the newly created certificate:

Get-ChildItem -Path Cert:\CurrentUser\my -CodeSigningCert |
  Where-Object {$_.Subjectname.Name -match $CHT.Subject}

Create a simple script:

$Script = @"
  # Sample Script
  'Hello World!'
  Hostname
"@
$Script | Out-File -FilePath C:\Foo\signed.ps1
Get-ChildItem -Path C:\Foo\signed.ps1

Sign the script:

$SHT = @{
  Certificate = $Cert
  FilePath    = 'C:\Foo\signed.ps1'
}
Set-AuthenticodeSignature @SHT -Verbose

Look at the script after signing:
```
Get-ChildItem -Path C:\Foo\signed.ps1
```

Test the signature:

Get-AuthenticodeSignature -FilePath C:\Foo\signed.ps1 |
  Format-List

Ensure the certificate is trusted:

$DestStoreName  = 'Root'
$DestStoreScope = 'CurrentUser'
$Type = 'System.Security.Cryptography.X509Certificates.X509Store'
$MHT = @{
  TypeName = $Type 
  ArgumentList  = ($DestStoreName, $DestStoreScope)
}
$DestStore = New-Object  @MHT
$DestStore.Open(
  [System.Security.Cryptography.X509Certificates.OpenFlags]::
    ReadWrite)
$DestStore.Add($cert)
$DestStore.Close()

Re-sign with a trusted certificate:

Set-AuthenticodeSignature @SHT | Out-Null

Check the script's signature:

Get-AuthenticodeSignature -FilePath C:\Foo\signed.ps1 |
  Format-List

How it works...

In step 1, you create a self-signed code-signing certificate which you store in the current user's personal certificate store (also known as Cert:\CurrentUser\My). Since you store the certificate in $Cert, there is no output from this step. In step 2, you examine the code-signing certificates in the current user's personal certificate store, like this:

In step 6, you test the script to validate the signature, like this:

https://www.globalsign.com/en/blog/the-importance-of-code-signing-redux for some thoughts on the importance of code signing in general.

Whether or not you deploy code signing, it's useful to know how to do it.

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 role RKDnsAdmins 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 called RKDnsAdmins.
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 the RKDnsAdmins 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 the RKDnsAdmins 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              = '[email protected]'
  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-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 as JerryG:
```
Invoke-Command -ScriptBlock $SB1 @ICMHT
```

Get the DNSServer commands in the JEA session that are available to JerryG:

$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:

In step 12, you calculate how many DNS commands are available within an RKDNSAdmins JEA session, 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.

Page 1 of 8

Bronson Magnan Mar 26, 2019

This book is the single resource to take an intermediate PowerShell user and supercharge their career into a Professional Windows Server Administer. You will learn how to work with remote management environments, custom repositories, package management, code-signing, JEA (Just Enough Administration), IP Address, DHCP, and DNS management, AD management, File share automation, DFS management, WSUS management, practical Container operations, IIS Administration, DSC (Desired State Configuration), Hyper-V management, Performance monitoring, Event logs, and some Azure, all with PowerShell. Even if you are a veteran PowerShell expert with Windows Server, you will learn some new ways to do things with Windows Server 2019.

Amazon Verified review

Amazon Kunde Jul 22, 2020

Sehr gut!

ColMike May 21, 2019

Don't pass this book up, seriously! From soup to nuts, Thomas gives you the recipes to excel in the world of Powershell and automation. If you're not automating your server tasks on ANY version of Windows server, you're at least 15+ years behind the times. I was doing it with PERL in the early 2000s and doing it now with Powershell. Thomas gives you the tools to be ahead of your peers when it comes to Powershell. I knew this would be a great asset to have in my toolbox because I also have his Windows Server 2016 Cookbook.

Jesse Mar 04, 2021

Good book if you like powershell comands this is a great book.

shawn dunham Mar 14, 2020

Enjoyed this book. Recommend for beginners-intermediate experience.

Windows Server 2019 Automation with PowerShell Cookbook: Powerful ways to automate and manage Windows administrative tasks , Third Edition

What do you get with eBook?

Contact Details

Billing Address

Introduction

Installing RSAT tools on Window 10 and Windows Server 2019

Getting ready

How to do it...

How it works...

There's more...

Exploring package management

Getting ready

How to do it...

How it works...

There's more...

Exploring PowerShellGet and the PSGallery

Getting ready

How to do it...

How it works...

See also…

Creating an internal PowerShell repository

Getting ready

How to do it...

How it works...

There's more...

Establishing a code-signing environment

Getting ready

How to do it...

How it works...

Implementing Just Enough Administration

Getting ready

How to do it...

How it works...

There's more...

See also

Page 1 of 8

Key benefits

Description

Who is this book for?

What you will learn

Product Details

What do you get with eBook?

Contact Details

Billing Address

Product Details

Packt Subscriptions

Frequently bought together

Table of Contents

Recommendations for you

Customer reviews

People who bought this also bought

About the author

FAQs

Create a Free Account To Continue Reading

Sign in to activate your 7-day free access