Credentials Requirements for Discovery

For the Tripl-i Scanner Agent to perform deep, authenticated scans of your infrastructure, it requires appropriate credentials for your target systems. This guide outlines the necessary credentials and best practices for managing them securely.

Credential Management and Security

Credential management is a critical aspect of the discovery process. The Tripl-i Scanner Agent is designed with security as a priority.

• Local Storage: Credentials are configured within the Credentials tab of the Tripl-i Scanner Agent application.
• Strong Encryption: All credentials are encrypted using the Windows Data Protection API (DPAPI). This means they are encrypted at rest and tied to the specific user account or machine running the agent.
• No Central Storage: Credentials are never sent to or stored on the central Tripl-i platform, ensuring they remain within your network boundary.

---

Requirements by Target System

Below are the specific credential requirements for each type of system you wish to scan.

Windows Systems (via WMI)

To collect a full inventory of Windows servers and workstations, the agent requires an account with administrative privileges on the target machines.

• Required Privileges: Local Administrator
• Recommended Account: For ease of management across a domain, using a Domain Administrator account or a dedicated service account that is a member of the local administrators group on all target machines is recommended.
• Username Format:
  • For domain accounts: DOMAIN\username or username@domain.com
  • For local accounts: .\username (when scanning a non-domain machine)

Linux/Unix Systems (via SSH)

To scan systems running Linux or other Unix-like operating systems, the agent requires an SSH-enabled user account.

• Required Privileges: An account that can authenticate via SSH.
• Recommended Privileges: For a complete inventory (including hardware details like serial numbers and memory modules), selective passwordless sudo is recommended. Full root access is not required — you can grant sudo for only the specific commands the scanner needs.
• Authentication Methods: Both password-based and SSH key-based authentication are supported. For key-based authentication, ensure the private key is accessible to the scanner agent.
• Graceful Degradation: The scanner collects whatever data is available at the current privilege level. Commands that fail due to insufficient permissions are silently skipped — the scan never fails.

For the full list of commands executed, sudoers configuration, and selective privilege setup, see the SSH Scanning Reference guide.

Network Devices (via SNMP)

For discovering and inventorying network hardware like switches, routers, and firewalls.

• SNMPv1/v2c: A valid Community String with read access.
• SNMPv3: A user account with appropriate security level (e.g., authPriv) for authenticated and encrypted communication.
• Recommendation: Use SNMPv3 wherever possible, as it is significantly more secure than older versions.

VMware vCenter

For discovering your virtualized environment, including ESXi hosts, clusters, and virtual machines.

• Required Privileges: A user account for the vCenter server.
• Recommended Account: A dedicated service account with Global read-only permissions is sufficient for discovery and is a security best practice. An administrator account is not required.

SQL Server Databases

SQL Server database discovery uses the same credentials as Windows WMI scanning. No separate SQL credentials are required.

• Authentication Method: Windows Authentication - The scanner uses the WMI scanning account to authenticate to SQL Server.
• Required Configuration: The WMI scanning account must have a SQL Server login created from the Windows account.

SQL Server Permission Levels

The amount of data collected depends on the permissions granted:

Permission Level	What's Discovered
Basic (public only)	Instance name, version, edition
Standard	+ Memory config, connections, services, encryption
Full	+ All databases, backup status, linked servers

Recommended SQL Server Permissions

For comprehensive database discovery, grant the following permissions to your scanning account:

Permission	Purpose
VIEW SERVER STATE	Server-level metrics, connections, encryption status
VIEW ANY DATABASE	List all databases on the instance
VIEW ANY DEFINITION	Linked server discovery
db_datareader on msdb	Backup history and dates

Setting Up SQL Server Permissions

Your SQL Server administrator needs to configure the following on each SQL Server instance for the scanning account:

1. Create a SQL Server login from the Windows domain account used for scanning
2. Grant server-level permissions on the master database:
   • VIEW SERVER STATE
   • VIEW ANY DATABASE
   • VIEW ANY DEFINITION
3. Grant msdb read access for backup history:
   • Create a database user in msdb for the scanning login
   • Add the user to the db_datareader role

All permissions are read-only — the scanning account cannot modify data or configuration. Use your organization's Windows scanning service account (e.g., DOMAIN\ScanAccount).

For detailed information, see the SQL Server Database Discovery Reference.

PostgreSQL Databases

PostgreSQL discovery runs automatically during SSH scans when PostgreSQL is detected. No separate credentials are required in most cases.

• Default Authentication: The scanner uses peer authentication via sudo -u postgres psql. This works when the SSH scanning account has sudo access.
• Optional Credentials: If sudo is not available, configure PostgreSQL credentials in the Credentials tab:
  • Protocol: PostgreSQL
  • Fields: Username, Password, Port (default: 5432)

PostgreSQL Permission Levels

Permission Level	What's Discovered
Superuser (peer auth)	Full: instances, all databases, connections, extensions, replication
pg_read_all_stats role	Instances, databases, connections, replication
Basic (CONNECT only)	Instance version and database list

For detailed information, see the PostgreSQL Database Discovery Reference.

MySQL/MariaDB Databases

MySQL and MariaDB discovery runs automatically during SSH scans when MySQL/MariaDB is detected. The scanner automatically distinguishes between MySQL and MariaDB. No separate credentials are required in most cases.

• Default Authentication: The scanner uses unix socket authentication via sudo mysql. This works on most modern MySQL 5.7+ and MariaDB 10.4+ installations when the SSH account has sudo access.
• Optional Credentials: If sudo is not available, configure MySQL credentials in the Credentials tab:
  • Protocol: MySQL
  • Fields: Username, Password, Port (default: 3306)

MySQL Permission Levels

Permission Level	What's Discovered
Root (socket auth)	Full: instances, all databases, connections, replication
SELECT + PROCESS	Instances, databases, connections
Basic (SELECT on information_schema)	Instance version and database list

For detailed information, see the MySQL/MariaDB Database Discovery Reference.

Oracle Databases

Oracle Database discovery runs automatically during SSH scans when Oracle is detected via running processes or /etc/oratab. All instances on the server are discovered automatically. No separate credentials are required when the SSH account has sudo access to the oracle OS user.

• Default Authentication: The scanner uses OS authentication via sudo su - oracle -c "sqlplus -S / as sysdba". This provides SYSDBA access without storing database passwords.
• Optional Credentials: If sudo is not available, configure Oracle credentials in the Credentials tab:
  • Protocol: Oracle
  • Fields: Username, Password, Port (default: 1521), SID/Service Name

Oracle Permission Levels

Permission Level	What's Discovered
SYSDBA (OS auth)	Full: instances, PDBs, tablespaces, connections, Data Guard
SELECT on v$ views	Instances, connections, basic configuration
Process detection only	Instance name and version (from process list)

For detailed information, see the Oracle Database Discovery Reference.

---

Security Best Practices

Follow these best practices when configuring credentials for discovery.

• Use the Principle of Least Privilege: Always provide the minimum level of access required. For example, use a read-only account for vCenter discovery.
• Create Dedicated Service Accounts: Instead of using named user accounts (e.g., a personal administrator account), create dedicated service accounts for scanning. This improves auditability and security.
• Limit Credential Scope: Within the scanner agent's credential configuration, associate credentials with specific IP ranges. This prevents the agent from attempting to use a credential on an unintended network segment.
• Implement Credential Rotation: Adhere to your organization's security policy for rotating passwords, community strings, and SSH keys. Remember to update them in the scanner agent when they change.
• Monitor Authentication Logs: Regularly review scan logs for authentication failures. A high number of failures could indicate an incorrect password, an expired key, or a network access issue.