This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

API Access Denied Issue

We have two AD accounts that are members of the same AD group, same SolarWinds group, and have the same permissions.  We are able to use one account to query the API, but the other fails with an "Access Denied" message.  We have tried recreating the SolarWinds group, but that did not resolve the issue.  Adding the failing account as an "Individual Windows Account" with the same permissions as the group, resolved the issue.  Does anyone have any suggestions as why this is is happening?  We have an internal requirement to use groups versus individual accounts.

  • Is the account getting denied also added as an individual account? I think individual accounts take precedence over group accounts.
  • Thanks for the reply.

    When using an individual account the get-swisdata command works, but fails when using a group.  The individual account and the group have identical permissions, so I am not sure why this is happening.  The permissions are set to default with the addition of Node Management, so nothing unusual here.  We have been logging into the console using the account to verify that the account is actually using the individual account or the group (displayed at the top-right in the console), and it has matched our test every time.  Elevating the group permissions to administrator-level did not make any difference.

  • Using AD users with the API has been an issue since the beginning. Save yourself some heartache and use a local Orion user.

  • I mentioned earlier that one AD account is working and one is not.  Can you elaborate on what the issue is?  Is it an issue with consistency, reliability, or something else?  For example, if we use the AD account that IS working, will it stop working in the future, or be inconsistent in some way?  I appreciate your advice, I am just try to understand what the scope of the issue is.

  • I’ve seen issues using ad accounts before too but didn’t have much of an ad environment to test it on and really didn’t look into it, just what was mentioned above and made a local account. It was basically an issue with logging in, couldn’t get in at all.

    Now though I’m using an ad service account for powershell swis access / updates and am seeing no issues whatsoever. Not using any groups though, they’re just configured as an individual ad account with as limited access as possible.

    Sorry I don’t have much to provide.
  • Is the account which is denied also in other groups and are those also configured in Solarwinds and have less priviledged and are on top of the group which has access in the list? Then you find the problem. It is since the beginning not so easy when you have a user which is in more than one group. I also have an headache from that. 

  • Although the account is a member of several groups in SolarWinds, it is using the group with the highest level of permissions.  The group that it is using is the highest in the sort order and we have visually confirmed what group it is using by logging into the console (the group is displayed at the top-right).

  • Perhaps the API is not abiding by this sort order or maybe confused by all of them.

    Have you tested access with an account that only has access with just one group or just the account added?