Unfortunately, after a lot of discussion, I think this is the only solution, which I've put in IdeaStream;
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.
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!
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.
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.
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.
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.
