Skip to content
Schoolyear AVD

Sessionhost access

One of the unique features of the Schoolyear AVD solution is that it enforces “endpoint security”. It not only secures the sessionhost to which the student has remote access, it also enforces security on the physical endpoint on which the student is working.

This endpoint security is enforced by the following three mechanisms working together:

  1. Sessionhosts can only be accessed from one specific VNET. This is configured using an Azure Private Link

  2. Students can only access that VNET through a proxy. This is achieved by not peering the VNET to any other network

  3. The proxy only accepts connections from endpoints running the Schoolyear Safe Exam Workspace. For this, you can use the Trusted Proxy provided by Schoolyear

If you make adjustments to the network configuration of the deployment template, make sure these mechanisms are still intact.

VNET configuration

It is important that students can only access the VNET of the exam when connecting from an endpoint that runs the Schoolyear Safe Exam Workspace.

In the default deployment template, this is enforced by configuring AVD to only accept connections from a Private Link.

In AVD you can configure three types of Private Links. The default template only configures a “Connection” and a “Feed” Private Link. It does not configure a “Global” Private Link, as to not interfere with other AVD deployments that may exist in your Azure tenant.

Furthermore, the VNET that is deployed for each exam is configured to not be reachable through any other means than through the “Trusted Proxy”.

Finally, the VNET has a single NAT Gateway that allows outgoing internet connections. How these outgoing connections are filtered is described later in this chapter.

Trusted Proxy

As described in the previous paragraph, the only way into the VNET of the exam is through the Trusted Proxy. This Trusted Proxy is then charged with one of the most important responsibilities in the Schoolyear AVD Solution: making sure students can only access the sessionhosts from within a secured Safe Exam Workspace endpoint.

It does this by inspecting incoming proxy requests and synchronizing with the Schoolyear APIto validate the validity of the client. This process is similar to how integrated Test Applications validate that students are using a Safe Exam Workspace.

The Trusted Proxy has the following requirements:

  • Linux x64, we recommend Ubuntu
  • Internet connection
  • One NIC in the VNET of the exam
  • One NIC that is publicly reachable on port 443
  • Enough resources to transfer RDP traffic between students and the sessionhosts

Port 443

The Trusted Proxy is an HTTPS CONNECT proxy. This means that it needs to be publicly accessible on port 443 and requires a TLS certificate. This certificate is discussed in the Quick-Start guide.

When exposing an HTTPS server to the public internet, extra considerations should be made. The following design decisions were made to reduce the security risk of this server:

  • The server is short-lived. It will be deleted at the end of the exam.
  • No other applications are hosted on the server.
  • The server does not have access to the organization’s internal network.
  • The server is developed in a memory-safe language (Go), removing any risk of heap-corruption.
  • The server does not process personal data. CONNECT proxies cannot inspect the traffic that is proxied.
  • The server is hardened against malicious TCP connections: https://blog.cloudflare.com/exposing-go-on-the-internet/.
  • We recommend using x64 servers because they have fast, constant-time implementations for many cryptographic operations.

Setup

Multiple trusted proxies are deployed per exam by running an installation script after the VM is deployed. This installation script is publicly available in our Github Repository. This script will also fetch the TLS certificate from your configured KeyVault and pass it to the Trusted Proxy. It accesses the KeyVault using the identity assigned to the VM it is running on. Therefore, it is required that this identity can read the secret of the certificate from the KeyVault and the KeyVault uses RBAC, not legacy access policies. This is all taken care of by the default deployment template.

The Trusted Proxy server does not require regular maintenance or updates because it is short-lived. Each time a new server is installed, the latest version of the proxy is used.

The Trusted Proxy requires a token to authenticate with the Schoolyear API. This token is passed as a parameter to the deployment template and is then passed as an argument to the installation script. This token is only valid for students in the specific exam.

Resources

When you notice there are latency spikes during large exams, but not in small exams, this may be due to resource-constrained Trusted Proxies. All RDP traffic for an exam is transferred by the Trusted Proxy servers, so whey they are not equipped to handle this traffic, the latency may increase. You can check this by looking at the resource usage of the proxy servers in the Azure Portal.

If your Trusted Proxies are resourced-constrained, you can take the following actions:

  • Deploy more proxies (default=2). You can adjust this number in the deployment template.
  • Use a larger VM size to give your proxy servers more resources.

Both are challenging to do while an exam is ongoing, so make sure your proxies have enough capacity before doing large exams.

ChromeOS

When using managed Chromebooks for exams with AVD, you need a specific network configuration to support Schoolyear AVD. You need to create an isolated network that only contains Chromebooks running the Schoolyear Safe Exam Workspace. This network must not be accessible to devices not running the Safe Exam Workspace. For example, these Chromebooks should not be able to show an unrestricted browser (e.g., guest mode).

This isolated network should be routed through its own public IP addresses that are not used for by other devices. These public addresses (CIDR ranges) must then be configured in the deployment template in the ipRangesWhitelist variable.

  1. Configure your exam-specific Chromebooks network and their isolated public IP.

  2. Find the "ipRangesWhitelist": [] variable in your deployment template.

  3. Add the public IP ranges to this variable. E.g. "ipRangesWhitelist": ["123.123.123.123/30", "12.12.12.12/30].

Why is ChromeOS different?

ChromeOS currently contains a bug impacting its ability to authenticate with HTTPS proxies automatically. This makes it impossible for the Trusted Proxy to validate if your Chromebooks are running the Safe Exam Workspace. By routing the ChromeOS traffic through its isolated public IP addresses, these addresses can then be whitelisted in the Trusted Proxy.