Netbackup malware scan-host capabilities and limitations for Windows vs Linux hosts

Description

The NetBackup malware scan host that is configured on stand-alone Windows vs Linux OS will differ slightly in its capabilities, behavior and performance.

Details:

Both Windows and Linux hosts can be used as a stand-alone scan host for on-demand malware scan.
The overall prerequisites for a scan host, for Windows and Linux OS hosts, are documented in the NetBackup Security and Encryption Guide 10.x under the section "Prerequisites for a scan host".
Limitations specific to a Windows scan host using NFS share are listed below.

1. Both Windows and Linux scan-hosts will not be able to scan file types listed below. These will be skipped.

Password protected files
Encrypted files
Compressed and password protected file archives (zip, tar, gzip)
Corrupted files

Additionally, both Windows and Linux scan-hosts will skip a file if the scanner is unable to determine the file type.

However, a Windows scan-host will not be able to scan backup images containing files and folders with non-English characters. This is a limitation of Windows OS and such files are skipped during a scan. Thus, the number of files scanned reported on WebUI could be less than the total files in that image.

A Windows scan host may also skip scanning file / folder paths exceeding 256 characters. 
If the scan encountered files that could not be scanned for whatever reason, then a warning notification is displayed as seen below.

A report of files that were skipped can be obtained by clicking on Actions > Export unscannable files list, as seen below.

A Windows scan host may take a longer time to scan when compared to a Linux scan host.

Key points to consider when creating a scan-user account on Windows scan-host using NFS share:
2a. The built-in administrator account can be used as the scan-user and will be able to scan all types of images. However, this account would most likely be disabled on production servers for security consideration.

2b. Thus, a local user account (example name: xyz) must be created and then added to the "Administrators" group.
In order to enhance security, we need to map the account identity to better secure our interactions with NFS shares. Utilizing the local passwd and group files is one of the methods which does not need Active Directory integration. The default location for these files are:

C:\windows\system32\drivers\etc\passwd
C:\windows\system32\drivers\etc\group

If the above files do not exist, then create them manually.

2c. When scanning images of Standard and MS-Windows policy type, the local scan-user account, xyz, needs to have UserIdentifier (UID) permissions set to non-zero value. As an example, we have chosen a random UID 1001, and have added it to the passwd and group files.

passwd file:
xyz:x:1001:1001:Description:C:\Users\xyz

group file:
scangroup:x:1001:1001

Note: The scangroup is just a random name chosen as an example. It can be any name of your choice.

Example:

2d. When scanning images of VMware and cloud workloads, the scan-user account, xyz, needs to have UserIdentifier (UID) permissions set to 0 value. Thus, the passwd and group files need to be modified as seen below

passwd file:
xyz:x:0:0:Description:C:\Users\xyz

group file:
scangroup:x:0:0

2e. As the permissions differ for the scan-user account (depending on the type of image to be scanned), it would necessitate provisioning 2 separate Windows scan hosts, each with a unique local account and UID permissions. Prior to initiating an on-demand scan, we then need to choose a specific scanhost pool which has the desired scan-host.

A possible workaround to avoid provisioning two separate Windows scan hosts is to create and use a local user account called nfsnobody, add it to the "Administrators" group and then set the UID mapping to 0 value, example below.

The group file needs to have the 0 value as well.
scangroup:x:0:0

It is advisable to log-off and logon to Windows using the nfsnobody account just to ensure that the account has no issues due to any restrictive group policies, if any.

2f. On the Windows scan-host, the 'Client for NFS service' needs to be restarted, preferably using command line.

nfsadmin client stop
nfsadmin client start

If the service fails to start, then go for a reboot.
To check if the account has been correctly mapped as a NFS mapped identity, run the below command in PowerShell.

Get-NfsMappedIdentity -AccountName <scan_user_name> -AccountType User