For emdash™ to function, it needs to run as a service account. That service account needs certain permissions for the system to manage that particular environment.
Here’s a rundown of functionality and the Service Account permissions that are needed. The service account name of SvcEmdash is used as an illustration through this guide - but this is defined by the Customer through the installation process.
Note that each individual environment can be managed by an isolated workflow service if required - and that workflow service would run under the context of a service account. This means that protected environments, such as Production, can be isolated and managed by different accounts to that of development or test environments.
Manage emdash Reference Data
SvcEmdash should be allocated db_owner role against the emdash™ database.
Environment Refresh – Source Database
SvcEmdash needs to have db_datareader access the following databases on the Source database instances where the application's databases are located (for SQL Server):
- The database that will be selected as Source (e.g. Endur Production, Cube Production, etc.)
Environment Refresh – Destination Database
For non-production databases, SvcEmdash should be given db_owner access to the instance. This allows for the databases to be overwritten through the restore process.
This is true for SQL Server for Endur/Cube. It will also need admin rights to SSIS, SSRS and SSAS for Cube refreshes.
It is not recommended that the service account is given sysadmin rights.
For the full environment refresh process to function, the service account needs to be able to start/stop services and allocate users in Active Directory. See the Create User/Create Group sections below for details of the permissions needed for this.
To perform code upgrade functions, the database rights are needed as per Environment Refresh.
In addition to database permissions, the Service Account will need to have local admin rights on all application servers. This is needed so that code binaries can be copied from the repository to the Citrix and Application Servers.
Write permissions are required on the Fileshare for code upgrade components that write files here (For example, Cube, ESS, ECMS, ESS Scripts).
Read permissions are needed on the Repostory fileshare where the core code binaries are stored.
Rebuild Endur Config Files
Local admin access is required on all Endur application servers to query the value of ‘ENDUR_DRIVE_LETTER’ and the IP Address of the server for rebuilding the config files.
Write permissions are required on the Fileshare to create the files (and archive the previous version of the files).
To backup databases, the Service Account needs the Backup Operator role on the database instance and database.
To query processes the service account needs local admin access on the application servers to look for rogue or orphaned Endur processes.
Start / Stop Services
To start/stop services, the service account needs local admin access on the application servers.
OPTIONAL - Reset Password (Endur)
To enable emdash™ to reset a user’s Endur password, the Service Account needs permissions on the SQL instance to be able to do this.
For non-Prod environments this will be inherited through the allocation of sysadmin.
For Production database instances, the SQL Login for SvcEmdash will need the following:
GRANT ALTER ANY LOGIN TO <domain>\SvcEmdash
OPTIONAL - Reset Password (Windows)
To allow for Users’ passwords to be reset SvcEmdash will need elevated permissions to manage Active Directory.
This can be activated through the ‘Delegate Control’ function in Active Directory.
This needs to be done at the root of the Active Directory where the users are created.
Following the Delegate Control wizard allows for granular allocation of elevated rights. This is the option that needs to be selected for this purpose:
OPTIONAL - Create User or Group Allocation
Similar to resetting passwords, the emdash Service Account needs to have elevated rights to AD to be able to create users and groups if that is a function you require. It will also need this to assign or remove users from an environment where it adds/removes users to the AD Groups for that environment.
The location of the Organisation Unit in AD that is used for this purpose is controlled by a number of System Wide Settings in emdash™.
In the screenprint above you can see that Production Groups and Users are managed in the ‘PRODOU’ and ’PRODUSEROU’ settings and non-Prod are separated out into another OU.
Delegated Control is needed at the root level for the Service Account – for the cwjad.local domain illustrated this would be at the next level down in the ‘emdash’ folder.
These are the options that should be selected: