Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials

User with limited permissions, can't determine where limitation is set

We have an employee that transferred to our department. We added him into the same AD group that everyone else is in ... but somehow he is showing as inheriting "Read Only" permissions in the IPAM module.

Is there a way to search for a specific user to see exactly what permissions they have and where they are getting those permissions?

I've attached a couple of screenshots

snippet1.png - shows the Manage Windows Group Accounts screen. The user in question is a member of the ...NetworkServices_Core group ... which should have extra rights

snippet2.png - shows the group properties for a folder in IPAM and the user in question (rastitt) shows as only having Read Only access

It seems like you should be able to select a user and find out what permissions they have or maybe some authentication log that would list permissions granted.

attachments.zip

Find more posts tagged with

Accepted answers

All comments

gkjono

A couple things worth checking.

Do they have an individual account in Orion in addition to the group membership? Individual accounts will override the group permissions.
Do they belong to multiple groups? If they do, the one with the higher order ranking will take precedence over any lower groups.

When the user is logged in, it should show the group that it is pulling the permissions from on the top right of the screen next to their username.

How is the user logging in? I've noticed when users use FQDN\USERNAME instead of SHORT-DOMAIN\USERNAME that they don't necessarily get the right permissions. I think this is a bug.

- gkjono

Loop1 Systems: SolarWinds Training and Professional Services

LinkedIN: Loop1 Systems
Facebook: Loop1 Systems
Twitter: @Loop1Systems

wdharperok

The employee in question is only in one group, no individual account in Orion.

I'll have to verify which format (FQDN\USERNAME or SHORT-DOMAIN\USERNAME) they are using .. but for what it's worth, you can also login using USERNAME@SHORT-DOMAIN.

Had a call from support and wasn't thrilled with what the tech told me. His understanding was that using AD groups were not "dynamic", meaning that when you first create a group some process pulls in all the members of the AD group once. His suggestion was to delete group and recreate.

We have multiple modules and we assign different permissions to for those modules, so I explained that wasn't a very practical option and that the perception isn't that users were just imported once. We would expect this to be dynamic in that as someone logs in, Solarwinds checks to see if what group a member is in and apply the appropriate permissions. As I've been researching this, I found multiple users that no longer exist when I look at permissions in certain areas. These users are not in any security groups.

They had me send some diagnostic information and said they would get back to me. Haven't heard anything back yet.

frak

The permissions are not additive (I do think this is a shame).

The order of the groups within Solarwinds is important. To work out the 'home' group of the user, Solarwinds will work its way down from the top though the available groups in Solarwinds. The first group it finds, that the user is a member of, will be its group for permissions sake. Also this group will appear on the top of of the users screen.

wdharperok

Got more information from support yesterday.

When a user logs in, Solarwinds checks to see if the user is defined as a local user or is in any AD group you have defined. If it finds a match, the userid gets added to the database with the permissions found.

There is not an automated method for removing users who no longer exists as a local user or in your AD groups.

You can delete them (manually) by using the Database Manager on your Orion Server.

We found multiple users listed in our database that haven't worked here for years. In my opinion, that's a poor design, there should be some kind of automated clean-up tool (or at least a report you could run that would list "orphaned" users, those who aren't defined as a local user or in an AD group), so you aren't having to look up every user listed in the database.

We have to talk to the IPAM group still, problem with read-only for the one user still isn't resolved.