- About LogicMonitor
- Cloud Monitoring
- Dashboards and Widgets
- Getting Started
- Implementation Readiness
- I just signed up for LogicMonitor, now what?
- Advanced LogicMonitor Setup
- LogicMonitor Security Best Practices
- Defining Authentication Credentials
- Adding devices when they boot
- Network scanning for additional devices
- Credentials for Accessing Remote Windows Computers
- Why am I receiving account lock out alerts?
- Running without Administrator Privileges in Windows
- How do I get support resources?
- LM Service Insight
- Rest API Developers Guide
- RPC API Developers Guide - Deprecated
- Servicenow CMDB Integration
- Terminology and Syntax
Using Properties to Set Credentials
LogicMonitor may require credentials (e.g. JDBC passwords, SNMP community strings, etc.) in order to collect data from your devices. You can use properties to set this information at the global, group, or device level.
Before you set properties for your devices, you should understand where to set them, which depends on how many devices that property applies to. For example, if you have the same SNMP community string set for all of your Linux devices, it doesn’t make sense to go and set that as a property individually for each Linux device in your account. It may be better to instead set this community string at the account level so that it applies to all Linux devices.
Note: For strategies and instructions on where and how to set properties, see Resource and Instance Properties.
The following table lists many predefined properties that can be used to store credentials (and authentication details) for various common protocols and systems.
Note: Any values assigned to properties with names ending in .pass, .auth, .key, or password will be obfuscated throughout the LogicMonitor interface for security purposes. Values assigned to the snmp.community, snmp.privtoken, and snmp.authtoken properties, as well as the aws.accesskey property, will also be obfuscated.
Defining SNMP Credentials and Properties
LogicMonitor can use SNMP versions 1, 2c or 3. If your device supports 2c, it supports 64-bit counters and is preferable over version 1. SNMPv3 adds authentication and encryption, making it more secure, but also more complicated to set up and troubleshoot.
- On an individual device, snmp.version is automatically set by LogicMonitor to the version of SNMP which responds. LogicMonitor attempts SNMP communication initially with version 3, then 2c, and finally version 1. The highest responding version is set for this value, and any attempts to edit it will automatically revert.
- If you attempt to change the SNMP version after initial device addition (by entering new credentials), you must ensure it and the pertinent credentials function. If LogicMonitor is not able to communicate using the new version specified, it will automatically revert to the original version as a result of the failure.
- If you want to override the default UDP 161 port, set snmp.port (defined in the table above) to reflect your SNMP port.
SNMP Versions 1 and 2c
For SNMP versions 1 and 2c, you need to set the snmp.community property (defined in the table above).
SNMP Version 3
For SNMPv3, to communicate with authentication and privacy (referred to as authPriv security level), you need to set the snmp.security, snmp.auth, snmp.authToken, snmp.priv, and snmp.privToken properties (all defined in the table above).
If communicating with authentication only (no privacy), referred to as authNoPriv, include the snmp.priv and snmp.privToken properties, but leave them blank.
SNMPv3 also introduces support for snmp.contextName and snmp.contextEngineID. The snmp.contextEngineID value is a string used to identify the device on which the management information is hosted. The snmp.contextName identifies the individual SNMP context.
In this Article: