The RUN_AS passwords are stored (encrypted) in Control-M/Server database but are used to authenticate a user against the OS or Active Directory, depending on how the OS on the Control-M/Agent host is configured.
So at the basic format, the password needs to comply with the OS/Active Directory password rules.
The issue you had, was it:
1. The password stored in CTM/Server was wrong?
2. The password stored in CTM/Server was correct, but the authentication against the OS/AD failed?
My guess is #1 is what you faced.
I don't think there are any "rules" in Control-M that limit what these passwords can be. So I would look at how the integration between Cyberark and Control-M takes place? Meaning, I'm assuming that Cyberark passes the password to Control-M so it gets stored there. It probably uses AAPI's 'ctm config server:runasuser::update' service or the CTM/Server utility 'ctmsetown' to store the new password in Control-M. Maybe this integration is managing the password in a way that makes special characters not come across correctly?
The way I would test is:
- change the password for a RUN_AS user to include special characters in it
- Use CCM GUI to set the new password in Control-M
- Test the new set password works? You can use the CCM GUI's test option or run a job.
If it does work, so the issue is with the integration from Cyberark to Control-M.
BTW, if the integration uses AAPI so you can enhance it by adding the 'ctm config server:runasuser::test' call which can be used to validate the RUN_AS user works and this way identify potential problems when the password is updated rather than when jobs run.
1 of 1 people found this helpful
In general the product will take any alphanumeric character and the underscore symbol as valid characters.
However, you can use special characters if you escape them. BMC have a help note for this -
(each special character must be escaped with a backslash).