Service Account Permissions After a Security Review
Following a security review, an organisation tightened permissions on its Blue Prism environment. The application service account was removed from a broad administrative group and given only the rights the reviewer believed were needed. After the change, attended users can log in but cannot see their queues, and scheduled processes fail at the point where they read from a network file share. The runtime resources run under a separate service account that was also restricted. The reviewer also disabled interactive logon for both service accounts. The organisation uses role-based access control within Blue Prism, and the roles were not changed during the review. The file share previously allowed the runtime service account full control and now allows only read for a named group the account is not in.
1. Diagnose the queue visibility problem. Why would tightening the service account break role-based visibility when the roles themselves were unchanged?
Read the worked answer
Role-based visibility in Blue Prism is evaluated in the context of the database permissions the application uses, and the symptom points at the application service account losing rights it needs to resolve or return data, not at the roles.
Investigate in this order:
- Database permissions. Confirm the service account still maps to a user in the Blue Prism database with the role membership the application expects. Removing it from a broad group may have removed inherited database rights that were never granted explicitly.
- Explicit grants. Re-grant the minimum set the application requires directly to the account, rather than restoring group membership, so the review's intent is preserved.
- Role membership. Verify the affected users' Blue Prism roles are intact and that queue access is granted to those roles. If queues were scoped to a role the users still hold, the failure is on the data-access path, not the role definition.
- Reproduce with a test user holding the same role, to separate a per-user problem from a platform-wide one.
The lesson is that inherited group membership was silently carrying required rights. The fix is to make those rights explicit and documented, then re-test before closing the change.
2. Address the file share failure and the disabled interactive logon together. What is the correct configuration, and what will break if it is left as is?
Read the worked answer
File share. The runtime service account lost access because the share now grants read to a group it is not in. Grant the runtime service account read access to the specific share path it needs - not full control, and not by re-adding it to a broad group. Least privilege here means read on the exact path. Confirm the account the process actually runs under, since a process may run under a different credential than the machine's service account.
Interactive logon. Disabling interactive logon for service accounts is correct hardening and should stay. It does not prevent a service from running, provided the account holds the logon-as-a-service right and the service is configured with that identity. Verify that right explicitly - if the reviewer removed it along with the administrative group, services will fail to start rather than fail at runtime, which is a different symptom from the one reported.
If left as is: the file share failure will recur on every process touching that path, and the environment will drift toward ad hoc exceptions granted under pressure. Document the explicit grants, the logon rights, and the accounts they apply to, and add a post-change verification step so the next review does not silently break the platform again.