Forum Discussion

KurtMayer's avatar
KurtMayer
Contributor
5 months ago

Excluding Groups from Manage System Security Roles

I thought I knew how to solve this but it is not working as expected.

We are trying to prevent a Child Group of users called "App_Administrators" from changing System Security. We want them to be able to still 'view' security roles, groups, and users -- just not be able to make any changes.

The Group called App_Administrators is a child group in the Administrators Group (which is needed because we want application administrators to be able to run OSD System Snapshots on demand). Since the child group is part of Administrators, we thought all we needed to do was create an Exclusion Group that effectively takes App_Administrators back out of Administrators and apply it to the ManageSystemSecurity roles (there are three of them).

After creating the Exclusion Group and applying it to the following Roles 

  • ManageSystemSecurityUsers, 
  • ManageSystemSecurityGroups, 
  • ManageSystemSecurityRoles,

we found that the security group App_Administrators members could still modify security (after logging out and logging back in).  This seems like it should not be the case. Thoughts? Are we doing something wrong here? If you belong to the Administrators group, even through a child group, do Exclusion Groups not apply to you?

 

 

Security
  • MarcusH's avatar
    MarcusH
    Contributor III
    5 months ago

    I think the problem is that the App_Administrators group is a member of the default Administrators group. Members of the default Administrators group have access to 'nearly' everything and exclude groups do not remove those permissions. As far as I know, 'nearly' means that Administrators do not automatically inherit permission to security groups that are applied to items that default to Nobody. The 3 ManageSystemSecurity tasks default to Nobody so Administrators have to be explicitly given access to these groups. So your security model is giving App_Administrators access to them and then excluding them. I would look at removing App_Administrators from the Administrators group and instead give them the Application role AdministerApplication. That should give them the same access as Administrators to the Application items (and the added bonus is they can't change their own security). Then add the System roles that the App_Administrators need - start from nothing and add rather than start from everything and remove.

    In my opinion the standard way of configuring security (i.e. one security group applied to more than one securable item as in your case Exclude_App_Administrators) is inflexible and confusing. If you want another way of doing security have a look at this page. It is a link to my blog.

  • KurtMayer's avatar
    KurtMayer
    Contributor
    5 months ago

    Thanks Marcus.  The problem is that we want App_Administrators (who do have the AdministerApplication role by the way) to be able to run OSD System Snapshots on demand.  They used to be able to do this pre-v8 and now they can't in v8. They get an error from OSD.

    OneStream Support suggested adding the App_Administrators to the Administrators group to solve the issue. When we did that then of course all of the Application Administrators could change security. That's why I was trying the Exclude Group route to pull them back out.

    There's really no other way to "start from nothing and add" for the System Security Roles - even if you create another group, like perhaps Security_Administrators, as you say once you add another group to the Administrators group they have access to nearly everything.

    IMHO there needs to be another Security Role added, called ManageSystemSnapshots (or something like that) which OSD would use to allow non-Administrators to do system snapshots.

    • T_Kress's avatar
      T_Kress
      Contributor III
      5 months ago

      If I understand the issue correctly, you have a group of users who are local admins and thus in the "AdministerApplication" security role for that app.  But with only that out-of-the-box Application Security Role alone, they cannot get to the database tables (nor System tab in general) in order to run the OSD reports.

      So you started by nesting them in the "Administrators" native user group. But this inherently then gives them access to everything (except "Nobody"), including rights to change security, which is too much.  And even though you tried an exclusion group, the exclusion group does not supersede their "Administrators" access to 'everything'.

      I think what you have to do is start with "AdministerApplication" and then layer on possibly the following groups:

      + AdministerDatabase (an Application Security Role)

      Then + the following System Security Roles and Pages:

      I have not tested but I feel like there will be some combination you can grant of System Security Roles and System User Interface roles (without granting them the "ManageSystemSecurityUsers/Groups/Roles" that will allow them to be able to run the OSD reports.  

      You could create a new group called "Local Admins Plus" and in it put the "AdministerApplication" plus the ones above in yellow and then log in and test your ability to get to OSD reports.  

      I have noticed this before though that the 'AdministerApplication" Application Security Role alone, because it does not have access to certain database tables that reside in the framework database, it cannot run OSD reports and I have even noticed some of the Standard Application Reports (RPTA) reports are filtered out of the list because they need access to certain tables that this local admin role does not have.

      If I get a chance to test myself I can report back.  But I would start by testing the above combinations in yellow and keep expanding until you can run OSD reports.  I do not believe the "ManageSystemSecurityUsers/Groups/Roles" are a pre-requisite to running OSD reports so hopefully you can find the right combination of roles that will allow you to run them!

       

      • KurtMayer's avatar
        KurtMayer
        Contributor
        5 months ago

        Teresa, great minds think alike.  That is also what I tried -- ensuring that App_Administrators group have access to all of the highlighted groups shown below.  But then as Marcus pointed out, I remembered that the OSD BR specifically checks for the OSD user having membership in the Admin group.  At least this is the way it was in the past, now with all of the OSD BRs being encrypted we can't check.

         

    • MarcusH's avatar
      MarcusH
      Contributor III
      5 months ago

      The OSD BR specifically checks that the current user is in the Administrators group and members of AdministerApplication are not included in that from a BR point of view:

      Members of the Administrators group do not inherit these ManageSecurity groups by default so we should be able to configure this. Create another group(s) and apply them to the ManageSecurity items. Do not give App_Administrators access to them but leave it as a member of the Administrators group.

      • KurtMayer's avatar
        KurtMayer
        Contributor
        5 months ago

        I had tried that. I created another group called Sec_Admins by 'copying' the Administrators group and removing App_Administrators in the copy, leaving only the users considered system administrators. 

        I then applied that Sec_Admins group to the three System Security roles.  The members of App_Administrators group were still able to manage security (because their group is a child of the Administrators group). 

        Your statement "Members of the Administrators group do not inherit these ManageSecurity groups by default" has always been my understanding as well, however through testing, I have been able to determine that is not the case.