Remote Server Administration with PowerShell

Your RDP Client is going to get straight up jealous

Intro

In the past remote Window’s administration has been limited to RDP, Citrix, DRAC/KVM, VNC, or the command line using PsExec. Developing scripts to remotely connect to hosts and gather data utilizing these legacy technologies became very cumbersome. One of the best things about PowerShell is the ability to manage hosts remotely quickly and efficiently. In a previous post I wrote about Local Server Administration with PowerShell which included quick glances at cmdlets for managing Windows features, firewall administration, network connectivity diagnostic tools, HTTP and HTTPS diagnostic cmdlets, and scheduled job management. The same cmdlets are available remotely; allowing us to configure servers without the need to RDP and executing PowerShell commands locally.

First we need to understand Windows Remote Management (WinRM) as PowerShell uses this technology to remotely connect to servers and other infrastructure. WinRM provides a common way for systems to access and exchange management information across an IT infrastructure. WinRM was introduced with the Windows Vista/Server 2008 kernel and can retroactively be installed in earlier versions by installing Windows Management Framework 2.0.

Security Implications with WinRM

Before implementing PowerShell Remoting it is important to understand the security implications. WinRM, by default, will use the HTTP protocol on port 5985 to communicate with a remote host. Microsoft Negotiate Authentication will decide to authenticate using either Kerberos and NTLM. The preference will be Kerberos, which will be used in the same AD domains or domains with trust relationships.

If you analyze packet captures during the WinRM process over HTTP, and follow the entire TCP stream, you will see that the content is encrypted with the content type of HTTP-SPNEGO-session-encrypted for NTLM v2 and HTTP-Kerberos-session-encrypted for Kerberos. Here is an example of a WinRM session using Kerberos as the local and remote computers were on the same domain:

The actual password is never sent over the wire and the only way that a password could be decoded is if the Security Accounts Manager (SAM) on the remote machine had already been compromised. The hash that is stored in the Security Accounts Manager is never actually sent and cannot be decoded. Even if there was someone snooping packets on the network they wouldn’t see anything in clear text and therefore an exploit is extremely unlikely. With this data we conclude that WinRM is encrypted by default and that configuring WinRM for HTTPS would be an added layer of security.

Configuring PowerShell Remoting

Configuring PowerShell Remoting was originally difficult and time consuming because administrators had to manually create the WinRM listener, set the service to automatically start, enable PowerShell session configurations, and troubleshooting authentication. Now, all of this is configured out of the box; primarily because the majority of new management tools application require this to properly function. Additionally, several cmdlets have a ComputerName parameter that is supported to identify which computer you want to run the command on. Here is how you can enable PowerShell remoting on previous versions of Windows.

Configure PowerShell Remoting with HTTP

Starting in PowerShell 2.0 you can enable PowerShell remoting with a single command:

Enable-PSRemoting

The Enable-PSRemoting cmdlet runs the Set-WSManQuickConfig cmdlet, which performs the following tasks:

• Starts the WinRM service.
• Sets the startup type on the WinRM service to Automatic.
• Creates a listener to accept requests on any IP address.
• Enables a firewall exception for WS-Management communications.
• Registers the Microsoft.PowerShell and Microsoft.PowerShell.Workflow session configurations, if it they are not already registered.
• Registers the Microsoft.PowerShell32 session configuration on 64-bit computers, if it is not already registered.
• Enables all session configurations.
• Changes the security descriptor of all session configurations to allow remote access.
• Restarts the WinRM service to make the preceding changes effective.

Configuring PowerShell Remoting with HTTPS

If you would like this additional layer of security, the process is slightly more complex than the Enable-PSRemoting command. The first thing you need to do is obtain an SSL cert for the remote server or workstation. You can script out the issuing of certificates by using Certificate Enrollment Web Service and Certificate Enrollment Policy Web Service in Windows Server 2012 R2. I would also recommend deploying a duplicate of the Web Server certificate template and modifying the settings to meet your organization’s needs. Here is an example of how you can obtain these certificates using PowerShell.

PS C:\> $uri = “https://yourca.domain.tld/Policy/service.svc”

PS C:\> $fqdn = “remotehost.domain.tld”

PS C:\> $subject = “[email protected], C=US, S=Ohio, L=Dayton, O=DataYard, OU=TechOps,CN=$fqdn”

PS C:\> $netbios = “remotehost”

PS C:\> $creds = Get-Credential

PS C:\> Get-Certificate -Template “WinRM” -Url $uri -DNSName $fqdn,$netbios -CertStoreLocation cert:\LocalMachine\My `

-SubjectName $fqdn `

-Credential $creds

You can issue these commands from the remote host in the same domain. If the certificate request is issued, then the returned certificate is installed in the machine’s personal certificate store. If the request is made pending, then the request is installed in the machine’s request store. Once you have the certificate installed you will need to obtain the certificate thumbprint for the issued certificate and copy it to your clipboard:

PS C:\> $thumbprint = (gci cert:\LocalMachine\My | Where {$_.Subject -eq $subject}).Thumbprint

PS C:\> $thumbprint | clip

In order to create the HTTPS WinRM listener you will have to use a command prompt and not PowerShell as you will receive an error “Error: Invalid use of command line. Type “winrm -?” for help”. In the following example we also delete the default HTTP listener:

C:\> winrm create winrm/config/Listener?Address=*+Transport=HTTPS  @{Hostname=”remotehost.domain.tld”;CertificateThumbprint=”E1ED1974E00A9789DFDD417A690F2C1480FD224A”}

C:\> winrm delete winrm/config/Listener?Address=*+Transport=HTTP

Now that WinRM is actively listening on 5986 we need to modify the firewall rules in PowerShell to reflect our changes. We strongly suggest restricting the remote addresses able to access this service for an additional layer of security:

PS C:\> Get-NetFirewallRule | Where {$_.Name -match “WINRM-HTTP-In-TCP”} | Disable-NetFirewallRule

PS C:\> New-NetFirewallRule -Name “WINRM-HTTPS-In-TCP” -DisplayName “Windows Remote Management (HTTPS-In)” `

-Direction Inbound -Action Allow -Protocol TCP -LocalPort 5986 -RemoteAddress 10.0.0.0/24

Utilizing PowerShell Remoting

Now that we have PowerShell Remoting configured there are several options to remotely connect. These options include the ComputerName parameter, Invoke-Command, PSSession capabilities, and implicit remoting.

ComputerName Parameter

You can run commands on a remote computer by using the ComputerName parameter. Although many cmdlets now offer a ComputerName parameter, there are a limited number of cmdlets with this parameter available. When you use this parameter Windows PowerShell creates a temporary connection that is used for the command and is then closed. Here is an example regarding memory consumption on a remote host:

PS C:\> Get-Process -ComputerName remotehost.domain.tld | sort WorkingSet | select -last 5

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName

——-  ——    —–      —– —–   ——     — ———–

   4658      93   100208     185996   669            3612 OUTLOOK

   1358     130   178744     214380   631           11912 VpxClient

   5917     104   136148     220148   772            5480 OUTLOOK

    463      32   268112     231492   780           10780 javaw

   7114     108   175692     269376   878            3528 OUTLOOK

Here are all of the commands with the ComputerName parameter available:

PS C:\> Get-Command | ForEach { if ($_.Parameters.Keys -Contains “ComputerName”){$_}} | select name

Name

—-

Add-Computer

Clear-EventLog

Connect-PSSession

Enter-PSSession

Get-EventLog

Get-HotFix

Get-Process

Get-PSSession

Get-Service

Get-WmiObject

Invoke-Command

Invoke-WmiMethod

Limit-EventLog

New-EventLog

New-PSSession

Receive-Job

Receive-PSSession

Register-WmiEvent

Remove-Computer

Remove-EventLog

Remove-PSSession

Remove-WmiObject

Rename-Computer

Restart-Computer

Set-Service

Set-WmiInstance

Show-EventLog

Stop-Computer

Test-Connection

Write-EventLog

I primarily utilize the ComputerName parameter for quickly identifying issues with servers in our local domain or dev environments. Since invoking a cmdlet only creates a temporary connection, any time you need to perform several action items on a remote host I would recommend to utilize PowerShell Sessions (PSSessions).

Invoke-Command

Invoke-Command is perhaps the most versatile way to remotely connect to hosts with PowerShell. You can use this command to execute scriptblocks locally, remotely, through a remote session with or without arguments, or through a connection endpoint URI. Invoke-command can also be used to invoke the same scriptblock on several different servers; we can also identify a filepath to predefined scripts to run remotely. You can also use Invoke-Command on a local computer to evaluate or run a string in a script block as a command. Windows PowerShell converts the script block to a command and runs the command immediately in the current scope, instead of just echoing the string at the command line.The Invoke-Command cmdlet runs commands on a local or remote computer and returns all output from the commands, including errors.

Here is an example of grabbing the configured DNS servers on all interfaces for several servers in your domain:

PS C:\> $server1 = “server1.domain.tld”

PS C:\> $server2 = “server2.domain.tld”

PS C:\> $server3 = “server3.domain.tld”

PS C:\> Invoke-Command -ScriptBlock { Get-DNSClientServerAddress } `

>> -ComputerName $server1,$server2,$server3

>>

InterfaceAlias               Interface Address ServerAddresses                                PSComputerName

                             Index     Family

————–               ——— ——- —————                                ————–

Ethernet                            12 IPv4    {192.168.1.101, 192.168.1.102}                 server1.domain.tld

Ethernet                            12 IPv4    {192.168.1.101, 192.168.1.102}                 server2.domain.tld

Ethernet                            12 IPv4    {192.168.1.101, 192.168.1.102}                 server3.domain.tld

PSSession Capabilities

A PSSession is a persistent PowerShell Session on a local or remote computer. Use a PSSession to run multiple commands that share data, such as a function or the value of a variable. Commands are executed inside of a PSSession using the Invoke-Command. Through PowerShell session options and New-PSSession parameters we can connect to a remote machine to perform the vast majority of our actions, and we can develop very elaborate scripts by connecting to and storing persistent PowerShell sessions.

Invoke-Command and PSSessions

Let’s start with the basics of creating a new session, storing it in a variable, and then issuing a command:

PS C:\> $session = New-PSSession remotehost.domain.tld

PS C:\> Invoke-Command -Session $session -ScriptBlock { (Get-NetAdapter).Name }

vEthernet (Internal Ethernet Port Windows Phone Emulator Internal Switch)

vEthernet (Realtek PCIe GBE Family Controller – Virtual Switch)

Production Interface (95)

That is a very basic example of capturing data from a remote host. Here is a little bit more of an advanced example of how we can capture all IPs from a remote host, and create A records on our domain controller (a different remote host) for all the server IPs:

PS C:\> $creds = Get-Credential

PS C:\> $remote_fqdn = “remotehost.domain.tld”

PS C:\> $dc = “domaincontroller.domain.tld”

PS C:\> $session1 = New-PSSession $remote_fqdn -Credential $creds

PS C:\> $session2 = New-PSSession $dc -Credential $creds

PS C:\> $ips = Invoke-Command -Session $session1 -ScriptBlock {

(Get-NetIPAddress | Where {$_.InterfaceAlias -notmatch “Loopback”}).IPAddress

}

PS C:\> $ips

10.0.1.42

10.0.0.42

172.16.2.1

192.168.1.108

192.168.1.105

PS C:\> Invoke-Command -session $session2 -ArgumentList $remote_fqdn,$ips -scriptblock {

param ($remote_fqdn, $ips)

$name = $remote_fqdn.split(“.”)[0]

ForEach ($ip in $ips){

#Add-DnsServerResourceRecordA -ZoneName domain.tld. -Name $name -IPv4Address $ip

$ip

}

}

Enter-PSSession

Persistent PowerShell sessions are great for scripting purposes, but troubleshooting on the fly and utilizing Invoke-Command and ScriptBlocks is not a practical solution. However, with the Enter-PSSession command you can connect interactively to a PowerShell session on any properly configured remote system. The Enter-PSSession cmdlet starts an interactive session with a remote computer. During the session, the commands that you execute run on the remote computer, just as though you had a local PowerShell sesssion on it (one thing to note is that you can have only one interactive session at a time). Here is an example of connecting to a remote computer:

PS C:\> Enter-PSSession remotehost.domain.tld -Credential (Get-Credential)

In the past we had to launch an RDP client, enter in credentials, wait on the user profile and startup programs to load, and launch a PowerShell session. These actions took much longer than Enter-PSSession. The Enter-PSSession cmdlet is my personal favorite for PowerShell remoting because it is a subsitute for remote desktop and decreases the administrative time to connect to remote hosts.

Implicit Remoting

PowerShell remoting gets even better as you can take it one step further and create PowerShell modules from your PowerShell sessions you create. For example, I created modules for managing our corporate exchange servers (Exchange 2013):

PS C:\> $creds = Get-Credential

PS C:\> $uri = “https://exchange.domain.tld/PowerShell”

PS C:\> $exchange = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionURI $uri -Authentication Basic `

-Credential $creds -SessionOption (New-PSSessionOption -NoMachineProfile -SkipCACheck -SkipCNCheck -SkipRevocationCheck)

PS C:\> Export-PSSession -Session $exchange -CommandName * -OutputModule DataYardExchange -AllowClobber

Managing remote infrastructure becomes significantly easier as we build custom modules for our environment. Implicit remoting and PowerShell modules will not store your password(s) and will prompt you accordingly upon importing the module. Here is an example of modifying DataYard’s corporate exchange environment with the module we recently created:

PS C:\> Import-Module DataYardExchange

PS C:\> Set-Mailbox eric.wright -EmailAddresses @{add=”[email protected]”}

PS C:\> (Get-Mailbox eric.wright).EmailAddresses

smtp:[email protected]

smtp:[email protected]

Another way to take advantage of implicit remoting is by utilizing the cmdlet Import-PSSession. Rather than creating a module we can create a PSSession and then use the Import-PSSession cmdlet to implicitly remote to the server:

PS C:\> $creds = Get-Credential

PS C:\> $uri = “https://exchange.domain.tld/PowerShell”

PS C:\> $exchange = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionURI $uri -Authentication Basic `

-Credential $creds -SessionOption (New-PSSessionOption -NoMachineProfile -SkipCACheck -SkipCNCheck -SkipRevocationCheck)

PS C:\> Import-PSSession $exchange

PowerShell Web Access

The last feature to discuss is PowerShell Web Access (WindowsPowerShellWebAccess). This allows you to execute PowerShell commands through an encrypted website from any web browser. PowerShell Web Access can be configured using the following commands:

PS C:\> Install-WindowsFeature -Name WindowsPowerShellWebAccess -IncludeManagementTools

PS C:\> Install-PswaWebApplication -webApplicationName pswa -UseTestCertificate

PS C:\> Add-PswaAuthorizationRule -UserName domain\user -ComputerName localhost -ConfigurationName Microsoft.PowerShell

PS C:\> start iexplore.exe https://localhost/pswa

In your favorite web browser (Chrome, Firefox, Safari, or IE) you can utilize PowerShell Web Access from anywhere in the world. This is a screenshot of PowerShell Web Access from Safari on an iPhone:

 

I strongly suggest to implement additional layers of security by restricting the IP space that is able to access this feature as well as utilizing additional authentication schemes such as Windows Authentication, Basic Authentication, and/or client certificate verification at the IIS level.

Conclusion

There are many ways to connect to and manage remote systems, PowerShell becoming the most consistent way to manage Window’s infrastructure. As you can see the functionality of persistent PSSessions and modules can become very elaborate. Remote management techniques for Windows’ infrastructure has been constantly improving and I look forward to the incremental improvements.