Remotely Managing Windows Endpoints Part I: Domain/Hybrid Joined Hosts

After a number of conversations with Adam Gross in Discord voice on WinAdmins about this topic, which initially started on Twitter a while back, I finally decided to lab up some WinRM scenarios involving domain/hybrid/AAD joined devices and wanted to put together something documenting the configurations. I realized that there a few settings that I have taken for granted that others may not realize how they work, and I also wanted to explain how I have secured remote management of Windows endpoints from an identity-based access perspective in the past. Finally, I learned some things when I got to AAD-joined devices (more on that in part II).

I only plan on covering configuring and securing Windows Remote Management (WinRM) traffic in these posts, but the same concepts can be applied to other common remote management protocols such as RDP, SMB, WMI/RPC, etc.

• Configuring WinRM
• Testing WinRM
• Securing WinRM Further
• Testing the New Configuration
• Conclusion

Configuring WinRM

First things first: Using the winrm quickconfig command should be reserved for one-off testing/configuration. We want to manage devices at scale and running a command like that doesn’t scale easily when there are better tools at our disposal. Let’s configure a basic GPO to enable and secure WinRM.

The above image shows a basic WinRM service configuration applied to the endpoints in my lab. I am strictly allowing only the necessary authentication methods (Kerberos and Negotiate), blocking unencrypted traffic, and configuring the IPv4/IPv6 filters to “*”. This particular setting is one I’ve seen people trip up on. This is NOT controlling what IP addresses are allowed to connect, but rather what IP addresses the WinRM service will listen and accept connections on. By using “*”, the WinRM service will accept connections on any interface.

Next, we want to configure the WinRM client settings. In the above image, I’ve configured the authentication methods to match what I use service-side (Kerberos and Negotiate only), as well as blocking unencrypted traffic.

Trusted Hosts is set to disabled here, because we want to ensure mutual authentication of all WinRM connections. Since all of the endpoints in question at this point are AD or Hybrid AAD joined, they can perform mutual Kerberos authentication before allowing a connection to succeed. We’ll be revisiting this in part II.

One additional note about the authentication methods. We need to enable both Negotiate and Kerberos, even though our end goal is Kerberos, as the connection will fail if Negotiate cannot be performed. Negotiate is also known as Windows Integrated Authentication (WIA) and allows for both Kerberos and NTLM authentication. We can choose to further restrict NTLM usage via NTLM restrictions and exceptions policies, but this is beyond the scope of what we’re looking to achieve here.

Finally, we need to configure a firewall rule to allow WinRM traffic. In the above image, I have added the built-in rule for WinRM HTTP-In traffic via Domain/Private profiles and accepted the default configuration. There is a second rule you can add that is for the Public profile; the difference is that the Public profile rule will have the Remote Scope set to Local Subnet by default. In most environments, I wouldn’t add this. We only want WinRM to be accessible when connected to the domain network.

Testing WinRM

Now that we’ve configured the WInRM client and service components on all domain endpoints, let’s test it. You can verify the WinRM configuration by running winrm get winrm/config via an administrative command prompt, and the output should look similar to the following:

As shown above, the settings we configured via GPO are listed as “[Source=”GPO”]”. Next, we can test access between endpoints by running Enter-PSSession -ComputerName HOSTNAME (or etsn HOSTNAME for short) in a PowerShell window.

If the connection was successful, you should see the prompt change to include the remote hostname at the beginning, as shown above. Investigating the Security log on the remote host should yield a 4624 event showing a successful network logon, and in the Windows Remote Management Operational log, a 91 event showing the shell creation.

Securing WinRM Further

Up to this point, I’ve configured WinRM and allowed access from any:any. Going with the principals of least privilege and minimal access, I’d rather tighten this down. The easiest way to accomplish this is to simply configure the firewall rule to only allow connections from specified IP addresses, but I prefer something more dynamic.

Utilizing Connection Security Rules, we can configure the firewall rule to require authentication (and optionally encryption) and specify a group of authorized users to be able to establish a connection via IPSec. This secures the communication at the network layer, preventing communication to the application protocol itself unless authentication and optional encryption negotiation is successful.

I go over this configuration in much more detail in my Windows Firewall series (check out parts 3 and 4 here: Windows Firewall: The Series). For now, I’ll cover the configuration at a high level.

First thing to do is to configure the server-side rules, and an AD group to contain the authorized users that will be used in the firewall rule.

Above is my updated firewall rule, and a new connection security rule. The firewall rule has been scoped to my internal IP ranges, configured to require authentication and encryption, and an AD group configured under authorized users (if you view it in edit mode, the group will be CORP\WinRM_Servers. The connection security rule is configured to require mutual authentication for inbound traffic over TCP 5985 from my internal IP ranges. First and second authentication methods are set to default, as they are configured in my global IPSec configuration policy for Computer Certificate or Computer Kerberos first, and User Kerberos second.

Lastly, I’ve configured advanced auditing settings to audit IPSec related events for troubleshooting purposes, as shown above.

Testing the New Configuration

To test the config, I attempted to connect to one of my servers from two different PowerShell windows on a client, one running as a normal user (CORP\lol) and the other running as my SA account (CORP\ajf-sa). Here’s the results:

On the left side, the connection failed. On the right, the connection succeeded, because the user account used is a member of the group specified in the firewall rule. If I look at the current IPSec main mode session on the server, I’ll find the successfully established session:

Huuzah! WinRM secured via identity-based access control!

Now, to answer two questions you might be asking yourself at this point.

Q: Didn’t we disable unencrypted WinRM connections? Is this double-encrypted?

A: Yes, and Yes. In this case, we could configure the firewall rule security to use “null encapsulation”, which would still allow the authentication to occur, but the transport itself would not be encrypted via IPSec. This can be good for performance at scale for protocols that support their own encryption. But you can also use this methodology to secure a connection that is otherwise unencrypted. Got an app only accessible by Telnet or HTTP? Wrap it in IPSec to secure communication over the wire!

Q: Aren’t WinRM and other similar protocols already doing identity-based access control inheritently?

A: Yes. However, that on its own leaves the WinRM application layer protocol open for anything to connect. Securing it in this fashion prevents the application layer connection from ever succeeding if the required IPSec AuthN/AuthZ isn’t met first. This effectively secures the application protocol itself from attack, allowing you to expose it to untrusted networks such as the internet. See part 5 of my firewall series here: Windows Firewall: The Series for more fun with that, where I cover putting Domain Controllers on the internet!

Conclusion

I hope this was a good introduction to configuring and securing WinRM from a domain perspective. Part II will get into something that complicates things: connecting to Azure AD joined clients. Is it doable? Yes, with some additional configurations and caveats. Read on here: Part II.