Re: Separation of Admin and Development Duties

[Warren R. Baltimore II]

Yeah...but you work for Campbell!

:-)

On Fri, Aug 5, 2011 at 5:25 PM, patrick zandi  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

[Axton]

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  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  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

[sriram pm]

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  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"_

___
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

[Arner, Todd]

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 tha

Re: Separation of Admin and Development Duties

[Mueller, Doug]

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 p

Re: Separation of Admin and Development Duties

[Jonas Stumph Stevnsvig]

OT: At least you get a swiveling chari ;-P

Den 05-08-2011 23:25, patrick zandi skrev:
** 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 
mailto: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"_ 



___
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

[patrick zandi]

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"

Re: Separation of Admin and Development Duties

[Jonas Stumph Stevnsvig]

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

[LJ LongWing]

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

[John . Atherly]

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"  
Sent by: "Action Request System discussion list(ARSList)" 

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"