Groups/Users rights to Orion

That is the expected behavior, Solarwinds does the group matches to the first group you are a member of based on the order listed in the account management page, it does not combine group memberships or anything else like that.  Local or individual account permissions also supersede any group memberships so if you have an individual account with read only access but are also a member of the admin group you will not get admin privileges because the individual account always takes priority.

Thanks you for your answer

Sorry old thread I'm replying to, but in the table Accounts on the database there is a column for Group Priority, if one group is set to a higher priority than the other and a member is part of both groups do they then get permissions based on which group their account is associated with that has a higher priority?

The group priority is the same as the group order you see in the GUI, you want the most privileged groups at the top of the list/lowest priority number

I'm also going to stir up this one thread with a question.

We've been asked to remove any admins with local Windows account and replace them with a Windows Group accounts.  The users are in the correct group, and I disabled the old account, but have not deleted it yet.  The user cannot log in.

I suspect this is expected behavior, as the individual user account that is disabled is superseding the fact that the user belongs to one of allowed Windows Group account groups.  Is that correct, will I need to actually delete his account for him to be able to log in via his Windows Group membership?

Interesting ...

We have a 'secure' SolarWinds environment where we don't have access to the AD and are assigned to specific groups within that AD and access to SWI works via an FQDN logon. Rights are set at he lowest common denominator member for those groups, so I don't have admin access when logging in via my domain account. We have, however, configured local SWI users (individual accounts tab) that do allow us that access.

So two things:

1. Have they tried using the FQDN logon approach? i.e DOMAIN\Username - as previously they likely just entered their logon ID.

2. AIU you, you are saying the users local windows account had access but not since it was disabled? Then if they need this access (say for higher privilege access), an individual account would be needed.

I may of course be teaching you to suck eggs and completely misunderstood your query.

User (XYZ) had individual account tied to AD, so he logged in via corp/xyz and password.  Audit wanted us to remove any local windows accounts that had admin privileges.  So user XYZ was added to Solarwinds_Admin AD group.  That AD group is configured (I'm a member if it, so I know that piece is working).  I disabled his individual account, and he attempted to login using corp/XYZ, just like before, but was not allowed in. (bad username and/or password)

I'm thinking that because individual accounts take precedence over Windows Group accounts that Orion is seeing him as a disabled account and not using the fact that he's a member of the Windows Group.  I had hoped to just disable his account as a test before deleting it, but I think that's not going to work, and I'll have to delete his account before he can successfully log in as a member of the Windows Group.