Remote Management with PowerShell (Part 2)

If you would like to read the other parts in this article series please go to:

• Using PowerShell to Manage AD and AD Users
• Remote Management with PowerShell (Part 1)

Introduction

Remoting is really the secret sauce of Windows PowerShell. In a previous article, we had the opportunity to show how centralized management can be immensely more effective with script remoting.

This article reviews the challenges of remoting for network administrators, including managing non-domain computers in an acceptable security context, delegating credentials across multiple hops, and implicit remoting. There may be times when you urgently need to access your network or data center from a remote location and you don’t even have a laptop or desktop computer available. Don’t panic, we have you covered.

Managing Non-Domain Computers

When you make a connection, by default, remoting delegates your logon credentials to the remote computer. The remote computer uses those credentials to impersonate you, executing the commands on your behalf. As you can imagine, there are security risks involved when delegating your credentials to a remote server. For instance, if a malicious user was able to successfully impersonate a known remote computer, you could possibly turn in your credentials to that impostor, who could use them against you and other people in the network.

To minimize this risk, remoting by default requires mutual authentication. The two-way authentication process forces a client to prove its identity to a server and the server to prove its identity to the client. Mutual authentication is a native feature of the Active Directory Kerberos protocol, and it is used by remoting between trusted domains computers.

However, when managing non-domain computers, you cannot count on Active Directory to handle mutual authentication. For those cases, you either have to provide another form of mutual authentication using SSL certificates (this is the recommended approach) or add the remote computer to your local TrustedHosts list. In both cases, the –Credential parameter is needed with the remoting command when making the connection. We’ll explain both options next.

Using Remoting with SSL Certificates

When authentication relies on digital certificates, internal or external certification authorities (CA) are a crucial component of the authentication process. The certificate installed on the remote computer must come from a trusted CA and bear the same name that you will use when making the connection. Even though IIS is not needed for this configuration to work, ensure that you install a web server certificate in the remote computer certificate store.

When you remote by using HTTPS, the whole connection is encrypted by using the encryption keys of the target computer’s SSL certificate; that means you could use the Basic Authentication protocol and the password would still be protected. Using MakeCert.exe to generate a self-sign certificate is not recommended in a production environment.

For our demonstration, a certificate signed by an internal CA has been installed in a workgroup server named Server1. Let’s see how it works.

1. To verify that the computer is in a workgroup and that a certificate is installed in the computer store. Enter:

Get-CimInstance –ClassName Win32_ComputerSystem

Get-ChildItem –Path Cert:\LocalMachine\My

Figure 1

2. To set up the WinRM HTTPS listener, you need to write down or copy the certificate thumbprint from the previous output. Then run this code:

Figure 2

Let’s review the parameter used with New-WSManInstance:

Address = ‘*’ the service will listen on all available IP addresses.

Transport = HTTPS. The other option is HTTP.

Hostname = Must match the name of the host on the certificate.

CertificateThumbprint = This is the thumbprint exposed with the Get-ChildItem cmdlet.

3. Configure the firewall to allow HTTPS traffic on port 5986. Enter:

Figure 3

4. Start a remoting session to test the HTTPS listener. Run:

Figure 4

After entering the password, the remote session prompt is displayed, confirming a successful HTTPS connection.

Figure 5

Adding the Remote Computer to Your Local TrustedHosts List

One-time warning here: This option turns off the requirement for mutual authentication, which increases the risk of an attacker wreaking havoc on your network by spoofing or impersonating the target connection.

The TrustedHosts list can be configured locally or by using group policy. It lists the computers for which mutual authentication is not required (again a security hazard). Computers may be listed by their name, DNS alias, or IP address; wildcards (*) are permitted. Once a computer is added to your local TrustedHosts list, you are allowed to send your credential to that remote computer without a process in place to verify that the computer on the other end is the one you intended to connect to.

Let’s configure a TrustedHosts list on a Windows client computer named Win81A.

1. First, to verify that the TrustedHosts list is empty, run:

Figure 6

2. To add a computer name CoreG2 to the TrustedHosts list, enter:

The names or IP addresses you enter here, must be the same ones that are used when remoting. For example, you cannot enter an IP address and then try to connect using the computer name.

Figure 7

3. To validate the configuration, run this again:

Figure 8

4. Let’s check that CoreG2 is in a workgroup. Enter: 

Figure 9

5. To test the connection enter:

Figure 10

The previous screen confirms that the TrustedHosts list is properly configured and we are able to remote into a non-domain computer.

Multi-Hop Remoting

For remoting to work, your credentials must be delegated to the target computer. Once you are connected, by default you are not allowed to initiate another connection from that target computer into another server. because credentials can be delegated across one connection or hop only. In other words, credentials cannot be chain-delegated a second time.

In order to overcome this default limitation, you must configure group policy or set up both ends of the connection as follows:

1. On the computer from which you are connecting from, run the following command:

The target computer name can be a * wildcard or a limited wildcard such as *.lanztek.local.

2. On the computer that you are connecting to, run the same cmdlet but assigning a different role. (This is the computer to which you are delegating your credentials.)

Implicit Remoting

Installing specialized client software on their desktop computers is one way many IT personnel perform remote administration of network services and applications; using remote desktop is another option. Implicit remoting offers a different approach that is lighter than remote desktop sessions and saves you the aggravation of installing and maintaining client applications on your workstation. Implicit remoting allows you to create shortcuts on your local computer to PowerShell commands on a remote server. The commands you enter locally are implicitly run on the server through remoting and the results are transmitted back to you.

Let’s demonstrate implicit remoting by connecting from a Windows 8 client named Win81A to a domain controller named FS1.

1. On Win81A PowerShell console, create a persistent connection to FS1 and store it in a variable, enter:

Figure 11

2. To display a list of modules on FS1, run:

Figure 12

3. To import the Active Directory module from FS1, enter:

Figure 13

4. To find out how many AD commands are now available on the local computer, enter:

Figure 14

These commands will be available as long you keep the PSsession open with the remote computer.

Let’s test implicit remoting by searching for computer accounts in the directory. Enter:

Figure 15

Remoting Output Serialization

When you run commands on a remote computer, as in the previous Active Directory demonstration, that computer serializes the results in XML format, and transmits that XML text back to your computer. The serialization procedure deals only with the properties of the object, which means static information. The XML received by the local computer is deserialized back into objects that are put into the Windows PowerShell pipeline. However, the deserialized objects have no methods or events. Think of any data that is received through remoting as a static snapshot. You cannot perform any action to change or update those objects. This is important to know, because you may want to do as much processing as possible on the remote computer where you are working with live objects that have methods and events.

Windows PowerShell Web Access

This feature allows you to run Windows PowerShell commands and scripts from a web browser without using any special plug-in or having PowerShell installed on the client computer. As long as you have a compliant browser, it is possible to make connections from a tablet or smart phone.

On the Windows server, besides adding the Windows Power web access feature, you must install Windows PowerShell 3.0 or a newer version, the web server (IIS) role, and .NET Framework 4.5. An SSL certificate is also required to secure the connections. It is possible to create a self-signed certificate during the configuration process, but that should be used for testing purposes only. In production, a valid SSL certificate, signed by a trusted certification authority (CA) is highly recommended.

Let’s review the steps to install and configure the PowerShell web access feature:

1. Install the Windows PowerShell Web Access feature. At the PowerShell prompt, enter the following command:

Figure 16

2. Set up the web access gateway. You can perform this task with either the IIS Manager or PowerShell. The Install-PswaWebApplication cmdlet allows you to set up the Windows PowerShell Web Access web application within the IIS default web site. Running this cmdlet creates the web access gateway with the following URL: https://<server_name>/pswa.

You can change the name of the web application or install it on a different website. Also using the-UseTestCertificate parameter creates a test certificate and configures the gateway to use the certificate for HTTPS requests. For our demo, running Install-PswaWebApplication is enough, as a valid certificate has been installed on the server already.

Figure 17

3. Configure authorization rules:

Access to the website is not permitted until authorization rules are configured to define the users and groups that will be allowed to use the Windows PowerShell gateway, and which computers these users and groups can connect to. To add an authorization rule, type the following:

Figure 18

Once you run the previous command, the domain administrator can access any computer in the network and connect to any available PowerShell session configuration using an Internet browser. The target computer must be configured to allow remoting and only authorized users on that computer will be granted access. The Test-PswaAuthorizationRule cmdlet can validate whether a rule exists for a specified user, computer or endpoint.

Verify Windows PowerShell Web Access configuration

The browser on the client side must allow cookies and support JavaScript. Once you open the sign-in page, in our case https://Server1/pswa, you can connect directly to the gateway, to another computer in the network, or to a custom URI. See the sign-in page below.

Figure 19

By default, the same credentials you enter to cross the gateway are also presented to the remote computer that you are connecting to. However, you can expand the Optional Connection Settings section and specify different credentials. This option comes in handy when the account authorized to connect to the gateway does not have permissions to access the target computer.

After completing the credentials and connection settings, click Sign In to connect to the remote computer. Now you have a Windows PowerShell console running in a web browser.

Figure 20

On Windows Server 2012 R2, the Windows PowerShell Web Access gateway allows users to open multiple connections to remote computers in different browser tabs.

Figure 21

Even though the web-based PowerShell console provides a level of functionality very similar to Windows PowerShell remoting, there are some limitations. For instance, some shortcut keys are not supported, such as Ctrl+C to interrupt command execution, or any of the function keys (F1, F2, F3, F7, etc.) related to command history.

To exit the web-based PowerShell console, click Save or Exit in the lower right corner. To sign out without saving your Windows PowerShell Web Access session, just click Exit. Clicking Save saves and closes your current session. When you sign in to the gateway again, Windows PowerShell Web Access displays all of your saved sessions; at that point, you either select and reconnect to a saved session, or start a new session, as shown below.

Figure 22

Let’s take advantage of the web-based PowerShell console to create a network share on a remote computer name FS1. Enter:

Figure 23

To verify the permissions, run

Figure 24

Closing Remarks

This article shows that it is possible to use PowerShell beyond the protective Active Directory boundaries and still provide a strong level of security. Using an internet browser to remote into a server means that you do not need to have a Windows computer to perform remote administration with PowerShell. Actually, you don’t need a computer, as using a tablet or smart phone with a compliant browser will suffice. Remoting takes the Windows PowerShell automating functionality to the next level. Having the capability to perform complex tasks on hundreds or thousands of computers in a very short period of time is a priceless blessing for any network administrator.

If you would like to read the other parts in this article series please go to:

• Using PowerShell to Manage AD and AD Users
• Remote Management with PowerShell (Part 1)