Setting up permission in a windows server for NPA access

Help Orchestrator
1

Title:

Minimum Permissions Required for Unattended Robots on Windows Servers

Hi everyone,

We’re in the process of configuring a new unattended robot environment and want to ensure we’re following least-privilege principles from the start.

We have robot service accounts that need to execute jobs on Windows servers through Orchestrator. We’re trying to understand the minimum permissions, user rights assignments, and local group memberships required for unattended execution to work reliably.

Currently, we’ve assigned:

  • Log on as a batch job
  • Allow log on through Remote Desktop Services

However, when Orchestrator attempts to initiate the remote session and start a job, the connection is failing.

A few questions for those who have implemented unattended robots in production:

  1. What are the minimum Windows permissions required for an unattended robot account?
  2. Are there any local groups the robot account should belong to besides standard Users or Remote Desktop Users?
  3. Are there specific Windows security policies that are commonly overlooked?
  4. Is there anything that needs to be configured differently in Orchestrator when using a non-administrative service account?
  5. Has anyone successfully deployed unattended robots using standard user permissions only, and if so, what permissions or group memberships were required?

Our goal is to avoid granting unnecessary elevated privileges while ensuring Orchestrator can establish sessions and run automations successfully.

Any guidance, best practices, or documentation references would be greatly appreciated.

Thank you!

2

Hi @Giraldo_Juan_P ,
For Unattended Robots, you can often run with a standard user account, but a few permissions are mandatory.

Minimum Windows Rights

  • Log on as a batch job
  • Allow log on through Remote Desktop Services
  • Read/write access to required folders, applications, network shares, and files used by the automation

Recommended Group Memberships

  • Remote Desktop Users
  • Users (standard user group)
  • Avoid Local Administrators unless the automation specifically requires elevated privileges

Commonly Missed Settings

  • Account must not be disabled or locked
  • Password must be valid and synchronized with Orchestrator
  • Check GPOs that deny RDP logon or batch logon
  • Ensure the robot machine can reach Orchestrator and required applications

Orchestrator Configuration

  • Verify the unattended robot account username/password in Orchestrator
  • Confirm the machine template/runtime is assigned correctly
  • Test creating an unattended session manually before running jobs

Best Practice

  • Start with a standard user account and grant only the additional permissions required by the target applications.
  • Only use administrator rights if a specific application or automation step requires them.

Thanks

3

@Giraldo_Juan_P

this page shows the exact permissions and configuration. We follow the same and it works

cheers

4

@Giraldo_Juan_P Hi,

You should be able to run unattended robots without giving the Windows account local administrator rights.

For a standard unattended setup, I would first check the following:

  • Add the robot/service account to the Remote Desktop Users local group.

  • Grant Allow log on locally under Local Security Policy > User Rights Assignment.

  • For High-Density/RDP-based execution, also make sure Allow log on through Remote Desktop Services is granted.

  • Access this computer from the network is also required for High-Density Robot scenarios.

One thing I noticed in your configuration is that you have Log on as a batch job, but UiPath’s unattended Robot prerequisites specifically mention Allow log on locally. I would check that first.

Also check the corresponding Deny log on locally and Deny log on through Remote Desktop Services policies. A deny policy will override an allow policy, and domain GPOs can overwrite the local server settings.

On the Orchestrator side, verify that:

  • The Windows Domain\Username and password configured for unattended execution are correct.

  • The machine template has an available unattended runtime.

  • Both the machine template and account are assigned to the correct folder.

  • If you are using an RDP session, check Robot Settings > Login To Console. Setting it to No makes the Robot use an RDP session.

UiPath also documents that users configured for High-Density Robots do not need administrator rights; they can be members of Remote Desktop Users instead.

So I would not add the account to Administrators just to resolve this. I would start with Remote Desktop Users + Allow log on locally, then verify the GPOs and Orchestrator Windows credentials/session configuration.

Hope this helps.

5

Hi @Giraldo_Juan_P

Unattended Robots generally do not require local administrator rights.

A standard Windows user with Log on as a batch job is usually enough. Remote Desktop Users is only required if RDP access is needed.

Also check Group Policy and Orchestrator machine/user configuration if the session is failing.