Hi Bentze, great question!
You are entirely correct, a user with agent add access (Privileges -> Configuration -> Update) can set the value of certain EM parms, manipulate host groups, even add a new CTM Server to the EM environment!
This really needs to be addressed by BMC sooner rather than later. We really need to be able to control the channels by which users access Control-M and we need fine control over what functions they can use. We are having similar issues with Control-M Self Service because IOA security has traditionally been performed at a job owner level, not a folder\jobname level. Security is simply not granular or flexible enough.
One option we are considering is using an API gateway to lockdown which users can access which API URIs, and securing the API at a network level so only the gateway can send requests, but I haven't figured out how that works in reality yet.
3 of 3 people found this helpful
- You are right, as of today, minimum privileges to login and obtain token via AAPI must be “Category : Control-M Configuration Manager” > “Control-M Configuration Manager” = “Full”. But even if someone having AAPI access could login to the CCM (if installed), the rest of permissions/privileges can be limited (setting them to e.g. only Browse or None).
- As an example, In “Category : Control-M Configuration Manager” we can modify the value of "Configuration" to define which operations he is permitted, e.g. if we set it as "Browse", he could niether add nor delete Agents, and with "Update" he could add Agents but not delete them. - Check the following KA which details the provileges required for Control-M Automation API, and the CCM authorizations required for its different services: What privileges are required for Control-M Automation API users
- Finally, watch out for new functionalites coming in v20 and beyond. New RBA (Role Based Authorization) capabilities will allow more granularity when defining what an user is able to do depending on resources (such as Agents, Plugins, Connection Profiles and Run As definitions) he has been assigned.
Hi Paul and David. Thanks for your replies.
David, I'm definitely looking forward to more granular permissions. This is what I feel is missing at the moment.
The challenge is not to allow/not allow CCM type permissions via AAPI.
The challenge is to allow only some CCM type permissions.
For now, instead of giving the user CCM permissions, I gave him "deploy" permissions, and in combination with 'Site Standards' I've allowed him to define/run jobs that call only some CTM/Server utilities like 'ctmping', 'ctm_agstat', 'ctm_agparm' and 'ctmhostgrp'.
Thanks again for your replies and looking forward to v20...