Skip to main content
LogicMonitor is an infrastructure monitoring platform. Connect your LogicMonitor portal to Oleria to see who can sign in to it and how, which roles they hold, and what those roles reach across your resource, website, dashboard, report, and collector groups. You also see which reports are emailed to people outside LogicMonitor, and the API-only users, API tokens, and collectors that act on the portal without a person at the keyboard. Oleria reads this data from the LogicMonitor REST API with an API token of a dedicated API-only user, and can take remediation actions with the same token. One Oleria integration covers one LogicMonitor portal, such as acme.logicmonitor.com. To connect another portal, add another integration. See Multi-instance support.

​
What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your LogicMonitor portal.

​
Users, user groups, and roles

  • Accounts - every LogicMonitor user, with name, username, email, and status. Suspended users show as disabled. A user with no first or last name is shown by username.
    • Last activity - the most recent of the user’s last action, last sign-in, and last access, and the last use of any API token the user owns.
    • Administrators - users who hold the built-in administrator role, or a role with Manage on all Settings or on User Access, are marked as administrators. Manage on only a user’s own personal information or API tokens doesn’t count.
    • MFA - checked in this order: API-only users show MFA as not applicable. A user with two-factor authentication turned on shows MFA as required. Otherwise, a user shows as needing to enroll when the portal, or one of the user’s roles, requires two-factor authentication. Otherwise, users created through SAML sign-in show MFA as unavailable, because your identity provider enforces it, and all other users show MFA as not required.
    • SSO and sign-in methods - users created through SAML sign-in show SSO as configured and sign in with SSO. Other users sign in with a password, and their SSO status shows as unavailable (see Known limitations). API-only users have no password, and their SSO status shows as not applicable. Users who own an enabled API token also show token sign-in and API access.
    • Account role - each user’s highest-ranked role is shown as their account role, and their other roles as secondary account roles. From highest to lowest: administrator, custom roles with administrator access, manager, other custom roles (those with more Manage permissions first), ackonly, and readonly.
    • LogicMonitor Support - the lmsupport user that LogicMonitor creates for its Support team is shown as an external user.
    • Creator and profile details - when LogicMonitor names another user as the creator, that user is linked as the creator. Oleria also keeps the creator as LogicMonitor records it (a user, SAML, or LogicMonitor), the user type, whether a password change is forced, the IP address of the last sign-in, phone, notes, and the user’s view permissions.
  • User groups - every user group, with its name, description, and members. Ungrouped is shown as a built-in group, and users who belong to no other group are its members. LogicMonitor user groups don’t grant roles.
  • Roles - every role, with its description and the users who hold it. The four built-in roles, administrator, manager, ackonly, and readonly, are shown as standard roles, and all others as custom roles. If a user holds a role that the role listing doesn’t return, for example because it was deleted or is outside the API-only user’s Role Access scope, the role still appears, with a description that says its permissions are unknown. Such a role isn’t used as an account role.
  • Portal - the portal itself, with whether two-factor authentication is required for the whole portal.

​
Resource groups and access

  • Resources - the portal and its groups: resource (device) groups, website groups, and dashboard groups, with their folder hierarchy, plus report groups and collector groups. Each group appears inside its parent group, or inside the portal. Resource groups also show their group type, whether they’re dynamic (filled by an AppliesTo query), and how many resources they contain.
  • Reports - each report, inside its report group, or directly under the portal when it’s in the root report group, with read access for the people it’s delivered to: LogicMonitor users who receive it, and any email address outside LogicMonitor. Each outside address appears once as an external account, with access to every report sent to it. When a report is sent to a recipient group, the LogicMonitor users and outside email addresses in that group, and in any group nested inside it, get the same read access, marked as coming from the recipient group. A LogicMonitor user in a group counts as a recipient whatever alert method the group uses for them. Outside contacts that the group reaches only by SMS, voice, or an integration don’t receive reports, so they’re left out.
  • Role access - what each role grants on each group, taken from the role’s permissions:
    • View shows as read access, and Manage as full access (read, create, update, and delete). Acknowledge, SDT, and threshold permissions show as update access. Remote Session on a resource group shows as privileged execute access, because it opens a session on the group’s resources through a collector.
    • A permission on a group also applies to its subgroups, unless the role sets a permission of the same kind on the subgroup itself.
    • A permission on all groups of a kind shows as access to every current group of that kind, and to that kind of group as a whole, so it also covers groups created later.
    • Collector permissions under Settings show as access to the collector groups they name, or to every collector group.
    • Permissions that don’t target a group, such as other Settings, logs, help, private dashboards, dashboards outside any group, and LogicMonitor support access, show as access to the portal. Manage on all Settings or on User Access, and LogicMonitor support access, are marked as privileged.

​
Non-human identities and credentials

Each API token also appears as a credential, an access key for LMv1 tokens and an API token for Bearer tokens, with its status and last use. Every token is linked to the user it belongs to: the token authenticates as that user, the user is shown as its owner, and the token can act as the user. A LogicMonitor token carries all of its owner’s roles, so its credential is shown with full authority. LogicMonitor tokens don’t expire, so no expiry date is shown. A token whose owner Oleria can’t list appears without an owner. A custom property counts as a stored credential when it has a value and its name:
  • ends in .pass, .password, .auth, .key, .accesskey, .secret, or .token;
  • is snmp.community, snmp.privToken, snmp.authToken, snmptrap.community, snmptrap.privToken, or snmptrap.authToken; or
  • contains password, credential, or secret.
snmp.auth, snmp.priv, snmptrap.auth, and snmptrap.priv aren’t counted: they name the SNMPv3 authentication or privacy protocol, such as SHA or AES, not a secret. Each one appears as a credential held by LogicMonitor: a password when its name ends in .pass or contains password, and a stored secret otherwise. Oleria keeps the property name only. It never reads, stores, or logs the value.

​
Activity

Oleria imports events from the LogicMonitor audit log, including:
  • sign-ins, failed sign-ins, sign-outs, and users signed out by an administrator;
  • API requests that LogicMonitor denied;
  • users created, changed, suspended, reactivated, or deleted, and changes to their roles and user groups;
  • password changes and resets, and two-factor authentication changes;
  • roles and user groups created, changed, or deleted;
  • API tokens created, disabled, enabled, or deleted;
  • SSO and security setting changes;
  • remote sessions started, failed, or ended;
  • changes to credential properties;
  • collectors added or deleted, and other additions, changes, and deletions.
Each event shows who made it, when, and from which IP address. Events Oleria doesn’t recognize are kept as custom events. When an event’s text names a user ID or an API token that Oleria discovered, the event is linked to that user or token. A denied API request made with a known API token is attributed to the token, acting as its owner. Events by a username Oleria can’t find, such as a deleted user, are attributed to a disabled account with that username. If LogicMonitor refuses Oleria’s user lookups, events by users Oleria hasn’t already matched keep the username but aren’t linked to an account, because Oleria can’t tell whether the user still exists. Events with no user, or by system, are attributed to a LogicMonitor system machine account. For changes to credential properties, Oleria keeps only the property names, not the event’s text. Changes Oleria makes appear as activity by the API-only user the integration connects as. Oleria refreshes this data on its regular sync schedule.
Oleria doesn’t import individual resources (devices), websites, dashboards, alerts, or LogicModules. LogicMonitor grants permissions on groups, so Oleria shows access at the group level. Reports are the exception, because each report has its own recipients.

​
Prerequisites

  • A LogicMonitor portal at <account>.logicmonitor.com. GovCloud portals (.lmgov.us) aren’t supported.
  • A LogicMonitor user who can create roles, users, and API tokens, such as a user with the administrator role.
  • Admin access to the Oleria workspace.
LogicMonitor rejects the API tokens of users who hold the built-in administrator role. Use a dedicated API-only user on a custom role, as described below. The integration depends on this user and its token: if the user is suspended or deleted, loses its role, or the token is disabled or deleted, syncs and actions stop working.

​
Permissions

Grant each permission with scope All: all user groups for User Access, all role groups for Role Access, and all groups for Resources, Websites, Dashboards, and Reports. LogicMonitor returns only what a permission’s scope covers, so a narrower scope leaves data out without an error. Read permissions, for discovery: If an optional permission is missing, Oleria skips that data and syncs the rest. Oleria lists LMv1 and Bearer API tokens separately. If LogicMonitor refuses one of those listings, or doesn’t offer it on your portal, that kind of token doesn’t appear and doesn’t count toward its owner’s API access, and the other kind still syncs. Other errors, such as an expired token or a LogicMonitor outage, fail the sync so that tokens don’t silently go missing. Manage permissions, only for remediation actions: LogicMonitor treats Manage on User Access and on Role Access as high-risk. Add these Manage permissions only if you want Oleria to take remediation actions.

​
Set up access in LogicMonitor

1

Create a custom role

In LogicMonitor, go to Settings > Users and Roles > Roles, and add a role for Oleria.
2

Grant the permissions

Give the role the read permissions in Permissions, each with scope All. Add the Manage permissions only if you want Oleria to take remediation actions. Save the role.
3

Create an API-only user

Go to Settings > Users and Roles > Users, and add an API-only user for Oleria. Assign it only the role you created. An API-only user has no password and can’t sign in to the portal.
4

Add an API token

Open the API-only user and add an API token: an LMv1 token (recommended) or a Bearer token. Copy the token’s Access ID and Access Key, or the Bearer token, and store them securely. You enter them in Oleria next.
To add API tokens, your own LogicMonitor role must allow creating them. The LogicMonitor interface changes over time. If these steps don’t match what you see, refer to LogicMonitor’s Adding an API token documentation.

​
Choose LMv1 or Bearer

Both token types act with the API-only user’s role. We recommend an LMv1 token:
  • LMv1 - Oleria signs every request with the Access Key, so the key itself is never sent. Before an action, Oleria finds its own token by its Access ID.
  • Bearer - Oleria sends the token with every request. Before an action, Oleria finds its own token by matching the start of the token that LogicMonitor shows in its token list. If LogicMonitor shows too little of it, actions fail (see Remediation actions), while discovery keeps working.

​
Connect LogicMonitor to Oleria

1

Open the integration

Go to your Oleria workspace, select Integrations > LogicMonitor.
2

Complete the connection form

3

Authenticate

Select Authenticate. Before it saves anything, Oleria reads one user and one role with the token, to confirm that the token works and has Settings > User Access: View and Settings > Role Access: View. It also tries to read API tokens, resource groups, collectors, reports, recipient groups, and the audit log. A missing optional permission doesn’t block the connection. Oleria then stores the Access Key or Bearer token securely. The integration is named after your portal, for example LogicMonitor (acme).
If the connection fails, the message says what’s wrong:
  • Enter your LogicMonitor portal name (the part before .logicmonitor.com) or its https URL - check the portal. Only <account>.logicmonitor.com addresses over https are accepted.
  • LogicMonitor GovCloud portals (.lmgov.us) are not supported yet - GovCloud portals can’t be connected.
  • Access ID is not a LogicMonitor API token Access ID - check that you entered the token’s Access ID, not its Access Key.
  • LogicMonitor rejected the credential (HTTP 401) - check the Access ID and Access Key, or the Bearer token, that the token is enabled, and that the API-only user doesn’t hold the built-in administrator role.
  • LogicMonitor denied the read (HTTP 403) - give the API-only user’s role Settings > User Access: View and Settings > Role Access: View, with scope All.
  • LogicMonitor REST API not found (HTTP 404) or LogicMonitor portal … is not reachable - check the portal name for typos.

​
Edit the connection

When you edit the integration, you can replace the token or switch the authentication method. You can’t change Portal. To connect a different portal, add a new integration.
  • Leave Access Key or Bearer token blank to keep the stored one.
  • If you change Access ID, enter that token’s Access Key too, because each Access Key signs only for its own Access ID. Oleria refuses the change without it.
  • If you switch Authentication Method, enter the new method’s credential. Oleria drops the old method’s credential.
Select Update to save. Oleria runs the same checks as Authenticate.

​
Verify the integration

Confirm the LogicMonitor portal appears on the Connected tab of your Oleria Integrations page with a status of Healthy. After the first sync completes, check that users, user groups, roles, resource groups, API tokens, and collectors appear in your Oleria workspace, and that administrators are marked as administrators. In the integration’s Capabilities and operation readiness section, Read users, Read groups, and Read roles show Available. Each row lists Settings -> User Access: View and Settings -> Role Access: View. If one shows Needs permission, check that the API-only user’s role still has both permissions, with scope All.

​
Remediation actions

Oleria can take these actions in LogicMonitor. Every action runs with the integration’s API token, so the API-only user’s role needs the Manage permissions in Permissions. Before it offers an action, Oleria finds its own token and checks that one of the API-only user’s roles grants Manage on User Access or on all Settings, or, for the report actions, Manage on Reports. LogicMonitor checks Role Access: Manage when the change is made. If LogicMonitor refuses a change for lack of permission, Oleria reports the missing permission and nothing changes.
Delete user can’t be undone. The user’s ID, password, API tokens, and two-factor enrollment are gone, and anything that uses the user’s tokens stops working. To remove a user’s access but keep the user, use Disable user accounts instead.
Keep these in mind when you use these actions:
  • Oleria never acts on its own connection. It refuses to suspend or delete the API-only user the integration connects as, to change that user’s roles, user groups, or resource access, and to disable the API token the integration uses. Reverting Enable user accounts follows the same rule.
  • Use an LMv1 token if you plan to run actions. To apply that rule, Oleria must find its own token in LogicMonitor’s token list. If it can’t find exactly one match, every action fails with cannot verify the connection’s own identity — use an LMv1 token, and nothing changes. This can happen with a Bearer token.
  • Every user keeps at least one role. Remove user from role refuses to remove a user’s last role, and Revoke permission to a resource refuses when it would leave the user with no role. To end a user’s access, use Disable user accounts.
  • Ungrouped isn’t a target. Add user to group and Remove user from group refuse Ungrouped, because a user with no other group is in it automatically.
  • lmsupport is LogicMonitor Support’s access. Disable user accounts works on it, but the action’s result warns that suspending it may limit LogicMonitor Support’s ability to troubleshoot. Delete user refuses it: suspend it instead.
  • Replacing a recipient group can start email delivery. When a report action replaces a recipient group with its members, LogicMonitor users the group reaches by SMS or voice are added as recipients too, and may start getting the report by email. The action’s result lists every recipient it added, and reverting the action removes them.
  • Oleria reads the user or token before it changes anything. If it’s already in the requested state, the action succeeds without a change, and reverting it makes no change either. After a change, Oleria confirms it from LogicMonitor’s response or by reading the user or token again. If the change doesn’t show, the action fails.
  • If the user is already deleted, Delete user succeeds without a change, and its result says the user was already deleted.
  • Reverting an action undoes only the change it made, and only while the user or token is still in the state the action left it in. If someone changed it in between, Oleria leaves it as it is and says so. If the user or token no longer exists, the revert makes no change.
  • Add user to role and Remove user from role replace the user’s role list, and Add user to group and Remove user from group replace the user’s group list, with the list Oleria read plus or minus the one change. A change someone makes in LogicMonitor between that read and the write can be overwritten.
  • Add user to role refuses to give an API-only user the built-in administrator role, because LogicMonitor rejects the API tokens of users who hold it. It also fails if the role doesn’t exist.
  • When Oleria can read the user group list, Add user to group and Remove user from group refuse a group that doesn’t exist.
  • Create user makes no change if a user with that username already exists. It refuses if the portal has no built-in readonly role. To give the new user other roles, use Add user to role afterwards.
  • Disable NHI on an API-only user refuses a user who isn’t API-only. Use Disable user accounts for other users.
  • User actions apply to LogicMonitor users only. API tokens, collectors, stored credentials, and audit log actors can’t be suspended, deleted, or given roles or groups.
  • Oleria removes a role only when everything the role grants stays inside the target group and its subgroups. If a role that grants the access also grants other groups or portal-wide settings, the action refuses, names the role, and changes nothing. Remove the user from that role, or edit the role in LogicMonitor.
  • The action also refuses when the user holds a role that the role listing doesn’t return, because Oleria can’t check what that role grants.
  • The portal isn’t a target, because portal-wide permissions also reach other groups. To end a user’s access to the whole portal, use Disable user accounts.
  • Revoke external access to a report and Remove access for an external account replace the report’s recipient list with the list Oleria read minus the outside addresses, then read the report again to confirm. If the change fails or doesn’t show, Oleria puts the recipients back before it reports the error. If a report has no outside recipients, the action succeeds without a change.
  • These two actions change only reports, so they don’t need User Access: Manage or Role Access: Manage. Like every action, they need User Access: View and Role Access: View to find Oleria’s own token and check its roles.
  • Oleria never edits a recipient group, because escalation chains use the same groups to decide who gets paged. Instead, on the report only, it replaces a group that sends the report to an outside address with the group’s remaining members as individual recipients, skipping anyone who already receives the report. Groups without outside members stay as they are, and so does a group inside a replaced group that doesn’t send the report to an address being removed. The report no longer follows later changes to a replaced group; reverting the action puts the group back.
  • When Oleria replaces a group with its members, it leaves out members that aren’t current LogicMonitor users, and the action’s result names them.
  • If Recipient Groups: View is missing, Oleria doesn’t guess what the groups contain. When a report it would change is sent to a recipient group, the action fails before it changes anything and names the groups and the missing permission, even if the report also lists outside addresses directly, so a report is never left half cleaned. When Remove access for an external account runs on every report sent to the address, this check covers all reports in the portal: if any report is sent to a recipient group, the action refuses before it changes anything.
  • If two recipient groups have names that differ only in upper and lower case, Oleria can’t tell which one a report means, so the action refuses before it changes anything. Rename the groups so their names differ by more than case.
  • If removing the outside addresses would leave a report with no recipients, Oleria also turns off the report’s email delivery in the same change, and reverting the action turns it back on.

​
Known limitations

  • GovCloud portals aren’t supported. Oleria connects only to <account>.logicmonitor.com portals over https. Portals on .lmgov.us are refused when you connect.
  • Sessions can’t be revoked. LogicMonitor doesn’t document an API to sign users out, so Oleria doesn’t offer Revoke user sessions. Use Disable user accounts to suspend the user instead.
  • Activity is classified from free text. LogicMonitor’s audit log records each event as a sentence, with no event type, target ID, or session ID. Oleria classifies events by matching their text. Only sign-ins and denied API requests match wording that LogicMonitor documents. Other matched events carry the label unverified pattern, and events Oleria doesn’t recognize are kept as custom events. An event is linked to the user or token it affects only when its text names a user ID or an API token.
  • Activity covers up to 90 days. Oleria reads the audit log back to 90 days before the sync, and then keeps it up to date. Within a single minute with more than 10,000 audit log entries, Oleria reads the first 10,000.
  • User groups come from an undocumented endpoint. LogicMonitor’s REST API v3 doesn’t document a user group listing, so Oleria reads user groups the way LogicMonitor’s own PowerShell module does. If LogicMonitor refuses that listing or doesn’t offer it on your portal, Oleria still shows each group that users belong to, named User group followed by its ID, and the rest of the sync continues. Group membership comes from each user’s record either way. Other errors, such as an expired token or a LogicMonitor outage, fail the sync so that groups don’t silently go missing.
  • No user creation date or last password change. LogicMonitor doesn’t record either for users.
  • SSO shows only for SAML-provisioned users. SSO configuration, including Restrict Single Sign On, isn’t available through the API. Users created through SAML sign-in show SSO. A local user who later signs in with SSO doesn’t.
  • No MFA factor. Oleria sees whether a user has two-factor authentication turned on, not which factor they use. Two-factor policy beyond the user and role settings isn’t available through the API.
  • Portal security settings aren’t read. Inactivity suspension, the API token auto-disable period, IP and email-domain allowlists, and SCIM configuration and tokens are set in the LogicMonitor interface only.
  • API tokens have no expiry or scope. LogicMonitor tokens don’t expire and always carry all of their owner’s roles.
  • Groups only, not individual objects. LogicMonitor grants permissions on groups, so Oleria doesn’t inventory individual resources, websites, or dashboards. Reports are inventoried with their recipients, including the members of the recipient groups they’re sent to. Credential properties set on single resources or on cloud groups aren’t covered. Role groups and access groups aren’t shown.
  • Next-gen reports may be missing. Oleria reads reports from LogicMonitor’s report listing without asking it to include next-gen reports. If that listing leaves out your portal’s next-gen reports, they and their recipients aren’t shown, and Remove access for an external account doesn’t remove the address from them. Check those reports in LogicMonitor.
  • Reports in the root report group appear under the portal. A report that isn’t in a report group is shown directly under the portal.
  • Recipient groups appear as members, not as groups. A recipient group isn’t shown as an object: its members get access to the reports sent to it. LogicMonitor users in a group count whatever alert method the group uses for them, so a user the group reaches only by SMS or voice can show access to a report. Outside contacts reached only by SMS, voice, or an integration aren’t shown. Without Settings > Alert settings > Recipient Groups: View, a group is only a name on the report, and its members aren’t shown.
  • Combined grants show the higher level. When a role grants a permission on all groups of a kind and a different permission on one of those groups, Oleria shows the higher of the two on that group.
  • No nested groups or group roles. LogicMonitor user groups don’t contain other groups or grant roles, and roles don’t contain other roles. A user’s access is the sum of their own roles.
  • Collectors can’t be disabled. LogicMonitor has no suspend state for a collector. Oleria never reads a collector’s own credentials.
  • No AI agents. LogicMonitor’s API has no AI agents. Collectors are monitoring agents and appear as workload identities.
  • Partner and embedded access isn’t visible. Access to the portal from a partner or parent portal can’t be seen from the portal’s API. Embedded dashboard widget tokens aren’t listed.
  • No license level. LogicMonitor licenses monitored resources, not users.

​
Contact us

For questions about this integration, contact us at support@oleria.com.