(tresa_regular_tasks)=

# Regular Tasks

Every month, someone from TRESA should take responsibility to carry out the regular tasks on this page. In the fortnightly meeting, discuss who will have responsibility to do this that month. This person can report back to the group any changes at the next meeting.

## Track Project Budgets

It's important that TRESA keep track of the spending on Azure for active TREs.

Recall that the `TRESA - Data Safe Haven deployments` project board is viewable at `https://github.com/orgs/alan-turing-institute/projects/25/views/1`.

1. Open the GitHub issues for active SREs attached to the production SHM on the project board where the {ref}`build_tre` task is checked off as completed. These will likely be in the `Project lifecycle start` and `Live production SREs` columns.
2. For each open SRE issue, make a note of the Azure Subscription (the "subscriptionName" in the config file)
3. Use [Research compute tab (RCtab)](https://rctab-turing-prod.azurewebsites.net/) to inspect each of these subscriptions
4. If any of the subscriptions seem like they will run out of credits before the project end, you should discuss what to do about this with TRESA and the Project Team
    - Refer to the docs on {ref}`managing the TRE <manage_tre>` around budget and resourcing and {ref}`project costing <project_costing>`
5. Make sure to log any decisions and changes made in the relevant TRE GitHub issues on the project board

```{note}
The `trustedresearch@turing.ac.uk` mailbox will receive updates from RCP about Azure Credits.
```

## User Management

It's important that TRESA regularly review that the user access to active project SREs is correct. This will involve TRESA comparing the information we have saved on users in Sharepoint for each of the active SREs documented on the `TRESA - Data Safe Haven deployments` project board, with the reality of the user access granted to SRE security groups in the SHM domain controller.

TRESA need to take action when users need access to an SRE granted or revoked and delete users from the SHM when appropriate.

Recall that:

- The `TRESA - Data Safe Haven deployments` project board is viewable at `https://github.com/orgs/alan-turing-institute/projects/25/views/1`
- Each SRE GitHub issue on the board has a linked sharepoint folder, with a spreadsheet abvailable at `user-information` -> `users`, which tracks user details and their completion dates for required training and signing the Terms of Use
- As a member of TRESA, you should have access to the production {ref}`SHM environment <shm_setup>`, which can be accessed via Microsoft Remote Desktop when connected to the Safe Haven Management Gateway VPN
- The Data Safe Haven guide for user management is available [here](https://data-safe-haven.readthedocs.io/en/v4.2.2/roles/system_manager/manage_users.html#)

### Get started

1. Open the GitHub issues for active SREs attached to the production SHM on the project board where the {ref}`create_users_in_shm` task is checked off as completed. These will likely be in the `Project lifecycle start` and `Live production SREs` columns.
2. For each open SRE issue, click through on the Sharepoint link to find the users speadsheet
3. Log in to the Domain Controller VM and navigate to `Server Manager` -> `Tools` -> `Active Directory Users and Computers` and ensure you can view `Safe Haven Research Users` and `Safe Haven Security Groups`

You can then complete the tasks below as appropriate:

### Ensure users exist and are added to the correct SRE security group

1. For each SRE, check if any of the names in the spreadsheet where `Role` is `General user/researcher` are missing from the `SG <SRE ID> Research Users` security group, and check if any where `Role` is `Admin/elevated access` are missing from the `SG <SRE ID> Data Administrators` security group
2. If any users are missing from the security group, check the user exists in `Safe Haven Research Users`, and if they do [add them to the correct security group](https://data-safe-haven.readthedocs.io/en/v4.2.2/roles/system_manager/manage_users.html#modifying-user-sre-access)
3. If any users are missing entirely, follow the {ref}`create_users_in_shm` guide to set them up as usual

### Remove users from SRE security groups who shouldn't have SRE access

1. For each SRE, check if any names in either the `SG <SRE ID> Research Users` or `SG <SRE ID> Data Administrators` security groups are not listed in the spreadsheet
2. [Remove these users from the security group](https://data-safe-haven.readthedocs.io/en/v4.2.2/roles/system_manager/manage_users.html#modifying-user-sre-access)
3. You might want to check with the {ref}`role_project_team` if you think the user should have access, but is missing from the spreadsheet

### Handle users with expired training or terms of use

1. For each SRE, check if any of the names in the spreadsheet are indicated as having one or more expired training or terms of use
    - You should also check the TRESA admin users spreadsheet at `information_governance` -> `TRESA_prod4_users`
2. Temporarily [remove these users from the security group(s)](https://data-safe-haven.readthedocs.io/en/v4.2.2/roles/system_manager/manage_users.html#modifying-user-sre-access) they are in
3. Send an e-mail to each user who was removed explaining which training they need to complete, and that they should send the certificate evidence to `trustedresearch@turing.ac.uk`
    - See {ref}`training_guides` where it is explained what to do in the case of expired GDPR and Cyber Security Training
4. Once you have received the new evidence, add it to the `user-information` -> `training-certificates` folder in Sharepoint and update the relevant completion date in the `users` spreadsheet
5. [Add the temporarily removed users](https://data-safe-haven.readthedocs.io/en/v4.2.2/roles/system_manager/manage_users.html#modifying-user-sre-access) back to the relevant security group(s)

### Delete unnecessary user accounts

1. Run the script from the [Data Safe Haven guide for deleting unassigned users](https://data-safe-haven.readthedocs.io/en/v4.2.2/roles/system_manager/manage_users.html#automatically-deleting-all-unassigned-users) with the `-dryRun` flag to list users from `Safe Haven Research Users` who are not members of any of the groups in `Safe Haven Security Groups`
2. Unless you have reason not to delete any of these users, run the script without the `-dryRun` flag to delete them from the SHM

You can also manually [delete the users from the SHM](https://data-safe-haven.readthedocs.io/en/v4.2.2/roles/system_manager/manage_users.html#deleting-users).