I'm a sysadmin managing several fully automated business processes, utilizing both Power Automate desktop flows and a third-party automation tool. Recently, New York state has put strict regulations in place, one of which prohibits interactive logins. I'm curious if anyone has ideas on how my bot accounts can function without interactive login enabled since they rely on active RDP sessions to run the automation smoothly. Any insights would be greatly appreciated!
2 Answers
It might be wise to chat with your boss or touch base with your InfoSec or compliance teams about this. They could provide clarity or alternative options you might not have considered yet.
If your bot doesn’t need direct access to a graphical OS, you might want to consider blocking the account from local logon through local security policy. You can do this by going to Local Security Policy, navigating to User Rights Assignment, and editing the "Deny log on locally" feature to include your service account. This is a good way to test if the bot can still work without that access.
However, if your automation uses RPA to simulate a user, you’ll need to document an exception for that account. It's a tight spot since we heavily rely on RPA for many tasks—you might find that disabling local logon will necessitate rewriting your automation scripts from scratch.
Moreover, if you're considering gMSA accounts, they do inherently restrict the right to log in locally, which can be advantageous for compliance. But remember, while they’re designed for automation, there are still some vulnerabilities associated with them that can be found in various resources. Just make sure you document any exceptions needed!
This week, our team is set to test our RPA processes with the gPO already in place. We're also planning to file an exception and collaborate with our security team to ensure compliance with PAM solutions.
I’m on it! I’m trying to gather some different options we haven’t thought of to present to them.