Thanks very much Doug! This is extremely useful information. I think with the addition of the Structure only Administrator groups we can accomplish everything we need. Now our challenge will be to get to version 7.6.04 so we can use it :) Thanks to everyone who responded. The information will help to get us going in the right direction. Todd Arner
________________________________ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Mueller, Doug Sent: Monday, August 08, 2011 1:27 PM To: arslist@ARSLIST.ORG Subject: Re: Separation of Admin and Development Duties ** Todd, Well, this note gives me a good opportunity to talk about some functionality that has been added to the system over the years. These types of requests have come up periodically and they are coming up more and more over the years. We do listen.... 1) SubAdministrator For 10+ years of course we have had the concept of SubAdministrators who can only have Administrator rights to a subset of the system. I know this is not the current topic, but it is related and I wanted to make sure there is a complete list of the different ways you can segment duties. This capability allows you to have users who are Admins but only for certain parts of the system. They are normal users to the parts they are not SubAdmins for. 2) System Admin vs. Administrator For a number of releases (7.0?), we have allowed the separation of Development and System Admin duties. All the System Admin duties -- setting server info settings and creating users and groups and such -- can all be accomplished by a non Administrator user of the system. In fact, you can separate these duties as much as you desire since all of these duties are now accomplished through AR System forms and you can control the premissions as fine as you desire -- you can let someone change some settings but not others as you can control each setting with separate permissions. So, this allows you to have someone who is a System Administrator of the AR System but who does not have development rights and cannot see any data that their normal permissions doesn't grant them access to. But, you are looking for something above and beyond this, you want to restrict the Administrator. The above only allows you to have a System Administrator without Administrator rights. How do you limit the Administrator from having System Administrator or data rights? So, in 7.6.04, we introduced a new capability.... 3) Structure only Administrator With the 7.6.04 release, there are two new special groups -- Struct Administrator and Struct SubAdministrator. These two groups provide a restricted flavor of Administrator and SubAdministrator capabilities. The restriction is that they have development rights just like before but NO DATA ACCESS. In other words, they can play with structures but not see any data. Unless of course they are also in other groups that give them access to data just like any other normal user. In addition, there are ways to lock someone to the overlay layer so that they do not have the ability to go into base mode and be an Administrator there (so they are an overlay only Administrator or SubAdministrator). This allows you to have separation between development and data. You can have folks with Struct Administrator rights do an upgrade of a system but they cannot see any of the data on the system. You can of course mix and match rights someone has on different systems (so they can be full Administrators in development but only Struct Administrators in production for example) or have different users with the rights on different systems or whatever level of segregation you want. You can combine Struct Administrator with the System Administration capability to have users who can do development on a system but not do any System Administration on the system. You can have someone who has development and system adminstration rights but no access to any other data. Whatever combination you want on whatever systems you want should now be possible. NOTE: Administrator is still there and still has full rights to everything. Something has to have everything. But, you can restrict this access tightly and you can even have no one with those rights and use arcache to stick someone in as an Administrator if there is ever a need for someone with ALL rights. Combining the three features that are now available, you can restrict what rights a user has and control development, system administration, and data access and keep them together or separated as needed for your environment. I think if you look at these three capabilities, you will be able to slice and dice your roles and the access they allow to the system to conform to whatever separation of duties/roles requirements existing in your environment. If there are other divisions that are needed, we would like to hear about them. But, we think that the combination of these capabilities allows you to do what is needed. I hope this is useful and maybe lets you know about some features that you were not aware of. Doug Mueller ________________________________ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Arner, Todd Sent: Friday, August 05, 2011 12:31 PM To: arslist@ARSLIST.ORG Subject: Separation of Admin and Development Duties ** We have been given a directive to separate the Remedy Development and Administrative functions. Basically, we have been instructed to come up with a way to ensure that no one person can make development changes and also be able to set up users accounts. We currently split the roles between two groups so that no one person is doing both, however, since the developers and admins have Administrator privileges, there is nothing stopping either from performing all functions. Does anyone else out there have a similar requirement? If so, can you share your solution? I am just not seeing a way to do this. Or maybe I just don't want to see the way. :) Seems to me both rolls need to have Administrator privileges to complete their tasks. Any insight is greatly appreciated. ARS 7.5 p7 MS SQL 2005 Windows 2003 SP2 Thanks, Todd Arner Great Lakes ------------------------------------------------------------------------ -------- The information contained in this communication may be confidential, is intended only for the use of the recipient(s) named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender immediately and destroy or delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender. ======================================================================== ======== _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
