PMR EVENT CENTRALIZATION

This document provides guidance on how to centralize Endpoint Privilege Management events to a central server using Windows Event Forwarding (WEF). BeyondTrust provides an Endpoint Privilege Management Reporting Pack, which includes enterprise class trend analysis dashboards, allowing organizations to understand and be proactive about the Endpoint Privilege Management events raised in their environment.

With the Endpoint Privilege Management Reporting Pack, Endpoint Privilege Management events from all managed endpoints can be centrally collected to a SQL Server database. The Endpoint Privilege Management Reporting Pack builds on a number of Microsoft technologies, including:

• Windows Event Forwarding
• SQL Server
• SQL Server Reporting Services (SSRS)

This approach provides a scalable and secure architecture that can manage high volumes of events and the largest enterprise environments.

Event Forwarding is provided by Windows Remote Management (WinRM), Microsoft’s implementation of a WS-Management Protocol. The protocol is SOAP-based and firewall-friendly, providing a common way for systems to access and exchange management information across an IT infrastructure.

One of the most powerful features of WinRM is the ability to forward events, enabling large scale health and state status monitoring of Windows environments (also known as Windows Eventing 6.0). Not only is this feature built into the latest versions of Windows (originally shipped with Windows Vista and Windows Server 2008), but it is also available for down-level operating systems.

For more information on BeyondTrust’s Endpoint Privilege Management Reporting Pack, see www.beyondtrust.com/support.

Event centralization definitions

• Event forwarders and event sources
  The events you are interested in reside on these hosts.
• Event collector
  Events are collected on these hosts based on events subscriptions defined on the collector host.
• Event subscriptions
  Determine the events collected and defined on the event collector. Group policy does not support definition of event subscriptions. Event subscriptions define:
  • Event source hosts in scope
  • Events in scope on those hosts
  • Event data transmission characteristics: push from source/pull from collector, frequency, HTTP/HTTPS
    There are 2 ways for event source computers to become aware of event collection subscriptions.
  • Collector-initiated subscription (pull): Subscription information is pushed to the event source hosts by the event collector using WinRM. This requires the event forwarder/source to listen for incoming WinRM connections from the collector.
  • Source-initiated subscription (push): The event source computer connects to the event collector via WinRM and requests subscription information. The event collector may be defined by Group Policy. Source-initiated subscription is preferred for its reliability and scalability in enterprise scenarios. A source-initiated subscription has an advantage of not requiring the collector to know all the computer names of the remote machines connecting to the service a priority, whereas a collector-initiated subscription requires the aforementioned information, which is harder to maintain.
    Suited for large environments where Group Policy is available. Policy is dictated to the source computer by Group Policy. The source computer is told: Contact Collector X and do what they say. Once the source computer contacts the collector, the collector looks up the subscriptions for the source computer, and then sets up the subscriptions. Then this begins to act like a Push subscription.
  • Positive: Very simple to configure using a single policy. Supports clustering of collectors. Only requires uni-directional TCP communication since the collector never initiates communication to the source computer.
  • Negative: Requires an AD infrastructure. Can be difficult to troubleshoot if the entire scope of source computers is successfully registered with their respective collectors since the collector does not know which source computers should be forwarding events to them.
    Event subscriptions may not be defined through Group Policy.

Windows Remote Management (WinRM)

WinRM is the communication channel leveraged by the Windows Event Forwarders (event sources) and Windows Event Collectors.

There are 2 types of communication between the hosts over WinRM:

• Event Subscriptions: Which hosts are included, which events, pull or push, how much, how often
• Event Transmission: The events themselves
  WinRM may act as a client or server component. It is necessary to configure WinRM as a server to listen for connections initiated from another host.

The host initiating connections depends on the event collection/forwarding configuration. In the typical configuration, connections are initiated from the forwarder/source to the collector as HTTP or HTTPS on standard WinRM ports.

WinRM may be configured using Active Directory Group Policy.

Active Directory Group Policy (GPO)

Active Directory (AD) is a directory service created by Microsoft for Windows domain networks included in most Windows Server operating systems.

Group Policy is a feature of the Microsoft Windows NT family of operating systems that controls the working environment of user accounts and computer accounts. Group Policy provides the centralized management and configuration of operating systems, applications, and users' settings in an Active Directory environment.

GPO provides a central configuration mechanism for WinRM and one aspect of Windows Event Forwarding; the event collector from which subscriptions are retrieved in source-initiated subscriptions.

Windows event forwarding collection

Features

• Standards Based: Leverages the DMTF WS-Eventing standard allowing it to work with other WS-Man implementations (see OpenWSMAN at SourceForge).
• Agentless: Event forwarding and event collection are included in the operating system by default.
• Down-Level Support: Event forwarding is freely and readily available.
• Multi-Tier: Forwarding architecture is very scalable where a source computer may forward to a large number of collectors and collectors may forward to collectors.
• Scalable: Event collection is very scalable where the collector can maintain subscriptions with a large number of source computers and events per second.
• Group Policy Aware: The entire model is configurable by Group Policy.
• Schematized Events: Windows events are now schematized and rendered in XML, which enables many scripting and export scenarios.
• Pre-Rendering: Forwarded Windows events can be pre-rendered on the source computer, negating the need for local applications to render Windows events.
• Resiliency: Designed to enable mobile scenarios where laptops may be disconnected from the event collector for extended periods of time without event loss (except when logs wrap), as well as leveraging TCP for guaranteed delivery.
• Security: Certificate based encryption through Kerberos or HTTPS.

Architecture

The architecture uses Group Policy to distribute WinRM and event forwarding configurations to a group of domain computers. Each client is configured to forward events to a central event collector.

Prerequisites

Central event collector

A central event collector must be used as a repository for all the events collected from the source computer.

The following operating systems can be event collectors (this feature is not supported for down-level operating systems):

• Windows Server 2012
• Windows Server 2016
• Windows Server 2019
• There are no built-in limitations when client operating systems are used as event collectors. However, we recommend Windows Server 2008 R2 or higher as the event collector, as this scales much better in high volume scenarios.

🚧

If you choose Windows Server 2016 or Server 2019 to run the event collector, refer to Microsoft KB article 4494462. On these operating systems, the Windows Event Collector service (WecSvc) and the Windows Remote Management service (WinRM) use the same URLs, but the default access control lists (ACLs) do not provide access from the WecSvc service; to resolve this issue, you must update the appropriate URL ACLs. For directions, see Events are not forwarded if the collector is running Windows Server.

Depending on the volume of events, the event collector can either be a dedicated or an existing machine. True enterprise class Windows Eventing is included with enterprise monitoring solutions like System Center Operations Manager (SCOM) (Audit Collection Services ACS).

Event source computers

The minimum operating system level required on the source computer is Windows 7.

Events can be centralized on any of the supported Windows Event Collector operating systems from any supported Windows event source operating systems. Each source computer requires a minimum of Windows Remote Management 1.1.

Implement Windows event forwarding

Summary checklist for the setup of event forwarding

1. Install and disable the BeyondTrust agent.
   We recommend doing this step before creating a subscription. A reboot is required for the service to be available to the subscription. The Avecto Defendpoint Service must be set to Disabled to deactivate the agent.
2. Run WinRM quickconfig
3. Run Wecutil qc
4. Create and name subscription in Event Viewer.
5. Run wecutil ss /cf:Events
   This changes the subscription from the default behavior of RenderedText to Events, which has the dual benefit of reducing source computer CPU overhead and the event size.
6. Run wecutil ss /ree:True
   This setting ensures all desired events in the Application event log on a source computer are forwarded to the event collector; the default behavior is to only forward future (arriving) events from the point the subscription begin. This can result in missing data.

1 Configure the event collector server address

Group Policy may be used to configure source computers (clients) to forward events to a collector (or set of collectors). The policy is very simple. It merely tells the source computer to contact a specific Fully Qualified Domain Name (FQDN) or IP Address and request subscription specifics. All other subscription details are on the event collector.

The following Group Policy settings are used to configure event forwarding:

Computer Configuration\Policies\Administrative Templates\Windows Components\Event Forwarding
Group Policy Computer Configuration path to Event Forwarding folder

When editing Group Policy settings, ensure the event collectors and source computers are under the management scope of the Group Policy Object being edited.

1. Edit the Group Policy Object (GPO) being used.
2. Configure the Configure the server address option.
3. Select Enabled.
4. Click Show. The SubscriptionManagers dialog box displays.
5. Add the server address in the Group Policy Management Editor for the group policy.
6. Click Add and enter the address of the event collector. for example, if the event collector FQDN is Server1.BeyondTrustlab.com, then the server address is Server=Server1.BeyondTrustlab.com
7. Click OK.

In some cases, the clients and the event collector might not be able to communicate. If this occurs, change the value of the server address to:
Server=Server1.BeyondTrustlab.com:5985/wsman/SubscriptionManager/WEC,Refresh=10

If the problem persists, contact BeyondTrust Technical Support.

2 Configure event collection services and Windows firewall

For source computers to communicate with the event collector machine:

• The correct inbound firewall ports must be open and accepting connections.
• The WinRM and event collector services must be running.

To run quickconfig:

1. On the event collector machine, open a command prompt.
2. Type winrm quickconfig.
3. When prompted to continue with the configuration, type Y.
4. This command checks the current configuration and makes the necessary changes. Upon completion, the following is configured:
   • Windows Remote Management service set to Automatic (Delayed Start) and Started.
   • Windows Firewall ports Windows Remote Management (HTTP-In): Port 5985 configured for inbound communication OR
   • Windows Firewall ports Windows Remote Management (HTTP-In) – Compatibility Mode: Port 80 configured for inbound communication.

In addition, the event collector service must be configured and started.

1. On the event collector machine, open a command prompt.
2. Type wecutil qc.
3. When prompted to continue with the configuration type Y.
   This command checks the current configuration and makes the necessary changes. Upon completion the following is configured:
   • Windows Event Collector service set to Automatic (Delayed Start) and Started.

3 Configure event subscriptions

The Windows Event Forwarding architecture stores the subscription definition on the event collector to reduce the number of touch-points in case a subscription needs to be created or modified. The following subscription is configured so that event source computers retrieve subscriptions from the event collector host (source-initiated subscriptions).

Subscriptions are defined on the event collector through the new Event Viewer user interface by selecting the Create Subscription action, when the Subscriptions node is selected. The subscription may also be created via the WECUTIL command-line utility.

Configuration Steps:

1. On the event collector, open the Event Viewer.
2. Navigate to the Subscriptions node.
3. From the menu bar, choose Action > Create Subscription.
4. The Subscriptions Properties dialog box appears.
   From here, you can specify a name, description, and the destination log (where the events are collected).
5. Select Forwarded Events for the destination log.
6. Select Source Computer Initiated (as Group Policy configures the source computer to contact the event collector for subscriptions settings).

📘

The Subscription type can also be configured as Collector initiated. In this case, source computers must be manually added to the subscription either through the subscription configuration or the WECUTIL command-line utility (which can also be scripted using PowerShell). We recommend that Source Computer Initiated be used, as this configuration is the most scalable.

7. Click Select Computer Groups.
8. Click Add Domain Computers and select the source computers.

We recommend adding a computer group that includes the required computer accounts, such as the Domain Computers group.

9. Click OK on the Computer Groups dialog box.
10. Click Select Events. The By Source field varies depending on where the logs are saved.
    Select event types to include in event collection as part of the event subscription configuration.
11. Configure the following Query Filter:
    • Event Level = Critical, Warning, Error, Information.
    • By Source = Avecto Defendpoint Service (when using the default log location Windows Logs\Application).
    • By Source = BeyondTrust Endpoint Privilege Management (when using the log location Application and Services Logs\BeyondTrust Privilege Management).

📘

• In a production environment, it may be advantageous to gather all events from the Application and System logs with a level of Critical, Error, or Warning. This event scope can be expanded to gather all events from these logs or even add additional logs (like the Security log).
• If the Endpoint Privilege Management Agent is not installed on the event collector, you cannot select BeyondTrust Endpoint Privilege Management Service as the event source. We recommend the Endpoint Privilege Management Agent be installed and the BeyondTrust Endpoint Privilege Management Service set to disabled to deactivate the agent, if desired. If it is not possible to install the agent, the subscription can be configured to collect events from the Application event log and filtered on event IDs 100 to 501. See the Endpoint Privilege Management Administration Guide to verify the minimum and maximum event IDs created by the Endpoint Privilege Management Service, as these are subject to change.

12. Click OK on the Query Filter dialog box.
13. Click Advanced on the Subscriptions Properties dialog box.
14. Select Minimize Latency.
    • Normal: This option ensures reliable delivery of events and does not attempt to conserve bandwidth. It is the appropriate choice unless you need tighter control over bandwidth usage or need forwarded events delivered as quickly as possible. It uses pull delivery mode, batches 5 items at a time, and sets a batch timeout of 15 minutes.
    • Minimize Bandwidth: This option ensures network bandwidth is strictly controlled for event delivery. It is an appropriate choice if you want to limit the frequency of network connections made to deliver events. It uses push delivery mode and sets a batch timeout of 6 hours. In addition, it uses a heartbeat interval of 6 hours.
    • Minimize Latency: This option ensures events are delivered with minimal delay. It is an appropriate choice if you are collecting alerts or critical events. It uses push delivery mode and sets a batch timeout of 30 seconds.
    • Protocol: HTTPS can be used to secure the communication channel. However, this requires additional configuration steps and requires the Event Collector to use a certificate.\
15. Click OK on the Advanced Subscription dialog box.
16. Click OK on the Subscription Properties dialog box.

4 Pre-render events

If the source computer is generating a large volume of forwarded events (for example, Security events from a Domain Controller), then we recommend event rendering be disabled on the event collector. The task of pre-rendering an event on the source computer can be CPU intensive for a large number of events.

1. On the event collector, open a command prompt.
2. Type:

wecutil ss <subscriptionname> /cf:events

ContentFormat is changed from RenderedText to Events, which reduces Source Computer CPU overhead and event size.

To view event subscriptions, use the WECUTIL command utility with the gs option. Type:

wecutil gs <subscriptionname>

5 Increase the event batch size

The batch size can be increased to reduce the frequency that source computers send their data. Use the command syntax in the shown example to configure batch size.

This example sets the batch size to 10,000.

wecutil ss sub_name /cf:Events /ree:false /dmi:10000 /cm:custom

6 Configure the source computer

Install the WinRM on source computers

When the down-level machines are source computers, ensure that the WinRM client is installed on these machines.

We recommend you use a software distribution server to deploy the WinRM packages, such as System Center Configuration Manager (SCCM) or Systems Management Server (SMS).

When upgrading an event collector from WinRM 1.1 to WinRM 2.0, ensure there are no active subscriptions running, otherwise the upgrade may fail.

For more information, see Prerequisites.

Configure the WinRM service

For source computers to communicate with the event collector machine, the Windows Remote Management (WinRM) service must be running on the source computers. WinRM service auto start is necessary for the host to retrieve subscription information from event collectors and send/push event data to the event collector.

The following Group Policy setting is used to configure WinRM to support event forwarding:

Computer Configuration\Policies\Windows Settings\Security Settings\System Services

Configuration Steps:

1. Navigate to the Windows Remote Management (WS-Management) service.
2. Double-click the service.
3. Check Define this policy setting.
4. Select the Automatic radio button.
5. Click OK.

Implementation scenarios

The scenarios outlined below provide an overview of the most common Windows Event Forwarding configurations, including scaled out and fault tolerant designs.

Basic event collection

The basic event collection design provides an example configuration for use in small to medium size organizations, where fault tolerance is not required.

Positives

• Supports up to 100,000 source computers connecting to a single event collector.

Negatives

• Limited fault tolerance. If the event collector goes offline, the events are collected on the client and forwarding resumes once the event collector is back online.
• An extended fault could result in audit event loss on the client due to log rollover. This can be mitigated by large event log size.

Scaled-out event collectors

The scaled-out design provides scalability as the number of event collectors can be increased to accommodate an unlimited number of source computers.

Positives

• Supports up to 100,000 source computers connecting to a single event collector.
• Supports an unlimited number of source computers.
• Accommodates broad geographic deployment or network segmentation.

Negatives

• Limited fault tolerance. If the event collector goes offline, the events are collected on the client and forwarding resumes once the event collector is back online.
• An extended fault could result in audit event loss on the client due to log rollover. This can be mitigated by large event log size.
• Traffic to database across WAN links requires firewall configuration.
• Database insert performance may be affected by slow links.

Scaled-out tiered fault tolerant event collection

The design combines scalability and fault tolerance. Windows Event Forwarding supports fault tolerant event collection by transmitting events to duplicate event collectors. The solution consuming the events must identify duplicates and discard them.

Positives

• Supports up to 100,000 source computers connecting to a single event collector.
• Supports an unlimited number of source computers.
• Accommodates broad geographic deployment, or network segmentation.
• Mitigates firewall and database performance concerns by placing 2nd tier collector proximate to database.
  Provides fault tolerance

Negatives

• Limited fault tolerance. If the event collector goes offline, the events are collected on the client and forwarding resumes once the event collector is back online.
• Extended fault could result in audit event loss on the client due to log rollover. Mitigated by large event log size.
• Traffic to database across WAN links requires firewall configuration.
• Database insert performance may be affected by slow links.

📘

Specific hardware and software specifications varies depending on the enterprise environment in which Event Forwarding is configured. BeyondTrust’s Professional Services team can provide advice and assistance in this area if required. Please contact your account manager for more information.

Optional event centralization configuration

Optimize event forwarding

Forwarder resource usage

It is possible to control the volume of events sent to the event collector by the source computer. This may be required in high volume environments.

The following Group Policy settings are used to configure Forwarder Resource Usage:

• Computer Configuration\Policies\Administrative Templates\Windows Components\Event Forwarding\ForwardResourceUsage

This GPO controls resource usage for the forwarder (source computer) by controlling the events per second sent to the event collector. This setting applies across all subscriptions for the forwarder (source computer).

Reduce the TCP/IP connection idle time

A Windows Server is capable of 16,000 concurrent TCP/IP connections; if your environment has more than 16,000 source computers connected to an event collector, not all the machines are able to communicate at the same time. In large enterprise environments where large numbers of source computers are required to connect to an event collector, we recommend reducing the TCP/IP idle time to improve the speed at which source computers can connect.

It is possible to connect about 100,000 source computers to a single event collector. However, in this scenario, Microsoft recommends setting the TCP/IP idle time to 2 minutes.

1. Open an elevated command prompt on the event collector.
2. Enter net config server /autodisconnect:2
3. The message command completed successfully should be displayed.

The purpose is to disconnect idle sessions after a set number of minutes. The valid value range is -1 to 65535 minutes. To disable Autodisconnect set it to -1.

Setting Autodisconnect to 0 does not turn it off and results in very fast disconnects, within a few seconds of idle time. However, the RAS Autodisconnect parameter is turned off if you set it to a value of 0.

Event log retention

The forwarded events log must be set to a size large enough to ensure the log does not wrap before the data is parsed into BeyondTrust’s Endpoint Privilege Management Reporting database or upstream event collectors.

The theoretical maximum log file size for the forwarded events log on Windows Server 2008 R2 is 2 terabytes. However, as the log file grows, the Event Viewer UI takes longer to load and show results for custom views. Depending on the size of the network, a 1GB forwarded events log file can hold from a few hours to a few days’ worth of log data. Due to this size limitation, review the log regularly and set up the appropriate size for your environment.

The above information is intended for the server acting as the event collector. The size of the event log on the source computers is less critical, however if the event collector is unavailable, events are collected locally and forwarded once the event collector is back online. Therefore, we recommend considering the impact of offline event collectors and set the size of the client machine event log accordingly.

BeyondTrust’s Professional Services team can provide best practice advice in this area.

Configure the event collector service with Group Policy

Group policy may be used to enable and configure Windows Remote Management (WinRM). This section focuses on configuring the WinRM service to listen for incoming events. This can be configured with the following Group Policy setting:

• Computer Configuration\Policies\Administrative Templates\Windows Components\Windows Remote Management\WinRM Service

📘

When editing Group Policy settings, ensure the event collectors are under the management scope of the Group Policy Object being editing.

1. Edit the Group Policy Object (GPO) being used.
2. Navigate to ./Allow remote server management through WinRM (see above for full path).
3. Select Enabled.
4. Specify * as the filter.

📘

This Listener configuration should only be used in a trusted network environment. If the environment is not trusted (like the internet), then configure only specific IP addresses or ranges in the IPv4 and IPv6 filters.

If you are using Windows Server 2008 R2 as the event collector or have upgraded to Windows Remote Management 2.0 (which is recommended), then you will need to enable Compatibility mode to receive events from down-level clients. The following Group Policy settings are used:

• ./Turn on Compatibility HTTP Listener
• ./Turn on Compatibility HTTPS Listener

Configuration Steps:

1. Navigate to ./Turn on Compatibility HTTP Listener (see above for full path).
2. Select Enabled.
3. Navigate to ./Turn on Compatibility HTTPS Listener (see above for full path).
4. Select Enabled.

The following command allows you to enable the compatibility listener from the command line:

winrm set winrm/config/service @{EnableCompatibilityHttpListener="true"}

Specify the event collector server address port with Group Policy

The event collector’s server address port can be configured with Group Policy. To do this, the full URI must be specified within the address configuration of the following GPO settings:

Computer Configuration\Policies\Administrative Templates\Windows Components\Event Forwarding

WinRM 2.0 settings

Server=http://:5985/wsman/SubscriptionManager/WEC
Server=https:// :5986/wsman/SubscriptionManager/WEC

WinRM 1.1 settings

Server=http://:80/wsman/SubscriptionManager/WEC
Server=https://:443/wsman/SubscriptionManager/WEC

The syntax used here depends on the WinRM version running on the event collector and whether HTTP or HTTPS is used. If HTTPS is used, a valid SSL certificate is needed.

Additional information may be configured. The syntax of the SubscriptionManagers value is:

Server=[http|https]\://HOSTNAME[:PORT]/wsman/SubscriptionManager/WEC[,Refresh=SECONDS][,IssuerCA=THUMBPRINT]]

Each option for the SubscriptionManager is a comma-delimited string containing the following parts:

• Server: FQDN or Hostname
• Refresh: The number of seconds to send events to the server
• IssuerCA: Thumbprint of the client authentication certificate

For more information on how to configure WinRM to use SSL certificates, see https://docs.microsoft.com/en-us/windows/win32/wec/setting-up-a-source-initiated-subscription.

Configure WinRM enhanced security with Group Policy

The security configuration is divided into two parts: service and client. The service configuration manages the WinRM service that receives WS-Management requests from clients.

The following are supported authentication methods:

• Basic Authentication
• Digest Authentication
• Credential Security
• Support Provider (CredSSP)
• Negotiate Authentication
• Kerberos Authentication
• Client Certificate-based Authentication
• Channel Binding Token

The security settings must be compatible between the client and the service. The following Group Policy settings may be configured for the WinRM Client and Service:

Computer Configuration/Policies/Administrative Templates/Windows Components/Windows Remote Management/WinRM Client/

Computer Configuration/Policies/Administrative Templates/Windows Components/Windows Remote Management/WinRM Service/

📘

It is important these settings are compatible with your operating environment and the WinRM Client and WinRM Service settings are compatible. Misconfiguration may stop WinRM from operating correctly.

Allow basic authentication

This policy setting allows you to manage whether Windows Remote Management (WinRM) uses basic authentication. If you enable this policy setting, then WinRM will use basic authentication.

If WinRM is configured to use HTTP transport, then the user name and password are sent over the network as clear text.

Disallow digest authentication

This mode of authentication is a challenge-response scheme. The client will initiate the request, and in response, the server will send a server-specified token string to the client. After the token string is received, the client will append the resource request with the user name of the client, the hash of the user name’s password, and the token string to the response message.

This method of authentication is abused by attackers using a technique called Pass the Hash. Pass the Hash is a way for an attacker to use the password hashes to authenticate as the user without ever discovering the user’s actual password. The client has the option to set Digest Authentication, while the service does not. Additionally, the service can allow hardening of WinRM TLS connections using channel binding tokens.

Allow credential security support provider authentication (CredSPP)

This policy setting allows you to manage whether Windows Remote Management (WinRM) uses CredSSP authentication. CredSSP provides a secure way to delegate a user’s credentials from a client to a target server. The SSP provides the capability of Single Sign-on (SSO) in Terminal Services sessions. This option is only available for WinRM 2.0.

Disallow Keberos authentication

Kerberos version 5 is used as a method of authentication and communication between the service and client. This policy setting allows you to manage whether Windows Remote Management (WinRM) will not use Kerberos authentication directly.

If you enable this policy setting, then WinRM will not use Kerberos authentication directly. Kerberos may still be used if WinRM is using the Negotiate authentication and Kerberos is selected.

Disallow negotiate authentication

Negotiate authentication is a Security Support Provider (SSP) that provides a client with two alternative methods for authentication: Kerberos and NTLM. This policy setting allows you to manage whether Windows Remote Management (WinRM) will not use Negotiate authentication. Negotiate will initially select Kerberos as the default; otherwise, NTLM is used.

Disabling Negotiate authentication may result in unforeseen problems when trying to configure WinRM locally. When the remote destination is the local host and the client is in the domain, WinRM uses Negotiate authentication. If an error arises stating Negotiate authentication is disabled, a workaround is to use Kerberos locally by specifying the local host name in the remote switch. Setting the Disallow Negotiate Authentication policy to Enabled is recommended.

Allow unencrypted traffic

This policy setting allows you to manage whether Windows Remote Management (WinRM) sends and receives unencrypted messages over the network. If you enable this policy setting, then WinRM sends and receives unencrypted messages over the network.

Trusted hosts (client only)

Trusted host authentication is used for computers not using HTTPS or Kerberos for authentication. A list of computers (non-domain members) can be provided and marked trusted. If you enable this policy setting, the WinRM client uses a specified list to determine if the destination event collector is a trusted entity. These computers, when using WinRM, will not be authenticated.

Specify channel binding token hardening level (service only)

A common threat amongst NTLML, NTLMv2, and Kerberos authentication methods is a Man-in-the-Middle (MitM) attack. Channel Binding Token (CBT) authentication option involves securing communication channels between a client and server using Transport Layer Security (TLS).

A MitM attacker is positioned between a client and a server to impersonate as both the server and client. When the client initiates a request to the server, the attacker captures the client’s first request and forwards it to the server on the client’s behalf. The server responds with an authentication request. The attacker receives the server’s request and forwards the request to the client. When this request is received by the client, the client sends their credentials as a response. As previously done, these credentials are sent to the attacker because the client assumes it is communicating with the server and now the attacker can access the resource. CBT ensures a secure communication channel with the client. If a MitM is underway, then the two connections will generate two different tokens (sessions in particular; server-to-attacker and client-to attacker). When the CBT-aware server notices this discrepancy, it will refuse the authentication request.

Channel Binding Tokens can be set to:

• None: Not using any CBTs
• Relaxed: Any invalid tokens are rejected, but any channel without a binding token will be accepted
• Strict: Any request with an invalid channel token is rejected

If Hardening Level is set to Strict, any request not containing a valid channel binding token will be rejected. This option is only available for WinRM 2.0.

Disable Windows Remote Shell

When WinRM completes execution of quickconfig, Windows Remote Shell (WinRS) will be enabled by default and will accept connections. This poses a potential security risk and you may want to disable this. If the Windows Remote Shell service is needed for a task, temporarily enable it and then disable it when the task is completed.

WinRS can be disabled for domains using Group Policy. This policy enforcement applies for the collector and sources in the domain. WinRS policies can be found by navigating to:

Computer Configuration\Policies\Administrative Templates\Windows Components\Windows Remote Shell

To disable WinRS:

1. Set the Allow Remote Shell Access policy to Disabled.
2. Click OK.

WinRS can also be disabled by using the command line:

winrm set winrm/config/winrs @{AllowRemoteShellAccess="false"}]

Client certificate-based authentication

The WinRM traffic between the collector and source is encrypted using a Windows Integrated Authentication or HTTPS. The message payload of the WinRM traffic is encrypted using one of the three authentication methods provided by Integrated Windows Authentication: Negotiate, Kerberos, or CredSSP.

WinRM with SSL requires certificates to authenticate the collector and source. Services can verify the connecting client’s authenticity by examining its certificate. If the authentication process fails, then the client’s connection is revoked.

The general steps consist of configuring the listening port, creating certificates for collectors and sources, configuring the subscription manager, creating certificates, and configuring subscriptions.

There is no Group Policy setting to disable Certificate-Based Authentication for WinRM’s client configuration. The only alternative is using the command line:

winrm set winrm/config/client/auth @{Certificate="false"}

📘

Configuring Windows Event Forwarding to use HTTPS is beyond the scope of this document. BeyondTrust’s Professional Services team can provide advice and assistance in this area if required. Please contact your account manager for more information.

Restrict WinRM access

The default rules permit connections from any IP address to the specific WinRM port. An attacker who has presence on a network can possibly access machines and servers by accessing WinRM services. This attack can be mitigated by customizing firewall rules to only allow connections between collectors and sources.

These configurations apply to the WinRM predefined firewall rules under:

Computer Configuration\Policies\Windows Settings\Security Settings\Windows Firewall with Advanced Security\Inbound Rules

Event source firewall modifications

To enable WinRM firewall rules on the sources:

1. Right-click the predefined WinRM firewall rule and select Properties.
2. Navigate to the Scope tab.
3. In the Remote IP Address area, select the These IP addresses option.
4. Click the Add button.
5. Select the This IP address or subnet option and enter the IP address of the collector.
6. Click OK.

This assumes the Microsoft Windows Firewall is being used.

Collector firewall modification

Repeat the steps for the predefined WinRM rule at Configure event collection services and Windows firewall.

We recommend setting the Predefined set of computers option to Local subnet. This rule can be changed to best suit your environment.

Raise actions and tasks based on collected events

In many situations, administrators or security professionals may want to be informed when a particular event is collected. It is possible to trigger the following actions by assigning a task to be in the event collector’s forwarded events log:

• Start a program
• Email
• Display a message

For example, an administrator may want to be informed by email when a user has elevated an application using the On-Demand facility (Event ID 101).

1. Open the Event Viewer utility on the Event Collector.
2. Right-click on the Forwarded Events log and select Attach a Task To this Log.
3. Give the task a name and click Next.
4. Click Next.
5. Select the Action required.
6. Complete the action details and click Next.
7. Click Finish. The task is now set up.

Advanced options

It is possible to set advanced configuration options and filters by reviewing the action for the Windows Task Scheduler > Event Viewer Tasks.

General information

Subscription XML details

A subscription is an XML file that describes to the operating system what event logs to collect and forward. The following subscription example demonstrates the collection of Endpoint Privilege Management events in the Application log from a source (client). The targeted sources are the Domain Computers group and the Domain Controllers group.

The following subscription example is for testing purposes as it will collect a large number of events and is not recommended for production use.

<?xml version="1.0" encoding="UTF-8"?>
<Subscription xmlns="http://schemas.microsoft.com/2006/03/windows/events/subscription">
<SubscriptionId>Application Log</SubscriptionId>
<SubscriptionType>SourceInitiated</SubscriptionType>
<Description></Description>
<Enabled>true</Enabled>
<Uri>http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog</Uri>
<ConfigurationMode>MinLatency</ConfigurationMode>
<Delivery Mode="Push">
    <Batching>
        <MaxLatencyTime>30000</MaxLatencyTime>    
    </Batching>
    <PushSettings>
        <Heartbeat Interval="3600000"/>
    </PushSettings>
</Delivery>
<Query>
<![CDATA[
    <QueryList>
        <Query Id="0" Path="Application">
            <Select Path="Application">*[System[Provider
                  [@Name='BeyondTrust Endpoint Privilege Management Event 
           Service'] and (Level=1 or Level=2 or Level=3 or Level=4 or Level=0) and 
                  ((EventID &gt;= 100 and EventID &lt;= 116) )]]
           </Select>
        </Query>
</QueryList>
]]>
</Query>
<ReadExistingEvents>false</ReadExistingEvents>
<TransportName>HTTP</TransportName>
<ContentFormat>RenderedText</ContentFormat>
<Locale Language="en-US"/>
<LogFile>ForwardedEvents</LogFile>
<PublisherName>Microsoft-Windows-EventCollector</PublisherName>
<AllowedSourceNonDomainComputers></AllowedSourceNonDomainComputers>
<AllowedSourceDomainComputers> O:NSG:NSD:(A;;GA;;;DC)A;;GA;;;DD)</AllowedSourceDomainComputers>
</Subscription>

Subscription details

• Subscription: The subscription schema.
• SubscriptionId: The subscription’s identification.
• Description: Describes the subscription.
• Enabled: Specifies if the current subscription is enabled or disabled.
• Uri: The type of event used by the subscription.
• ConfigurationMode: Used for the Event Delivery Optimization of subscriptions. The four valid options are:
  • Normal
  • MinLatency
  • MinBandwidth
  • Custom
• Delivery Mode: Indicates how events should be sent to the subscription manager. The mode can either be: Push (Source-Initiated) or Pull (Collector-Initiated).
• QueryList: Used for event filtering and is a XPath query.
• Heartbeat: Used to validate the client’s connectivity with subscription.
• ReadExistingEvents: Notifies the subscription to read all events matching the filter.
• TransportName: Indicates that either HTTP or HTTPS will be used
• ContentFormat: Specifies how the event data will be given to the subscription manager.
• Locale: Language that the response is translated to.
• LogFile: The event log file where the received events will be stored.
• PublisherName: The name of the publisher that owns or imports the log file.
• AllowedSourceNonDomainComputers: List the allowed non-domain computers that can receive the subscription.
• AllowedSourceDomainComputers: List the allowed domain computers that can receive the subscription.

WS-Management protocol settings

• MaxEnvelopeSizekb: The Simple Object Access Protocol (SOAP) data size has maximum in kilobytes. Default is 150 kilobytes.
• MaxTimeoutms: Each push request (not pull) has a maximum timeout. This value is in milliseconds. Default is 60000ms (60 seconds).
• MaxBatchItems: The limit of elements used in a pull response. Default for WinRM 1.1 and earlier: 20. Default for WinRM 2.0: 32000.
• MaxProviderRequests: The limit on concurrent requests. Default for WinRM 1.1 and earlier: 25. Default for WinRM 2.0: Unsupported/Undefined.

WinRM client configuration

The following parameters configure how the WinRM client operates.

• NetworkDelayms: A time buffer for the client computer to wait in milliseconds. Default WinRM 1.1 and earlier: 5000. Default WinRM 2.0: 5000.
• URLPrefix: The type of URLPrefix used on request for HTTP or HTTPS requests. Default WinRM 1.1 and earlier: wsman. Default WinRM 2.0: wsman.
• AllowUnencrypted: Clients are allowed to request unencrypted traffic. Default WinRM 1.1 and earlier: false. Default WinRM 2.0: false.
• Auth: Specifies which authentication method is allowed for the client computer.
• DefaultPorts: Default WinRM 1.1 and earlier: HTTP = 80, HTTPS = 443. Default WinRM 2.0: HTTP = 5985, HTTPS = 5986.
• TrustedHosts: These trusted hosts do not need to be authenticated.

WinRM service configuration

WinRM and IIS

Windows Server 2008 R2 introduced a feature called WinRM IIS Extension. The IIS Extension allows the redirection of WinRM traffic from port 80 to port 5985 using a WinRM module. This module permits sources running WinRM 1.1 and earlier to communicate with a collector that is also using port 80 for Web traffic.

When a WinRM connection arrives on port 80, IIS investigates the incoming URL for the prefix /wsman. This URL prefix is reserved by IIS and no configuration of IIS is needed. All GET requests to the URL prefix /wsman are forwarded to WinRM.

Microsoft recommends not hosting any site with the URL prefix. WinRM IIS Extension is not installed by default and must be added through Server Manager.

WinRM registry keys and values

WinRM Registry keys can be found in the following locations. We do not recommend changing the registry key; they are only listed here for verification purposes. These keys are found by viewing the following GPO Administrative Template (ADM) files located at Event Forwarding:

• EventForwarding.adm
• Windows Remote Management: windowsremotemanagement.adm
• Windows Remote Shell: WindowsRemoteShell.adm

The policies registry keys appear once a Domain Controller configures WinRM using Group Policies.