CONFIGURATION OF

SNOW INVENTORY
AGENTS
Document date 2021-11-17

SNOWSOFTWARE.COM
CONTENTS
1 Introduction .................................................................................................... 3

2 Agent configuration ......................................................................................... 4

2.1 Configure file system scan ......................................................................... 4

3 Oracle database products ................................................................................ 7

4 Output data ..................................................................................................... 8

5 Server endpoints and drop locations ............................................................... 9

5.1 Server endpoint ....................................................................................... 9

5.2 Drop location ......................................................................................... 10

6 Security ......................................................................................................... 11

6.1 Encryption of passwords .......................................................................... 11

6.2 Data anonymization options ..................................................................... 11
6.3 Communication ...................................................................................... 12

7 Troubleshooting ............................................................................................ 14

7.1 Verify communication .............................................................................. 14

Page 2 of 14 SNOWSOFTWARE.COM
1 INTRODUCTION
This document describes the configuration of the Snow Inventory Agents in the latest
version of the products. Some functionality described in this document may work
differently or not at all in previous versions.

The Snow Inventory Agents are part of the Snow Inventory solution. They are used for
inventory of Windows, Linux, macOS, and Unix computers. The agents scan the computers
and save the collected data to encrypted files, which are sent to a Snow Inventory
endpoint (Master Server, Service Gateway, or Extender).

Page 3 of 14 SNOWSOFTWARE.COM
2 AGENT CONFIGURATION
The configuration file of the Snow Inventory Agents is named snowagent.config, an XML
file stored in the installation directory. The file contains settings defining what to inventory,
when to inventory, and where to send the inventory result.

For a complete list of all configuration parameters, refer to the configuration-doc.html file
available in the Snow Support portal: Configuration document for all Inventory agents.

Some parameters in the configuration file are described in more detail below.

NOTE

▪ To ensure the correct functioning of the agent, the syntax of the agent
configuration file must be correct. Manual editing of this file is not recommended.

▪ All elements in the agent configuration file are case-sensitive.

2.1 CONFIGURE FILE SYSTEM SCAN

Use Software/Include and Software/Exclude in the configuration file to specify what
parts of the file system the agent will include in the scan.

Based on the contents of Software/Include and Software/Exclude, a ruleset

determining what parts of the file system to include in the scan is created according to the
following:

1. The agent checks for content in Software/Include.

a. If no include path is specified:

▪ Inventory Agent for Linux, Unix, and macOS: no ruleset is

created, and no files will be included in the scan. The procedure is
terminated and will not continue with steps 2 and 3.

▪ Inventory Agent for Windows: all local drives are added to the
ruleset and represent starting points for the scan. The procedure
continues with step 3.
b. If one or more include paths are specified, each path is added to the ruleset
and represents a starting point for the scan.
The paths must be specified according to the rules for include paths.
c. Any content that does not begin with a drive letter (c: ) or root (/), does not
include a path separator (\ or /), and includes a wildcard is interpreted as a
file name extension and is placed in the global extension list.
2. If at least one complete include path has been specified, the agent checks for
content in the global extension list. The content, if any, is added to the endpoints of
each path in the ruleset created in step 1.
3. The agent checks for content in Software/Exclude. Any specified exclude paths
are added to the ruleset created in steps 1 and 2.
The paths must be specified according to the rules for exclude paths.

Page 4 of 14 SNOWSOFTWARE.COM
The agent traverses the file system in accordance with the created rule set. Beginning
from each defined starting point, it scans the locations specified by the include path and
any added global extensions, skipping locations specified by any matching exclude path.

NOTE
In addition to the paths specified in Software/Include and Software/Exclude in the
configuration file, there are other criteria affecting the selection of files to include in the
scan. The criteria are described in the user guide for the respective agent.

2.1.1 RULES FOR INCLUDE PATHS

An include path:

▪ Must be an absolute path, that is, begin with a drive letter (c:, d: etc.) or root (/).

▪ Can include a wildcard: '*'

◦ At most one wildcard may be used per directory.

◦ Exactly one wildcard must be used in file names.

If the wildcard is not included, it will not be treated as a file name.
Example: /folder1/folder2 means /folder1/folder2/* while /folder1/
folder2* means all files beginning with folder2 in /folder1.

▪ Is not recursive. If a recursive scan is desired, then it must be specified when

added.
Example:
/folder1/folder2 will only result in /folder1/folder2 being scanned, not the
subdirectories of /folder1/folder2.
<Path recursive="true">/folder1/folder2 will result in the subdirectories of /
folder1/folder2 being scanned.

EXAMPLE
Include path examples

▪ c:\Windows, same as c:\Windows\*

▪ c:\program files\*

▪ c:\, same as c:\*

▪ /usr/local, same as /usr/local/*

▪ /usr/*/bin, same as /usr/*/bin/*

2.1.2 RULES FOR EXCLUDE PATHS

Exclude paths follow the same rules as include paths, with the exception that they are
recursive.

EXAMPLE
Exclude path examples
Given the include-pattern /folder1/folder2/* and exclude-pattern of /folder1/
folder2/a, the entire directory /folder1/folder2/a would be excluded, but any other
directory under /folder1/folder2/ would be included.

Page 5 of 14 SNOWSOFTWARE.COM
Given the include-pattern /folder1/*/folder2 and exclude-pattern /folder1/b/
folder2, /folder1/a/folder2 and /folder1/c/folder2 would be scanned, but not /
folder1/b/folder2.

Given the recursive include-pattern /folder1 and exclude-pattern /folder1/*/

folder2, /folder1/a/folder2 and /folder1/c/folder2 would be excluded while /
folder1/a/a and /folder1/b/b would be included.

Just as for includes, excludes can specify file name patterns like *.dll.

2.1.3 GLOBAL EXTENSION LIST

Any content in Software/Include that does not begin with a drive letter (c: ) or root (/),
does not include a path separator (\ or /), and includes a wildcard is considered to be a
file name extension and is placed in the global extension list. The contents of the global
extension list are applied to the leaf nodes of the tree.

Specifying a file name extension pattern causes paths, such as /a/*, to no longer include
all files, but only those that have any of the specified file extensions. The exception to this
rule is an extension/wildcard in a path, like /folder1/folder2/*.py, which adds all .py-
files in /folder1/folder2.

EXAMPLE
File name extension examples

▪ *.py

▪ *.exe

▪ *abc.txt - Files ending in "abc.txt"

▪ def* - Files beginning with "def"

Page 6 of 14 SNOWSOFTWARE.COM
3 ORACLE DATABASE PRODUCTS
NOTE

▪ Inventory of Oracle database products is only available for the Snow Inventory
Agents for Linux, Unix, and Windows

The Snow Inventory Agent can perform inventory of Oracle database products. Automatic
discovery and inventory of all Oracle instances on the computer is achieved by the Snow
Inventory Oracle Scanner (SIOS).

NOTE
SIOS requires Java Runtime Environment 6.0 (1.6) or later to be installed. Due to an
internal defect in Java, Java Runtime Environment 1.7.0_7 must not be used.

When Oracle scan is enabled in the configuration, the agent will be triggered to run SIOS
as part of the inventory process, and automatically perform an inventory of all Oracle
database instances found. For information on advanced configuration options for the
Oracle database inventory, see Snow Inventory Oracle Scanner.

If multiple versions of Java are installed on a computer and the default Java version
available in the path is not version 1.6 or later, the system setting named
env.java_home in the configuration file can be used to specify the location to the Java
installation to use. The agent will then try to run Java using the following path to the
executable. Examples:

▪ Linux and Unix: <Setting key="env.java_home" value="/usr/bin/java"/>

▪ Windows: <Setting key="env.java_home" value="C:\Program Files\Java

\jre1.8.0_111"/>

This setting controls the Java version of the SIOS, and is applicable to the Windows and
Linux agents.

Page 7 of 14 SNOWSOFTWARE.COM
4 OUTPUT DATA
The output of the inventory scan is an encrypted and compressed file containing inventory
data, meta-information on the inventoried client, current configuration file of the agent
(snowagent.config), and any critical events from the agent log.

The output file will be placed in the data subdirectory if no other output path has been
specified in the configuration.

Page 8 of 14 SNOWSOFTWARE.COM
5 SERVER ENDPOINTS AND DROP
LOCATIONS
The agents can deliver the encrypted files in different ways, for example over HTTPS,
which is the most common (and recommended) way, or by writing the result to a file
share. For this, server endpoints and drop locations are configured.

5.1 SERVER ENDPOINT

A server endpoint represents a possible path for delivery. The Snow Inventory Agent
establishes a connection and sends the output file to an Inventory server endpoint defined
in the configuration. When several endpoints have been defined, the agent randomly
selects one from the list. It tries at least once for each endpoint. As soon as it has
successfully managed to negotiate a connection it will use that one for the remainder of
the session.

NOTE
The more server endpoints defined in the agent configuration, the longer it will take to
negotiate a connection. This is typically not an issue but when writing scripts, keep in
mind that it may introduce a significant delay since the agent has to timeout on a bad
server endpoint configuration before it can try the next one.

5.1.1 CONFIGURING THE AGENT FOR PUBLIC KEY PINNING

Public key pinning prevents man-in-the-middle attacks from occurring on the
communication link between agents and Snow Inventory endpoints, such as Snow
Inventory Server or a service gateway. It is recommended to enable the public key pinning
feature by default to ensure security of data in transit and fully mitigate potential man-in-
the-middle attacks.

During initial communication establishment between an agent and an endpoint, the agent
checks whether the encoded hash key of the endpoint matches the expected key, stored
as a hash value in the agent configuration file (default snowagent.config). If the values
match, communication is established, and dropped otherwise.

The recommended steps, with example OpenSSL commands:

1. Open a communication link with the endpoint

openssl s_client -servername www.invserver.com -connect
www.invserver.com:443 < /dev/null | sed -n "/-----BEGIN/,/-----END/p"
> www.invserver.com.pem
2. Extract the public key from the endpoint’s certificate in – often in pem format
openssl x509 -in www.invserver.com.pem -pubkey -noout >
www.invserver.com.pubkey.pem
3. Convert the public key from pem to the appropriate format for the local operating
system
openssl asn1parse -noout -inform pem -in www.invserver.com.pubkey.pem
-out www.invserver.com.pubkey.der
4. SHA 256 hash and base-64 encode the key in the local format

Page 9 of 14 SNOWSOFTWARE.COM
 openssl dgst -sha256 -binary www.invserver.com.pubkey.der | openssl
base64
5. Add the following code to snowagent.config file:

<Endpoint>
<Address>...</Address>
<Proxy>...</Proxy>
<ClientCertificate>...</ClientCertificate>
<ServerPublicKeyHash>sha256//<---encoded key ---></ServerPublicKeyHash>
</Endpoint>

5.2 DROP LOCATION

A drop location represents an additional location for delivery of the scan result. It can be
network folder, an HTTP endpoint, or an UNC file path. If several one drop locations have
been defined, the scan result will be sent to all of them.

NOTE
If the agent cannot reach a drop location during the send activity, it will not try to
resend the file later.

Page 10 of 14 SNOWSOFTWARE.COM
6 SECURITY

6.1 ENCRYPTION OF PASSWORDS

Passwords used in the configuration file are automatically encrypted when the
configuration file is managed via the Snow Inventory Admin Console.

6.2 DATA ANONYMIZATION OPTIONS

The Snow Inventory Agent can be configured to send anonymous user data from the
inventoried computer. It can also be configured not to inventory any IP addresses assigned
to the network interfaces of the computers.

6.2.1 ANONYMOUS USER DATA

Both usernames of logged on users and usernames within the software metering (i.e.
users who have used applications on the computer) can be replaced with SHA-1 hash. The
same encrypted string will be used for the same user each time, even if the user uses
multiple computers, no duplicate entries are created.

To enable the anonymous user data option, the following system setting needs to be
added to the configuration file:

privacy.hide_user=true

EXAMPLE
Default setting (not anonymous)

With privacy.hide_user=true (anonymous)

6.2.2 ANONYMOUS IP ADDRESSES

The IP addresses assigned to the network interfaces of the computer can be replaced with
SHA-1 hash. Add the following system setting to the configuration file:

privacy.hide_ip=true

Page 11 of 14 SNOWSOFTWARE.COM
NOTE
When this option is enabled, it is not possible to use Auto Connect Rules in Snow
License Manager based on computer IP addresses for allocation of computers to
different units in the organization structure. However, other criteria can still be used for
Auto Connect Rules, such as computer hostnames and site names.

6.3 COMMUNICATION
It is possible to use any combination of X.509 certificates to secure and authenticate
communication between the agent and the server.

If the server certificate has been issued by a trusted root certificate authority (CA), no
additional configuration is required other than to configure the agent to use the HTTPS (or
HTTP) URI scheme.

6.3.1 SELF-SIGNED OR SELF-ISSUED CERTIFICATES

If a self-signed or self-issued certificate is used to secure communication, i.e. a certificate
that is not installed in the trusted root certificate store of the computer, the agent needs
to be configured to ignore warnings about unknown CA’s. Use the following system setting
in the configuration:

http.ssl_verify=false

This setting is disabled by default.

NOTE
The system setting http.ssl_verify=false does not work on Mac OS X 10.8. Even if
the setting is set to false, the agent will still try to verify the server’s CA certificate.

NOTE
Read Configuring the agent for public key pinning for more security-related information
in regards to certificates.

6.3.2 CLIENT AUTHENTICATION USING CERTIFICATES

The Snow Agent supports use of client certificates. The certificates need to be password
protected, and the password must be stored (encrypted) in the agent configuration file.

A common practice is to distribute the client certificate alongside the agent as part of the
update package. The agent is then configured to look for a certificate.pfx file that
contains the client certificate for client authentication and use that (provided it has the
correct password).

If the server endpoint is used with a client certificate and the password does not match,
an error is generated in the snowagent.log. The agent will continue with other server
endpoint configurations, if any have been set.

NOTE
Specify one client certificate per server endpoint. It is possible to have multiple entries
for the same server endpoint with different client certificates

Page 12 of 14 SNOWSOFTWARE.COM
6.3.3 COMMUNICATION USING TLS
To be able to use Transport Layer Security (TLS) 1.2 for the communication between the
Inventory agent and the Inventory server, the following requirements need to be met:

▪ The Windows operating system of the Inventory server (both Master Server and
Service Gateway) must be updated to enable the TLS 1.2 protocol for SHA512
certificates. See article https://support.microsoft.com/en-us/help/2973337/sha512-
is-disabled-in-windows-when-you-use-tls-1-2.

▪ Windows agent
The root certificate (.cer) must be installed in the Trusted Root Certification
Authorities of the computer to be inventoried.

▪ Linux and macOS agents

In the configuration file of the agent, the setting <Setting key="http.ssl_capath"
value="" /> must point to the certificate file (.pem).

▪ Unix agent
The certificate file (.cer) needs to be put in the /opt/snow/ directory of the
computer to be inventoried.
If the "RSA premaster secret error" entry is shown in the log, the components
local_policy.jar and US_export_policy.jar need to be updated in Java.

Page 13 of 14 SNOWSOFTWARE.COM
7 TROUBLESHOOTING

7.1 VERIFY COMMUNICATION

If a computer with the Snow Agent installed is unable to send inventory result to the
server, the following steps can be performed.

From a command prompt, use the following command to run a self-test that checks server
connectivity, and then exits with a 0 (if successful) or a non-zero exit code:

snowagent.exe test

- or -

snowagent test

Page 14 of 14 SNOWSOFTWARE.COM