User access restrictions

We're looking to grant access to the LEM console to users beyond the administrators and I have some questions regarding user access control.

The LEM console (Addobe Air edition) requires both credentials and a certificate to be installed for access. However, the LEM web console only requires credentials. Are there any additional access restrictions that can be put in place such as restriction by IP address?
Regarding LEM user roles, what are the differences between a Guest and Auditor?
This is more a suggestion than a question. The only way I was able to find out the details of the different LEM user roles was modifying a user, selecting a role from a drop-down menu and clicking View Role. Also, because of the way the information is presented, it was difficult discerning the differences between the roles. Is this information documented anywhere else? I couldn't find it in the user documentation or the knowledge base.

Find more posts tagged with

access

restriction

log_and_event_manager

Accepted answers

All comments

FormerMember

I didn't see a response to this, not sure if you filed a support case or figured it out on your own, but here's some thoughts:

We're looking to grant access to the LEM console to users beyond the administrators and I have some questions regarding user access control.
The LEM console (Addobe Air edition) requires both credentials and a certificate to be installed for access. However, the LEM web console only requires credentials. Are there any additional access restrictions that can be put in place such as restriction by IP address?

You can restrict by IP address globally (i.e. can access the console AT ALL or not) at the appliance level using the "Advanced Configuration" on the appliance. It's not a user+IP combination, just an IP whitelist.

Regarding LEM user roles, what are the differences between a Guest and Auditor?

Right now, there are no functional differences between Guest and Auditor. We created the "Guest" account for use with our online demo and evaluation environments since it sometimes comes up, but they are technically identical right now. The goal of "Guest" was to keep them from doing any damage beyond customizing their view, the goal of "Auditor" is to have a system-wide view of data and configuration settings; it so happens that these two things ended up in the same place for now.

This is more a suggestion than a question. The only way I was able to find out the details of the different LEM user roles was modifying a user, selecting a role from a drop-down menu and clicking View Role. Also, because of the way the information is presented, it was difficult discerning the differences between the roles. Is this information documented anywhere else? I couldn't find it in the user documentation or the knowledge base.

You're right, I didn't find it anywhere else, either. I'll pass this suggestion on to our InfoDev team.

qle

You can restrict by IP address globally (i.e. can access the console AT ALL or not) at the appliance level using the "Advanced Configuration" on the appliance. It's not a user+IP combination, just an IP whitelist.

Is this the restrictconsole command that you're referring to? The description states that the command enables restriction for the GUI console so I didn't know whether it extended to the web console.

Right now, there are no functional differences between Guest and Auditor. We created the "Guest" account for use with our online demo and evaluation environments since it sometimes comes up, but they are technically identical right now. The goal of "Guest" was to keep them from doing any damage beyond customizing their view, the goal of "Auditor" is to have a system-wide view of data and configuration settings; it so happens that these two things ended up in the same place for now.

Would that in mind, would it be possible to make a distinction between these two roles? As indicated originally, we may be granting additional access to the console. I find that the Monitor and Contact roles are too restrictive. The Audit role seems to be perfect based on its label. The Guest role being functionally equivalent to the Audit role is too lax.

A potential scenario would be members of a different department/group looking to direct their logs to LEM. However, akin to the account restrictions in SolarWinds NPM, I would like to restrict their view of LEM both with regard to the data sources and possibly as far as pre-defining their monitor filters. They could still define their own filters. There would probably be little, if any access to the rest of the configuration.

FormerMember

Quang Le wrote:
You can restrict by IP address globally (i.e. can access the console AT ALL or not) at the appliance level using the "Advanced Configuration" on the appliance. It's not a user+IP combination, just an IP whitelist.
Is this the restrictconsole command that you're referring to? The description states that the command enables restriction for the GUI console so I didn't know whether it extended to the web console.

Yes! It's a low level port-based firewall on the appliance, effectively, that blocks 80/8080/443/8443 connections from any IP not in the whitelist. The AIR and web consoles use the same communication methods, so it applies to both.

Quang Le wrote:
Right now, there are no functional differences between Guest and Auditor. We created the "Guest" account for use with our online demo and evaluation environments since it sometimes comes up, but they are technically identical right now. The goal of "Guest" was to keep them from doing any damage beyond customizing their view, the goal of "Auditor" is to have a system-wide view of data and configuration settings; it so happens that these two things ended up in the same place for now.
Would that in mind, would it be possible to make a distinction between these two roles? As indicated originally, we may be granting additional access to the console. I find that the Monitor and Contact roles are too restrictive. The Audit role seems to be perfect based on its label. The Guest role being functionally equivalent to the Audit role is too lax.
A potential scenario would be members of a different department/group looking to direct their logs to LEM. However, akin to the account restrictions in SolarWinds NPM, I would like to restrict their view of LEM both with regard to the data sources and possibly as far as pre-defining their monitor filters. They could still define their own filters. There would probably be little, if any access to the rest of the configuration.

The Monitor user effectively can't create their own filters OR view any other configuration stuff, but can Monitor data. You have to create them first as an Auditor/Admin, build their filters/widgets, then make them a Monitor user. The purpose of that was to prevent them from creating filters that could see other data, in case there's sensitive information they shouldn't be able to see (we had some security teams that wanted to restrict server data from network teams, for example). So, you're kind of looking for a hybrid of the filter privileges of Auditor (customize their own view), but the configuration privileges of Monitor (can't configure or even see rules, groups, etc).

We do have a request in to create roles based on slices of data, but that's more complex. What we'd probably do is prevent that data from even being displayed in their Console at all, so it'd be something like a layer on top of the user's global role - a data role, if you will. So if I were console role "Auditor" but data role "Network Only", I could see the configuration everywhere, I could configure my own filters, but I'd never even know that other data existed since it wouldn't show up in my searches, filters, or rules.

If you wanted to slice views of your data based on role, what do you think would be most useful to do that with? Connector/tool name? IP Address of the data source? Type of event?

qle

In our context, it would come down to connectors and/or nodes. For example, our DBA would only be interested in the events collected from the respective connector (e.g. SQL Server Auditor or Oracle syslog) across different nodes. On the other hand, especially for systems that wouldn't fall under our purview, I'd simply designate nodes with specific tags (like custom properties in NPM) to specific roles with no regard for their connectors. If I could only choose one, it would have to be by nodes.

I do like your idea of the data role which prevents the data from being displayed at all. Except for a select few, anyone who can access the LEM console would be setup with a Monitor console role and their respective data role.

My only problem with predefining filters/widgets for them is the requirement to login with their credentials. Since we're leveraging the Active Directory integration, this makes it very hard to setup. Have there been any thoughts about improving this process?