Network credential access for agentless scanning
ALERT LEGACY ARTICLE: The content in this article is no longer updated and is available for reference purposes only. Features and workflows described may be deprecated, significantly changed, or no longer supported.
Environment
- Datto EDR
Description
Agentless endpoint access is achieved through the use of native remote management protocols like WMI, SMB, Remote Scheduled Tasks, and PSRemoting for Windows-based systems and SSH for Linux-based systems. This methodology is appropriate for centrally managed networks where you don't want to install permanent agents or don't want to make permanent changes to the systems (this bypasses most organizations' more stringent Change Control processes since it isn't producing a change to the baseline of the system).
Agentless collection utilizes credentials that are defined in Datto EDR's Credential Manager. This requires a service account or administrative credential with Administrator-level rights on each of the target endpoints. SSH Credentials can be Key-based or Username/Password or both. The SSH account must be part of the sudo group (should not be the root account). These are encrypted using a server-side key by default but can also utilize a client-side encryption (AES Key) generated by the Controller to further protect the credentials.
Authenticated scanning:
Authenticated scans against remote systems require an administrator (or sudo for Linux) account or an account with Local Administrator privileges on each remote system you intend to scan. These account credentials are stored in the Console's Credential Manager and can be entered in the Admin panel or during query creation.
Credentials stored by Datto EDR's credential manager are protected using strong industry-standard encryption, options for Client-side Encryption using an AES key generated by the Controller can also be used for further protection.
The simplest method is to create a Service Account for Datto EDR with domain administrator privileges or sudo credentials / SSH keys for Linux to perform scans.
Understanding Windows permissions
When scanning within a Microsoft Active Directory or LDAP Domain, Datto EDR will require specific permissions that allow remote administration for endpoint survey deployment. Before beginning it is important to understand the different levels of administrator- level permissions and what access they give when using it for authenticated scanning.
The following is a definition of each Windows Administrator roles:
Local Administrators |
Members of this group, like the built-in Administrator account (SID 500) or SYSTEM, have full control of the local system that they pertain to.
|
Domain Administrators |
Members of this group have full control over all systems within its respective domain. Systems may include: domain controllers, member servers, and workstations. |
A common least privilege best practice for authenticated scans of this type is to create a domain account and place it within the Local Administrators group of the target systems you intend to scan via Group Policy. This will ensure appropriate remote access to the targeted systems while restricting the account from more sensitive domain administrator activities. When considering what permissions and configurations you will use, consult your network administrator for any local policies around least privilege and privileged accounts management.
Scanning Non-Domain (unmanaged) Windows Hosts
On non-domain (unmanaged) assets, Local administrator accounts other than the built-in Administrator account (SID 500) may not have rights to manage a server remotely, even if remote management is enabled. The Remote User Account Control (UAC) LocalAccountTokenFilterPolicy registry setting must be configured to allow accounts of the Local Administrators group other than the built-in administrator account to remotely manage the server.
To disable UAC remote restrictions, change the registry value of "LocalAccountTokenFilterPolicy" to 1:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
If the LocalAccountTokenFilterPolicy registry entry does not exist, follow these steps:
-
Open regedit.exe and navigate to: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
-
On the Edit menu, point to New, and then click DWORD Value.
-
Type LocalAccountTokenFilterPolicy and press Enter.