-
1. Re: ControlM-related Roles and Responsibilities / user access best practices
Mark Francome Nov 8, 2019 3:04 AM (in response to Kelly Briggette)Do you have Control-M Server security (i.e. ctmsec) switched on, or is all the admin done via the Enterprise Manager groups?
-
2. Re: ControlM-related Roles and Responsibilities / user access best practices
Kelly Briggette Nov 8, 2019 10:05 AM (in response to Mark Francome)We use the CCM Security -> Authorizations to manage groups/users.
-
3. Re: ControlM-related Roles and Responsibilities / user access best practices
Paul Robins Nov 11, 2019 9:11 PM (in response to Kelly Briggette)1 of 1 people found this helpfulIt's going to depend on your environment a lot.
We have one Control-M for our entire dev\test environment. Within this we restrict based on Application name, Sub-Application name (environment; dev, uat, integration etc.), and folder name depending on whether you are a developer, tester, environment manager etc. These permissions were decided by our Production Support team.
However moving to agile has thrown this into disarray as agile squads are supposed to be able to perform across multiple roles and developers may perform testing and even BAs who previously had no access might be testing.
I suspect we will have to move to open access per application in dev\test based on which squad owns which application and create some stage gate processes on the way through.
Luckily Dev is completely separate to Production :-D
-
4. Re: ControlM-related Roles and Responsibilities / user access best practices
Mark Francome Nov 15, 2019 9:15 AM (in response to Paul Robins)1 of 1 people found this helpfulUsing different CM/EM environments is helpful, although I am interested to read Paul Robins' comments about the "Agile Gods" playing havoc with that approach.
I have switched on Control-M Server security (ctmsec) whenever possible and this allows you to take a "2 layer" approach to security, i.e. the EM security allows you to control what the various users see, then I use the CM security to control what they can do. In your case you are not using CM security, however you can still get very granular settings from EM security.
I gave groups access per application name (using access at folder level is also a good way to do it) and use the filter option on the actions to create "browse only" groups. Often this is enough (for groups like the Service Desk) and then you can always increase their access if they need it. Copying the groups is also very helpful, if you fine-tune a group you can then copy it to apply to other situations.