Windows permissions for database service accounts

When configured with Trust Protection Foundation to use Windows integrated authentication to a MSSQL database, you must allocate the following permissions to the database service accounts on all Trust Protection Foundation servers:

Service Account	Log On as a Service	Log On as a Batch Job	Local Windows administrator group
Database owner account (Also DBO account) This is a service account that Trust Protection Foundation uses for installations, upgrades, and administrative maintenance of the database. It can be a domain service account when used with Windows integrated authentication, or a MSSQL account when used with MSSQL authentication. This account requires "Log On as a Service" permissions on all Trust Protection Foundation servers. See also operational database account.
Operational database account (Also limited database account) This is a service account that Trust Protection Foundation uses for everyday operations. It can be a domain service account when used with Windows integrated authentication, or a MSSQL account when used with MSSQL authentication. This account requires "Log On as a Service" permissions, and also needs to be part of the Local Administrators group, on all Trust Protection Foundation servers. Database grants for this account are automatically managed by the system. See also database owner account.

With Windows integrated authentication, the CyberArk Windows services and IIS application pools will be configured to launch as the operational database account. We require the security permissions "Log On As a Service" and " Log On As a Batch Job" on all Trust Protection Foundation servers. The CyberArk installer will attempt to apply permissions automatically, if possible; however sometimes enterprise group policy domain settings prohibit us from making that change. In these cases, you will need to work with your Active Directory team to grant both database service accounts the permissions specified in the table above.

NOTE If you use the same account for both roles, that account must have all three permissions: Log On as a Service, Log On as a Batch Job, and be a member of the Local Windows administrator group.

For more information on the Log On as a Service permission, see the Microsoft TechNet article Log on as a service.

For more information on the Log On as a Batch Job permission, see the Microsoft Windows Server forum post Log on as batch job right.

You can use Group Managed Service Accounts (gMSAs) to minimize the administrative maintenance. See Using Group Managed Service Accounts (gMSAs).

NOTE If you use a Group Managed Service Account (gMSA) for Windows integrated authentication, the administrator account must also be granted the Debug programs user right (SeDebugPrivilege). You can review or set this right in the Local Security Policy (secpol.msc) under Local Policies > User Rights Assignment, where it is assigned to the Administrators group by default. In many environments, your Active Directory team must apply this through Group Policy.