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