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 RED Account Reset Management 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 Application Identity

Privileged Identity uses a COM application for its interactions from the web server to the application database. 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 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)

Note: If a single implementation of Privileged Identity will manage multiple trusting domains and if you use Active Directory for user authentication or Integrated Windows Authentication to the database, then the COM identity must be a trusted user for the target domains. Otherwise, you must manually configure an authentication server entry with explicit credentials for that domain.

The COM application must be configured to run as a user; this account can be automatically managed by Privileged Identity.

Note: The COM account, if using a separate account from the deferred processing account, may need admin rights over target Windows systems. This right is a requirement ONLY IF the web app option to Block password check-in if account is in use is enabled. Enabling this option allows the COM application to enumerate all active sessions and determine if the specified account is still logged in according to the target Windows system.

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)

Note: If a single implementation of Privileged Identity will manage multiple trusting domains and if you use Active Directory for user authentication or Integrated Windows Authentication to the database, then the COM identity must be a trusted user for the target domains. Otherwise, you must manually configure an authentication server entry with explicit credentials for that domain.

The COM application must be configured to run as a user; this account can be automatically managed by Privileged Identity.

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

Note: 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

IMPORTANT!

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 via 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