User Management

NetXMS has a built-in user management system that controls access to the monitoring infrastructure. This page covers how to create user accounts and groups, configure authentication methods, and set up access control.

For reference tables (access rights, configuration variables, certificate mapping), see User Management Reference.

Creating Users

To create a new user:

  1. Open the management client

  2. Navigate to Configuration > Users and groups

  3. Right-click and select Create new user…​

  4. Enter the login name

  5. Check Define additional properties to open the property pages, where the full name, authentication method, password, and group membership are set

Each user account has the following properties:

  • Login name — unique identifier for authentication

  • Full name — display name

  • Description — optional description

  • Authentication method — one of Local password, RADIUS password, Certificate, Certificate or local password, Certificate or RADIUS password, or LDAP password

  • System access rights — global permissions (see System Access Rights Reference)

  • Group membership — user can belong to multiple groups

Default Administrator Account

The default administrator account has the login admin (user ID 1). During database initialization, nxdbmgr init generates a random password for this account and prints it to the console; alternatively, a specific password can be set with the -p option of nxdbmgr init.

Record the generated admin password during installation — it is displayed only once.

The admin account receives its access rights through membership in the Admins group and, like any regular account, can be deleted — only the system account (user ID 0) and the Everyone group are protected from deletion.

The database also contains two additional built-in accounts: anonymous (user ID 2) and ai-operator (user ID 3).

Superuser Account

NetXMS has a built-in superuser account with internal ID 0 and login name system. This account is disabled by default. It is used internally by the server for operations that require full system access (scheduled tasks, background jobs, etc.). To allow interactive login with this account, run nxdbmgr reset-system-account, which unlocks it and sets a new random password (printed to the console).

The superuser account:

  • Always has full access to all objects (hardcoded); its system access rights are taken from its database record

  • Cannot be deleted

  • Should remain disabled unless specifically needed for recovery or troubleshooting

Account Lockout

NetXMS can automatically lock accounts after repeated failed login attempts. Configure lockout through the Server.Security.IntruderLockoutThreshold and Server.Security.IntruderLockoutTime server variables. See Account Lockout Variables for details.

A locked account can be unlocked from the command line with nxdbmgr unlock-user <login>.

Password Policy

NetXMS enforces password policies through server configuration variables, such as Server.Security.MinPasswordLength and Server.Security.PasswordExpiration. These policies apply to locally-authenticated users (not LDAP or RADIUS). See Password Policy Variables for all available settings.

Users can be marked with User must change password at next logon to force an immediate password change.

User Groups

Groups simplify permission management by allowing you to assign access rights to a group instead of individual users.

Built-in groups:

  • Admins — full system access. Members have all system rights.

  • Everyone — all authenticated users are automatically members. By default the group carries a small set of system rights: view event templates, view all alarms, and use the AI assistant.

To create a custom group:

  1. Navigate to Configuration > Users and groups

  2. Right-click and select Create new group…​

  3. Add members from existing user accounts

How to Configure LDAP Integration

NetXMS can synchronize users and groups from an LDAP directory (Active Directory, OpenLDAP, etc.). Configure LDAP integration through server configuration variables (see LDAP Configuration Variables).

Active Directory Example

LDAP.ConnectionString = ldap://dc01.example.com:389
LDAP.SyncUser = [email protected]
LDAP.SyncUserPassword = service_password
LDAP.SearchBase = OU=Users,DC=example,DC=com
LDAP.SearchFilter = (&(|(objectClass=user)(objectClass=group))(!(userAccountControl:1.2.840.113556.1.4.803:=2)))
LDAP.UserClass = user
LDAP.GroupClass = group
LDAP.Mapping.UserName = sAMAccountName
LDAP.Mapping.FullName = displayName
LDAP.UserUniqueId = objectGUID
LDAP.GroupUniqueId = objectGUID
LDAP.SyncInterval = 60

OpenLDAP Example

LDAP.ConnectionString = ldap://ldap.example.com:389
LDAP.SyncUser = cn=admin,dc=example,dc=com
LDAP.SyncUserPassword = admin_password
LDAP.SearchBase = dc=example,dc=com
LDAP.SearchFilter = (objectClass=*)
LDAP.UserClass = inetOrgPerson
LDAP.GroupClass = groupOfNames
LDAP.Mapping.UserName = cn
LDAP.Mapping.FullName = displayName
LDAP.UserUniqueId = entryUUID
LDAP.GroupUniqueId = entryUUID
LDAP.SyncInterval = 1440

Synchronization

When LDAP sync runs, NetXMS:

  1. Queries the LDAP directory for users and groups matching the filters

  2. Creates new NetXMS users/groups for any LDAP entries not already present

  3. Updates attributes (full name, description, group membership) for existing entries

  4. Disables or deletes NetXMS users whose LDAP accounts have been removed (controlled by LDAP.UserDeleteAction)

Synchronization only removes LDAP-synced users that are no longer present in the directory. Non-LDAP users added manually to LDAP-synchronized groups are left untouched.

LDAP-synced users are marked with the LDAP flag and authenticate against the LDAP directory. The authentication is transparent to the user — they use their LDAP username and password to log in.

To trigger a manual sync, use the server debug console:

ldapsync

LDAP Troubleshooting

If LDAP synchronization does not work as expected:

  1. Enable LDAP debug logging by setting the debug tag ldap to level 7 in the server configuration:

    DebugTags = ldap:7

  2. Check the server log for LDAP-related messages. Common issues include:

    • Connection errors: Verify LDAP.ConnectionString is reachable and the port is correct. For ldaps://, ensure the server’s SSL certificate is trusted.

    • Authentication errors: Verify LDAP.SyncUser and LDAP.SyncUserPassword. For Active Directory, use UPN format ([email protected]) or full DN.

    • Empty results: Check LDAP.SearchBase and LDAP.SearchFilter. Use an LDAP browser (such as Apache Directory Studio) to verify the filter returns expected results.

    • Users not created: Verify LDAP.UserClass matches the actual object class in your directory.

    • Group membership not synced: Verify LDAP.GroupClass is correct and that the group objects are within the LDAP.SearchBase scope.

  3. Use the server debug console to run an immediate sync and observe the results:

    ldapsync

How to Configure Two-Factor Authentication

NetXMS supports two-factor authentication (2FA) for additional login security. Two drivers are available: TOTP (Time-based One-Time Password) and Message (notification channel-based).

System-Wide 2FA Setup

Before users can use 2FA, at least one 2FA method must be configured at the system level:

  1. Navigate to Configuration > Two-factor authentication methods

  2. Create a new 2FA method

  3. Select the driver:

    • TOTP — generates time-based one-time passwords using applications like Google Authenticator, Microsoft Authenticator, or FreeOTP

    • Message — sends a one-time code through a configured notification channel (SMS, email, Telegram, etc.)

  4. For the Message driver, select the notification channel from the Notification channel drop-down in the method configuration

  5. Save the method

Multiple 2FA methods can be configured. Users will be able to choose which method to use during login.

Per-User 2FA Configuration

To enable 2FA for a user:

  1. Navigate to Configuration > Users and groups

  2. Open the user’s properties

  3. Go to the Authentication property page and find the Two-factor authentication methods group

  4. Add one or more 2FA method bindings

  5. For the Message method, specify the recipient (phone number, email address, etc.) and the message subject

  6. For the TOTP method, no additional configuration is needed at this step

When 2FA is configured for a user, they will be prompted for a second factor on their next login.

TOTP Initialization

When a user with TOTP 2FA logs in for the first time after TOTP is configured:

  1. The server generates a secret key and presents a QR code

  2. The same enrollment data is also shown as text (an otpauth:// URI containing the secret) for manual entry

  3. The user scans the QR code or enters the secret into their TOTP application

  4. The user enters the generated numeric code to confirm correct setup

  5. On subsequent logins, the user enters the current TOTP code from their application

Resetting TOTP

If a user loses access to their TOTP application:

  1. An administrator opens the user’s properties in Configuration > Users and groups

  2. In the Two-factor authentication methods group on the Authentication property page, reset the TOTP binding

  3. On the user’s next login, they will be presented with a new QR code and secret to set up their TOTP application again

2FA Enforcement

Two-factor authentication can be enforced at the group level: enable the Enforce two-factor authentication for group members option in a group’s properties to require 2FA for all its members. Alternatively, setting the Server.Security.2FA.EnforceForAll server configuration variable enforces 2FA for every user regardless of group membership.

Individual users can be excluded from enforcement with the Exempt from two-factor authentication enforcement flag in their account properties (useful for service accounts).

How to Configure RADIUS Authentication

NetXMS supports RADIUS as an external authentication method. When RADIUS authentication is selected for a user, passwords are sent to a RADIUS server for validation. Access is granted when the server responds with Access-Accept.

Configure RADIUS through server configuration variables (see RADIUS Configuration Variables).

To enable RADIUS for a user, set their authentication method to RADIUS password in the user properties dialog. Users can also be configured with Certificate or RADIUS password authentication, which attempts certificate validation first and falls back to RADIUS.

How to Configure Certificate Authentication

NetXMS supports certificate-based authentication using X.509 client certificates. This method can be used with smart cards or software certificates stored in the operating system’s certificate store.

Login Process

Certificate-based login works as follows:

  1. Server sends a random challenge to the client

  2. Client signs the challenge using the private key associated with the certificate

  3. Client sends the signed challenge and the public part of the certificate back to the server

  4. Server validates the certificate against configured trusted CA certificates

  5. Server verifies the challenge signature using the certificate’s public key

  6. Server maps the certificate to a NetXMS user account using the configured mapping method

  7. If the mapping matches, access is granted

Trusted CA Certificates

For certificate authentication to work, the CA certificate that issued the client certificate must be added to the server’s trusted certificate store. CA certificates are configured using the TrustedCertificate parameter in the server configuration file (netxmsd.conf):

TrustedCertificate = /path/to/ca-certificate.pem

Multiple TrustedCertificate entries can be specified to trust certificates from multiple CAs.

User Configuration

To configure a user for certificate authentication:

  1. Open the user’s properties in Configuration > Users and groups

  2. Set the authentication method to one of: Certificate, Certificate or local password, or Certificate or RADIUS password

  3. Select the certificate mapping method — Subject, Public key, or Common name (see Certificate Mapping Methods)

  4. Enter the certificate mapping data

  5. Save the user properties

When using Certificate or local password or Certificate or RADIUS password, the server first attempts certificate validation. If no certificate is presented or validation fails, it falls back to the alternative method.

How to Configure CAS Authentication

The NetXMS server can validate Central Authentication Service (CAS) tickets for single sign-on. The bundled management clients do not offer CAS login; the mechanism is intended for custom integrations built on the client library, which accepts an SSO ticket in place of a password.

Configure CAS integration through server configuration variables (see CAS Configuration Variables).

How to Configure UI Access Rules

UI access rules allow administrators to hide specific user interface elements from users or groups. This controls which perspectives, views, and UI components are visible in the management client.

UI access rules control visibility only. They are not a security mechanism — users with appropriate system or object access rights can still perform operations through the API or nxshell even if the corresponding UI element is hidden.

Rule Format

UI elements are identified using the format category:name. Common categories include:

  • perspective:name (short form p:name) — management client perspectives (e.g., perspective:objects.maps)

  • view:name (short form v:name) — views and tabs within perspectives (e.g., view:objects.fdb)

  • *:name — matches elements of the given name in any category

Rules support GLOB-style wildcards:

  • * matches all UI elements

  • perspective:* matches all perspectives

A rule can be prefixed with ! to exclude the matched elements, or with ^ to create a priority inclusion that overrides exclusion rules.

See UI Access Rule Evaluation for prefix types and evaluation order.

Default Configuration

By default, both the Everyone and Admins groups have the inclusion rule *, which makes all UI elements visible to all users. To restrict UI access, adjust these default rules and add specific rules per group or user (removing only the Everyone rule still leaves members of Admins unrestricted).

Example: restrict a group to only see the Dashboards and Alarms perspectives
perspective:objects.dashboards
perspective:alarms
Example: show everything except the Configuration perspective
*
!perspective:configuration

How to Configure Audit Logging

NetXMS logs all significant user actions to an audit log. Two logging modes are available and can be used simultaneously.

Internal Audit Log

The internal audit log stores records in the NetXMS database. It is enabled by default and viewable through the management console under Logs > Audit.

External Audit Log

For compliance or integration with centralized log management, audit records can be sent to an external syslog server via UDP.

To enable external audit logging, set AuditLog.External.Server to the hostname or IP address of your syslog server. Both internal and external logging can be active simultaneously.

See Audit Log Variables for all configuration options.

Each audit record includes:

  • Timestamp

  • Subsystem identifier

  • Success or failure indicator

  • User ID

  • Workstation address

  • Session ID

  • Object ID (if applicable)

  • Action description

  • Old and new values (for configuration changes)

  • HMAC of the record content for tamper detection — populated only when a signing key is configured with the AuditLogKey parameter in netxmsd.conf; empty by default

Authentication Tokens

Authentication tokens allow logging in without a password — as Bearer tokens for the web API, with the -token option for management client autologin (see below), and in any integration built on the client library.

Each user can manage their own tokens: open the user menu in the management client and select Authentication tokens…​. The dialog lists the user’s tokens (ID, description, creation and expiration time) and provides Issue New…​ and Revoke buttons. When issuing a token, set a description and expiration time; the token value is displayed only once, with a button to copy it to the clipboard — it cannot be retrieved later.

Administrators can manage any user’s tokens on the Authentication Tokens property page of the user’s properties in Configuration > Users and groups.

Tokens issued this way are persistent: they are stored (hashed) in the database and survive server restarts until they expire or are revoked. Integrations using the API can also request single-use tokens, which are invalidated on first successful use.

How to Configure Autologin

The management client supports automatic login using a pre-configured login token. This is useful for kiosk displays, NOC screens, and unattended dashboards.

Configuring Autologin

  1. Create a dedicated user account with minimal permissions (read-only access to necessary dashboards)

  2. Start the management client with autologin parameters as command-line arguments:

Password-based autologin
nxmc -auto -server=<server_address> -login=<username> -password=<password>
Token-based autologin (recommended)
nxmc -auto -server=<server_address> -token=<token>

A login token identifies the user, so no login name or password is needed; when both -token and -password are given, whichever comes last on the command line takes effect.

The same settings can be supplied as JVM system properties instead of command-line arguments: netxms.server, netxms.login, netxms.password, netxms.token, and netxms.autologin.

Security Considerations for Autologin

Autologin with -password stores credentials in the command line, which may be visible to other users on the system. Prefer token-based autologin.

Best practices:

  • Create a dedicated account with minimal permissions for each autologin deployment

  • Restrict the account to read-only access on specific dashboards

  • Use token-based autologin instead of embedding a password

  • Avoid using administrative accounts for autologin