When you set up users in the Reference Data – Users screen, you have a number of Types that you can set. For Endur, the following are recommended, and the functionality of Add/Remove Users changes accordingly:
|
User Type |
Function |
|
|
Endur User |
This is 90% of users. On Add/Remove the AD account is found and added into the Endur AD Group for the environment, and the corresponding Endur login is enabled within Endur itself.
If the ‘Administrator’ role is selected when mapping the user to the environment, the Endur User is allocated to the ‘Administrator’ security group within Endur, and the SQL Login is given elevated rights on the database. |
|
|
Endur System Account |
This is the application servers, or the Administrator Endur user. The process is the same as above, but no Windows account exists, so emdash does not try to find or allocate an AD User to the AD Group |
|
|
Endur SQL Group |
This can be the name of a Windows Group that you want to have access to the database after an Environment Refresh. This can be useful for developers to have access to a database via SQL Management Studio, for instance.
If the ‘Administrator’ role is selected for this user, they are given db_owner rights on the database.
Conversely, if you give them the ‘Read Only’ role, they only get db_datareader rights on the database. This gives some flexibility.
Note: You can add the EndurDev<EnvName>Access group name as an emdash User of type ‘Endur SQL Group’. This means that all users allocated to the environment will get database rights, and membership is controlled via emdash in the same way as Endur Users. |
|
0 Comments