SEB Server

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet plus subnet in the target region.

Standard_B2ms (2 vCPU / 8 GiB RAM) is a good starting point. The Spring Boot JVM and MariaDB run together and benefit from the extra memory.

NSG inbound rules: allow 22/tcp from your management network and 80/tcp from the operators and Safe Exam Browser clients that reach the server. For public exposure, front port 80 with TLS (see Enabling HTTPS).

Step 1 - Deploy from the Azure Marketplace

1. Sign in to the Azure Portal, choose Create a resource, and search the Marketplace for SEB Server by SecureAnyCloud.
2. Select Create.
3. On the Basics tab, pick your subscription, resource group, region and size.
4. Under Administrator account, choose SSH public key and paste your key.
5. Under Inbound port rules, allow SSH (22) and HTTP (80).
6. Choose Review + create, then Create.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:seb-server-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name seb-server \
  --image sac1647283583153:seb-server-ubuntu-24-04:default:latest \
  --size Standard_B2ms \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard
az vm open-port --resource-group <your-rg> --name seb-server --port 80 --priority 1010

Step 3 - Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the services are running

systemctl is-active mariadb.service seb-server.service nginx.service

All three services report active. On a fresh VM, the seb-server-firstboot.service unit runs once at first boot. It rotates the per-VM secrets and seeds the administrator password before the application is allowed to start.

Step 5 - Confirm the gateway answers

curl -s -o /dev/null -w 'health -> HTTP %{http_code}\n' http://127.0.0.1/health
curl -s -o /dev/null -w 'sebserver/check -> HTTP %{http_code}\n' http://127.0.0.1/sebserver/check
curl -s -o /dev/null -w 'web console -> HTTP %{http_code}\n' http://127.0.0.1/gui

The unauthenticated /health and /sebserver/check endpoints return HTTP 200. The nginx reverse proxy fronts the SEB Server web console, so /gui also returns HTTP 200.

Step 6 - Retrieve your administrator password

First boot generates a unique administrator password for your VM and writes it to a root-only file. Read the file with:

sudo grep -E '^SEB_' /root/seb-server-credentials.txt

SEB_ADMIN_USER is sebserver-admin and SEB_ADMIN_PASSWORD is the password. The image ships with no administrator account at all. First boot creates the account with this per-VM password, so the well-known upstream default is never present on a running VM.

Step 7 - Verify the admin API authentication

SEB Server authenticates the administration API with an OAuth2 password grant against the guiClient client. The following commands read the per-VM password and the client secret from their root-only files. They prove that a wrong password is rejected with HTTP 400 (invalid_grant), and then obtain an access token with the real password:

CS=$(sudo grep '^SEBSERVER_PASSWORD=' /etc/seb-server/seb-server.env | cut -d= -f2-)
PW=$(sudo grep '^SEB_ADMIN_PASSWORD=' /root/seb-server-credentials.txt | cut -d= -f2-)
echo "wrong password -> HTTP $(curl -s -o /dev/null -w '%{http_code}' -u "guiClient:$CS" -d 'grant_type=password&username=sebserver-admin&password=wrong' http://127.0.0.1:8080/oauth/token)" curl -s -u "guiClient:$CS" --data-urlencode grant_type=password --data-urlencode username=sebserver-admin --data-urlencode "password=$PW" http://127.0.0.1:8080/oauth/token | grep -o '"access_token"' && echo "authentication OK"

The wrong password returns HTTP 400, and the real per-VM password returns a JSON response containing an access_token.

Step 8 - Sign in to the web console

Open http://<vm-public-ip>/gui in a browser. Sign in with the user name sebserver-admin and the password from Step 6.

SEB Server prompts you to change the generated password on first sign-in. Set a strong password and store it securely.

Step 9 - Explore the administration console

After you sign in, you land in the SEB Server administration console. The left navigation covers Institution, User Account, User Logs, Configurations and Exam Administration. The Institution view lists the institution the image provisions on first boot.

Open User Account to manage administrators, exam supporters and other roles. Your sebserver-admin account is listed as active.

Connecting Safe Exam Browser clients

Under Configurations, create a Connection Configuration. Then download the generated .seb file and distribute it to candidates.

Under Exam Administration, import an exam from your connected learning management system and assign an exam configuration. The Safe Exam Browser clients then connect back to this server's exam API for monitoring.

The exam API discovery endpoint is served at /exam-api/discovery. Set your server's public URL under the webservice settings so that clients reach it by your own domain.

First-boot gating and patching

SEB Server never serves traffic before the per-VM credentials exist, because the seb-server.service unit is gated on a first-boot sentinel. The base image is patched at build time and ships with unattended security upgrades enabled.

Confirm the SEB Server version

ls /opt/seb-server/seb-server.jar && echo "SEB Server 2.2.3 deployed"

Enabling HTTPS

nginx fronts SEB Server on :80. To serve SEB Server over HTTPS, terminate TLS at nginx with a real domain that points at the VM's public IP. Install certbot and request a certificate, replacing the domain with yours:

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d your-domain.example.com

After you enable TLS, set the external webservice scheme and server name in SEB Server. The exam API discovery URL that Safe Exam Browser clients receive then uses your HTTPS domain.

Backup and maintenance

All SEB Server data lives in the SEBServer schema in MariaDB. This includes institutions, users, exams and client connection records.

To back up your data, snapshot the VM's disk in Azure. To keep the OS patched, run sudo apt update && sudo apt upgrade. To restart the platform cleanly, run sudo systemctl restart mariadb seb-server nginx.

Support

This image includes 24/7 SecureAnyCloud support. Contact us by email or chat for help with institution setup, exam configuration, learning management system integration, TLS and backups.

All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.

Deploy on Azure

Launch SEB Server on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View on Marketplace

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com