Re: Separation of Admin and Development Duties
There is no way to effectively enforce this. It's like asking people to not do what they shouldn't and that be the end of the discussion. It just doesn't work. Axton On Wed, Aug 10, 2011 at 12:45 PM, sriram pm ramjavas...@gmail.com wrote: ** Hi, I would simply suggest restrict remedy administrators to have only the Client(Remeyd 7.5 User Tool) Installed and not the Admin Tool(Developer Studio or Administrator Tool) and of course for the Developers to have both Admin and User tool installed. Thank you, Sriram On Sat, Aug 6, 2011 at 3:31 AM, Arner, Todd tar...@glhec.org wrote: ** ** 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
Re: Separation of Admin and Development Duties
Yeah...but you work for Campbell! :-) On Fri, Aug 5, 2011 at 5:25 PM, patrick zandi remedy...@gmail.com wrote: ** Huh ! I must be getting ripped, I have always been told by my boss, see that chair? Yes sir ... It Swivels.. On Fri, Aug 5, 2011 at 5:08 PM, Jonas Stumph Stevnsvig arsl...@stevnsvig.com wrote: ** My previous place of employment had similar protocols. To ensure quality, We had four environments: Development, which is the ONLY environment on which the Devs have admin rights. Test, which is in theory the Admin's olayground - a place to test patches, and so on, so that the Admin does not obstruct the DEVs work. Pre-Production, which was used for End-user accept testing before production. and of course, Production. Besides this, we used object reservation on all servers, with system forms locked by a per-server account, to prevent accidental modification (we had a strict policy of not altering system forms). The different tiers also means that basic things such as user privileges and server configuration changes are well described, since the Devs are forced to test on environments where they have no admin rights. We had one further modification; all the Admin forms the Devs would need access to in order to troubleshoot were given an extra permission group, which the Devs would get on their PRod user. Hope this is inspiration. best regards, Jonas Stevnsvig Den 05-08-2011 21:31, Arner, Todd skrev: ** 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_ -- Patrick Zandi _attend WWRUG11 www.wwrug.com ARSlist: Where the Answers Are_ -- Warren R. Baltimore II Remedy Developer 410-533-5367 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are
Re: Separation of Admin and Development Duties
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
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
Re: Separation of Admin and Development Duties
We have run across the same issue and basicly the developers do not roll out their changes on Production that is handled by the admins. The developers and admin all have full access to all servers Dev, QA and Production but each keeps in their own rolls. _ John Atherly | APC by Schneider Electric | Information, Process Organization (IPO) | Remedy Administrator / Developer Phone: +401-789-5735 ext. 2120 | Fax: +401-789-3710 | Email: john.athe...@apcc.com | Site: www.apc.com/ | Address: 132 Fairgrounds Road, West Kingston, RI 02892 USA *** Please consider the environment before printing this e-mail Arner, Todd tar...@glhec.org Sent by: Action Request System discussion list(ARSList) arslist@ARSLIST.ORG 08/05/2011 03:31 PM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc 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. __ This email has been scanned by the MessageLabs Email Security System. __ _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
Re: Separation of Admin and Development Duties
Todd, In our company, because our application is a SOX app, the development staff cannot have write access to production. We have full access to our Dev/Test environments, but cannot have a write license in production at all. This means that we were forced to develop processes and procedures to allow Admins to deploy our changes to production because the ability to do that ourselves violates SOX requirements. This effectively ensures you have a minimum of 2 environments.one where you make your Dev changes, and a second that is production. Ideally you also have a Test in between which is where you designated 'movers' can test out your migration directions from Dev to Test.then repeat them again in Prod when the time is appropriate. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Arner, Todd Sent: Friday, August 05, 2011 1: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_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are
Re: Separation of Admin and Development Duties
My previous place of employment had similar protocols. To ensure quality, We had four environments: Development, which is the ONLY environment on which the Devs have admin rights. Test, which is in theory the Admin's olayground - a place to test patches, and so on, so that the Admin does not obstruct the DEVs work. Pre-Production, which was used for End-user accept testing before production. and of course, Production. Besides this, we used object reservation on all servers, with system forms locked by a per-server account, to prevent accidental modification (we had a strict policy of not altering system forms). The different tiers also means that basic things such as user privileges and server configuration changes are well described, since the Devs are forced to test on environments where they have no admin rights. We had one further modification; all the Admin forms the Devs would need access to in order to troubleshoot were given an extra permission group, which the Devs would get on their PRod user. Hope this is inspiration. best regards, Jonas Stevnsvig Den 05-08-2011 21:31, Arner, Todd skrev: ** 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_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are
Re: Separation of Admin and Development Duties
Huh ! I must be getting ripped, I have always been told by my boss, see that chair? Yes sir ... It Swivels.. On Fri, Aug 5, 2011 at 5:08 PM, Jonas Stumph Stevnsvig arsl...@stevnsvig.com wrote: ** My previous place of employment had similar protocols. To ensure quality, We had four environments: Development, which is the ONLY environment on which the Devs have admin rights. Test, which is in theory the Admin's olayground - a place to test patches, and so on, so that the Admin does not obstruct the DEVs work. Pre-Production, which was used for End-user accept testing before production. and of course, Production. Besides this, we used object reservation on all servers, with system forms locked by a per-server account, to prevent accidental modification (we had a strict policy of not altering system forms). The different tiers also means that basic things such as user privileges and server configuration changes are well described, since the Devs are forced to test on environments where they have no admin rights. We had one further modification; all the Admin forms the Devs would need access to in order to troubleshoot were given an extra permission group, which the Devs would get on their PRod user. Hope this is inspiration. best regards, Jonas Stevnsvig Den 05-08-2011 21:31, Arner, Todd skrev: ** 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_ -- Patrick Zandi ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are
