On-Prem Agent - service account bloat?

[mppowe]

We're just starting to use the OPA for some things and I'm anticipating some security concerns down the road.  We're exploring automating a Phishing Response.  When we find out that an account has been compromised, we can run a recipe that will reset the password for the compromised account, disable them in AD, kill their Office 365 sessions, create a helpdesk ticket and post something to Teams.

As I explore the first couple parts, those are privileged actions in AD and O365.  The best way to accomplish those, I think, is by executing Powershell scripts, but the Workato service account running the OPA is the user who will have privileges to do those things.  And as time goes on and we do more things with the OPA, that one service account will accumulate more and more privileges.

How are other people handling this situation?  Or does Workato have on their roadmap a more granular way to handle OPA actions and security?

Thanks!

[meghan-legaspi]

Hey @mppowe,

Apologies for the delay and thank you for this feedback.

It's recommended to use connectors whenever possible (AD, Office via Graph API) directly from Recipe instead of PowerShells script. This way all the logins/Connections are saved to specific system from within the Workato instance and minimize amount of powershell responsibility.

Maybe you could pass the user that should run the script as parameter to the script from Workato Recipe, use encryptor/decryption to store hashed passwords in Workato connector, then pass over to script?

Someone on my team also had the idea to run multiple on-prem groups with different permissions, if you're able.

Let me know if this helps!
Meghan

[mppowe]

Thanks Meghan, I hadn't considered having multiple on-prem groups with different permissions.  So does that mean we could have multiple instances of the on-prem agent running on the same servers?  For example, we have 2 servers for redundancy, each running one instance of the on-prem agent.  Can we have, say, 3 instances running, one that handles our Active Directory operations, one that does Office 365 admin functions, and another that does other operations?

One other reason we couldn't use the AD connector is b/c it didn't have the operations we were looking for, like resetting a password or disabling an account.  And unlike other web API-based connectors, I'm not sure we can do custom actions with the AD connector?

[kbudurka]

Hi @mppowe .

Did you ever find an answer to your question about running multiple instances of the OPA on the same server?
I am facing this situation myself and I don't really want to create Hyper-V sessions for each connector.

[mppowe]

Hi @kbudurka , yes I created multiple on-prem groups in our Dev and Test environments.  It meant installing an on-prem agent on our server, configuring it to run as a specific user with specific privileges, and then in Workato associating the Connection with that particular OPA.  This is not in Prod yet as we haven't built out the actual recipes yet (different priorities trumped the previous request), but it does seem like it will address the issue.