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.
