Service Account Requirements

The service accounts that run each component have different requirements in terms of security and access within your environment and within the Privileged Identity software. Because of these different requirements, we recommend using multiple service accounts to separately perform the specific functions of the software, minimizing permissions granted for any component service account. Alternatively, you may use the same service account for all functions of the software if doing so better meets your business needs.

Web Service Identity

Privileged Identity uses a COM application for its interactions from the web service server to the application database. This application requires the use of a privileged account. The account can be configured as a NetworkService if using explicit database authentication (SQL account), though it should be configured as a domain member when using Integrated Windows Authentication to the database. If using a named identity, the account should have the following rights and memberships:

• Administrator of the web server host system (required)
• Domain user (recommended when authenticating domain users or working with domain groups)
• Log on as a batch job
• DBO rights for the application database (if using integrated authentication)

Deferred Processor / Zone Processor Service Identity

Privileged Identity performs all scheduled jobs, such as password change jobs or password verification reports, by using a service on the management console host system or by using a standalone service called a zone processor. This application requires the use of a privileged account. The account should be a domain member (as applicable) and should have the following rights and memberships:

• Administrator of the management console host system
• Log on as a service
• DBO rights for the application database (if using integrated authentication); system admin of the database not required
• Administrative rights over target managed systems

If the service account/interactive user account cannot be an administrator of the target systems, then you must configure an alternate admin account for use by the software. If possible, avoid the use of alternate admin accounts when managing COM and DCOM objects. Also avoid scheduled tasks, as these interfaces do not allow for impersonation.

For more information, please see the Privileged Identity Admin Guide.

 

The account used to run the deferred processing service cannot manage itself. If you manage this account through a scheduled job, then any job being run by that processor at that time is stopped mid-process. This leaves the job in a locked and incomplete state, requiring an administrator to resolve the issue. This also causes all other scheduled jobs to stop running until an administrator manually starts the service.

An alternative to using a named service account for the scheduling service is to configure the service to run as LocalSystem or as a Microsoft Managed Service Account (MSA). This negates password management requirements for the service.

However, you must also grant permissions to the database for the computer account (ComputerAccountName$) and ensure that the computer account is seen as an administrator of all managed systems. If the computer account is added to a new group in Active Directory to provide these administrative rights, the computer must be restarted.

Syslog Forwarder Service Identity

The syslog forwarder captures syslog or MSMQ UDP output and forwards the traffic using TCP or TCP with SSL to a target collector. This program requires a Windows service to run. The account can be a local user account or domain account and must be granted Log on as a service.

For more information, please see the Privileged Identity Admin Guide.