How should nested AD groups work in Solarwinds?

Still can't understand, please clarify it to me, would really appreciate it. No info in docs though.

So. We are using only SAML groups, there are no "individual" or "windows groups" accounts.
For example we have such AD structure:

AD User "X" is a member of AD Group "Group.City".
AD Group "Group.City" is a member of AD Group "Group.Country".
AD Group "Group.Country" is a member of AD Group "DSG.Solarwinds.ReadOnly"

So nested structure is like that:




X (user)

Hope it is clear enough.

Also, user "X" is a member of another AD Group - "DSG.Solarwinds.Admins":


X (user)

Both groups - "DSG.Solarwinds.ReadOnly" and "DSG.Solarwinds.Admins" are added as SAML groups in Solarwinds.
And DSG.Solarwinds.ReadOnly is located higher in the list.

But when I login with "X" user, I'm getting Admins rights instead of ReadOnly!
And in the account list I see what I was loggin as "DSG.Solarwinds.Admins".

Why? Does ad-nesting work in Solarwinds or not?

  • The short answer is that AD nesting does NOT work in Solarwinds.

    The more detailed answer is that whatever order those groups appear IN SOLARWINDS (Manage Accounts), that's the rights which will be applied. So if the order that the groups appear in "Manage Accounts" is like this:

    • DSG.Solarwinds.ReadOnly
    • DSG.Solarwinds.Admins

    ...then the user will get ReadOnly permissions.

    But if the groups appear in this order:

    • DSG.Solarwinds.Admins
    • DSG.Solarwinds.ReadOnly

    Then the user will get Admins permissions.

    And to be 100% clear, it has nothing to do with the AD permissions. It's all about the SolarWinds permissions you assign to the group under "Manage Accounts". Despite anything you've done in AD, the DSG.Solarwinds.Admins group may have "read only" permission *in SolarWinds* and that's what will be applied.

    Hopefully that is more clear

  • The thing is.. "DSG.Solarwinds.ReadOnly" is located higher in the list but user X still login via "DSG.Solarwinds.Admins" group

    P.S. DSG.Solarwinds.ReadOnly has RO rights and DSG.Solarwinds.Admins has admin rights in our SWS.

  • Let's clarify a few things:

    • You have one domain: DSG
    • You have one user:  "X"
    • You have two groups: "SolarWinds.ReadOnly" and "SolarWinds.Admin"
    • User "X" has been added to both of those groups

    The thing to understand is that there's only ONE user account ("X"). And therefore it doesn't matter how many groups they belong to. Whichever appears first in the SolarWinds account list is the one that is going to have it's SolarWinds rights applied.

    SolarWinds uses a firewall-style policy for rights. Whichever item matches first is what gets applied. User "X" could belong to 10 more groups and SolarWinds would never consider those rights. There was already a match in the list and the user was logged in with that.

    Does that make more sense?

  • adatole, thank you for answer, I appreciate it. I understood how Solarwinds will process user account rights - first match (the highest one) will be taken.
    But I'm trying to ask about something else using my limited English vocabulary :).

    The main question I need to clear up - can I add user accounts to Solarwinds Orion using nested AD groups or not.
    Based on my observations, I can't.

    Let me give an other example.
    AD Group "A" is a parent of AD group "B".
    User "X" is a member of AD group "B".
    That means user "X" has no direct relation with group "A", but it is A's grandson

    -- A
    ---- B
    ------ X

    If I will add group "A" only (to the Orion's user accounts), will X have access to Orion web or not?


  • AH!! Now I understand. Thank you for being patient with me.

    The user ("X") must be a direct member of the group you add into SolarWinds. Not a member of a sub-group.

    That's explains why the user is getting the "Admin" permissions, not the "readonly" permissions.