Enterprise Alert (EA) is three tier application that consists of a database layer, an application layer and a presentation layer.
The database layer is shaped by Microsoft SQL Server. Related executables can run under certain user or machine accounts, depending on scenarios and security requirements. Communication with that layer from components in the other layers works via TCP/IP protocol and specific authentication schemes to DMBS assets. Due to this interface to the database layer, it is relatively agnostic for the EA application integrity under which user account the DMBS executables run.
Local Administrator Account for EA executables required
A different situation can be found in the presentation and the application layer. The components of Enterprise Alert in these layers need to run under a local system or local administrator account. The key reason for this requirement is to allow for cross layer and cross component communication of related EA components.
Example where admin rights are essential
Let’s illustrate an example where the presentation layer communicates with a web server component which is belonging to the application layer. The web applications and web APIs of Enterprise Alert need to query the config of the IIS web server to obtain registered virtual path mappings. This configuration read request from the web applications fail when the related IIS application pool run-as account is not running as local system or as a local administrator. Instead, an error like this one will be displayed in the EA web portal log file:
Exception Details: System.UnauthorizedAccessException: Filename: redirection.config
Error: Cannot read configuration file due to insufficient permissions
The suggestions to resolve this problem is to simply run the application under a local system or administrator account.
The illustrated example where communication from the presentation layer with the application fails when Enterprise Alert components do to run as local administrator is only one example.
Enterprise Alert uses multiple other components and resources on the machine, e.g. for inter-process communication (MSMQ) or file system access.
These components work best together when they run under local system or a local administrator account. As the VM itself needs to be hosted for EA exclusively, fine-tuning access permissions on a machine-level has limited benefits anyways.
Isolating the machine account of the computer that hosts EA in your network domain is however strongly recommended, as with Windows-Authentication, any workload that runs as local administrator or local system on the EA machine will authenticate as DOMAIN\EAMACHINE$ in your network.
In example, limiting access permissions for this account on your SQL Server, is highly recommended.