Technical information on agentless connections for Windows systems

Agentless connections on Windows systems use the remote connection protocol WinRM. WinRM therefore needs to be activated on assets to be monitored by Cyberwatch.

WinRM HTTP uses the port 5985 by default, and WinRM HTTPS the port 5986.

Getting Windows agentless connection to work may require some configuration steps described below.

Prerequisites for using Agentless connections

The account used by Cyberwatch must be a member of the local Administrators group of the assets, as the analysis scripts contain privileged methods:

  • use of DISM (Deployment Imaging and Servicing Management) -recovery of versions of installed KBs -
  • use of WUA API (Windows Update Agent) - deletion / download / management of .cab file, WUA services management, deployment of updates -
  • access to privileged directories - %APPDATA% of all users to get the version of installed applications -
  • privileges potentially needed for running Compliance scan scripts

On assets joined to an Active Directory domain, use a domain account dedicated to Cyberwatch, member of the local Administrators group of the assets to monitor. This membership can be deployed with a GPO, using “Restricted Groups” or the “Local Users and Groups” Group Policy preferences.

In the WinRM with HTTP Negotiate stored credential, enter the account in the DOMAIN\user format. This connector authenticates with NTLM. If the domain restricts NTLM, use the WinRM with Kerberos connector described in the section “Using WinRM-Kerberos” below.

A domain account has two advantages over a local account:

  • it remains usable on assets that deny network logon to local accounts
  • it does not require the LocalAccountTokenFilterPolicy registry key, as UAC does not filter the token of a domain account during a remote connection

Use a local account

On assets that are not joined to a domain, create a local Cyberwatch user member of the local Administrators group, for example with the following command:

$UserPassword = Read-Host -AsSecureString   # Once the command is validated enter a password for the Cyberwatch user
New-LocalUser "Cyberwatch" -Password $UserPassword
Add-LocalGroupMember -Group 'Administrators' -Member Cyberwatch -Verbose

Name of the Administrators group will vary depending on the system’s language.

A local account also requires the LocalAccountTokenFilterPolicy registry key, described in the section Enable WinRM.

An asset can deny any network logon to local accounts, with the user right “Deny access to this computer from the network” (SeDenyNetworkLogonRight) containing Local account or Local account and member of Administrators group. This setting is required by rule SBP-WIN-04-007 of the Security_Best_Practice_Windows compliance repository, as well as by the Microsoft and CIS security baselines. On these assets, an agentless connection with a local account fails: use a domain account or the Cyberwatch agent.

The members of the Protected Users or gMSA groups cannot use the WinRM service. Make sure the account used by Cyberwatch, domain or local, does not belong to either of these groups.

Enable WinRM

The PowerShell command below enables the WinRM service if it is disabled, and configures the Windows firewall accordingly:

Enable-PSRemoting -Force

With a local account, the activation of WinRM alone is not enough. It is necessary to allow accounts of local administrator to connect via the WinRM protocol, or Cyberwatch will raise the WinRM::WinRMAuthorizationError error when initializing the agentless connection. This step is not needed with a domain account.

To avoid this issue, add the following key to the Windows registry:

New-ItemProperty -Name LocalAccountTokenFilterPolicy -path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -propertyType DWord -value 1

This key disables UAC token filtering for network logons of local accounts. It makes rule SBP-WIN-05-005 “Ensure UAC token filtering is not disabled for network logons” of the Security_Best_Practice_Windows compliance repository fail. A domain account avoids this setting.

The following command is used to check that the WinRM service is started, and starts it if it is not:

winrm quickconfig

Optional - Manually disable the firewall for WinRM

Manually disabling the Windows firewall may sometimes be necessary mainly with the use of AWS-EC2 hosts. In this case Cyberwatch will raise the Connection expired error.

The PowerShell command below configures the firewall to allow incoming TCP requests on port 5985.

netsh advfirewall firewall add rule name="WinRM-HTTP" dir=in localport=5985 protocol=TCP action=allow

Optional - Using WinRM-Kerberos

The WinRM with Kerberos connector requires a domain account. It replaces the WinRM with HTTP Negotiate connector when the domain restricts NTLM authentication.

Kerberos is an authentication protocol that relies on third-party trust. It works using a Key Distribution Center (KDC), that can distribute tickets allowing the user to access and use the network resources. It works in a way similar to SSO authentication systems.

Kerberos authentication process is as follows:

  • The client initiates an authentication request against the KDC
  • If the KDC validates the authentication, it issues a ticket-granting ticket (TGT)
  • The client then presents the TGT to a service it wants to access
  • The service sends back the TGT to the KDC for validation
  • Once validated, the KDC issues a final ticket that allows the client to authenticate against the service

For this authentication process to be possible, information below must be filled:

  • Realm: logical group in which Kerberos resources are centralized. For WinRM authentication, this represents the domain of your Active Directory
  • KDC: third-party trusted server responsible for issuing tickets. In an Active Directory domain, it corresponds to the FQDN of the domain controller
  • Administration server: third-party trusted server responsible for issuing service tickets to clients. In an Active Directory domain, it corresponds to the FQDN of the domain controller

It is then required to provide user/password information of an account allowed to authenticate against the Active Directory domain provided above.

Prerequisites for using WinRM-Kerberos

The Cyberwatch server must be able to resolve the domain names of:

  • the KDC (Key Distribution Center)
  • the administration server
  • each asset to be monitored