Excluding Groups from Manage System Security Roles

[KurtMayer]

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?

[MarcusH]

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]

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]

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]

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]

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]

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.

[T_Kress]

You confirmed my understanding which is that the native 'Administrators' has full rights to everything, excluding 'Nobody' (which is intentional).  So I always thought the native administrators had rights to manage security roles, by default. 

You can also create a group like 'Sec_Admins' and place that on the manage security roles so that group of users can do that, but the native 'Administrators' will still have rights. 

We used a 'Sec_Admins" group on the manage security roles at a customer and found a limitation to that, as well.  When one of their native 'Administrators' left the company and their access needed to be removed, the 'Sec_Admins" could not do it because 'Sec_Admins' was not in native 'Administrators' group and therefore they could not remove a user from the 'Administrator's group because that group is a higher level than 'Sec_Admins'.   The 'Sec_Admins" could manage all other security but we found that when it came to adding or removing individuals from the native 'Administrators' group, they could not.  So a small limitation there.  But not your issue.

I think a work around could be for you to edit the OSD BR that checks that a user is in the admin group.  Have it also do an OR check that the user is in the group you have assigned to 'AdministerApplication'.  That would be a customization to the OSD BR so you would want to make a copy and keep track of that tweak the next time you upgrade the OSD package.  But it seems like with a small tweak to that BR you could have it do the check it is doing now or check that the user is in a specific group for which you also want to have access to run those OSD reports.  That may be your easiest solve since granting local admins native 'Administrators' is not an option.

[KurtMayer]

Teresa, I would love to do that... but the OSD BRs are now encrypted.  🙂

I'm creating a suggestion in IdeaStream to have a new System Security Role called ManageSystemSnapshots added -- that OSD specifically checks with an "OR" check, like so:

BRApi.Security.Authorization.IsUserInRole(si,RoleTypeID.ManageSystemSnapshots)

But there would have to be much more internal coding than that to implement the idea. OSD would have to also check that the user is in other important security access roles as well -- all of the roles in yellow highlighting.  Not an easy problem to solve I understand, but one that I think merits consideration.

IdeaStream suggestion: (please upvote)

OSD - Allow Application Administrators to make System Snapshots - OneStream Community (onestreamsoft...

[MarcusH]

Create the group Sec_Admins and apply to the 3 ManageSecurity but don't make the Administrators a child. Provision the users directly with access i.e. the group Administrators does not inherit the access - the users do. I know it can be done because it took me a while to do the opposite.

[KurtMayer]

Sorry Marcus, that is what I stated above that I already tried. Even with Administrators not being a child of Sec_Admins, they still have access to manage security.  I only had Users in my Sec_Admins group, no child groups, and the members of the Administrators group could still manage security. In OneStream, the Administrators Group has access to everything, except where the Nobody group has been applied.

[KurtMayer · Accepted solution]

Unfortunately, after a lot of discussion, I think this is the only solution, which I've put in IdeaStream;

OSD - Allow Application Administrators to make System Snapshots - OneStream Community (onestreamsoft...