5 of 5 people found this helpful
We are using CyberArk to issue the ctmsetown command for Windows RunAs IDs. Previously we'd been adding the ID & Password to the Agent on each host that executed jobs for that ID. Now we define to Control-M and All Hosts, letting Active Directory dictate which servers the ID is authorized on. Our Security team worked with the CyberArk vendor to get it working.
In a nutshell, for each ID that CyberArk manages, it changes the PW every 60 days in AD, then it updates the password in Control-M.
As new IDs are created, they get set up in CyberArk and then it adds the ID/Password to Control-M.
Thanks Tammy, Would you be open for a phone call to discuss with us?
Hi Todd, Yes, I sent you a private message.
Hi Tammy, i would really like to understand how this was fully implemented. We are looking into have Control-M work with CyberArk and Cyberark's AFT.
We had a CyberArk consultant write the plug-in to Control-M (it doesn't come out of the box).
CyberArk changes the PW in Active Directory and then on the Control-M Server(s) using the ctmsetown command. CyberArk is not managing our passwords for any of the Connection Profiles (e.g. AFT).
Hi Tammy, thank you for you answer.
There must be a way to get this plugin also or are you proprietary?
1 of 1 people found this helpful
We were told in order for it to be supported by CyberArk, they had to write the plug-in. If your company has CyberArk, I would suggest you speak to your contact there.
Thank. I just did!
Big thanks for your help.
Hi all, we've just been tapped to add Control-M credentials to Cyberark.
I was just wondering if anyone has had any issues\concerns about jobs running between the AD credentials being updated and the ctmsetown being issued successfully? Has anyone experienced any job failures since adding credentials to Cyberark?
We've had just a few failures since using CyberArk to manage our Control-M AD accounts. It takes a few minutes for the password change to sync between AD and Control-M, so if a Control-M job submits after the AD and before the ctmsetown command, it will fail. We have different CyberArk rules so some teams opt to change PWs only on a certain day/time to try to prevent that. Overall, we've been pretty happy with it. We do however, not allow teams to use the same ID in Connection Profiles since CyberArk isn't updating those passwords.
The v20 Q&A raised this point last week -
Q For the AWS/Google/Azure plugins - are there any plans to tie in with a third-party auth service such as vault to get credentials instead of having to hard-code them in the profiles?
A Yes, we do plan to support vault integration, while our first provider would be Cyberark.
1 of 1 people found this helpful
Thanks Tammy Ryan
Yes we've identified that we'll need to hold jobs to cycle the password or identify non-batch times for individual applications and customise the cycle time.
We've also had the contractors custom code an integration using the Automation API as I wasn't comfortable giving them access to run utilities on our server. I haven't been impressed with Cyberark really, the web gui is pretty poor and there doesn't seem to be many working integrations out of the box. A lot of limitations that are not much better than doing updates manually and using a cheaper vault.
Good to know Mark Francome. Look forward to seeing how that works and what the performance is like :-)