SEB Server on Ubuntu 24.04 on Azure User Guide

Overview

SEB Server (Safe Exam Browser Server) is the open source institutional management service for Safe Exam Browser, the tamper resistant browser used to deliver secure electronic exams. From a single web administration console you register exams, define client connection configurations, connect a learning management system such as Moodle or Open edX, hand out exam configurations to candidates, and monitor every locked down Safe Exam Browser client connection in real time. The cloudimg image builds SEB Server 2.2.3 from source as a Spring Boot application (seb-server.jar) on OpenJDK 17, serving the web GUI and the REST admin API on 127.0.0.1:8080, backed by MariaDB, and fronted by an nginx reverse proxy on TCP 80. A unique administrator password is generated on the first boot of every VM. Backed by 24/7 cloudimg support.

What is included:

• SEB Server 2.2.3 (seb-server.jar) built from source on OpenJDK 17
• The web administration console (GUI) at /gui and the REST admin API at /admin-api/v1
• MariaDB holding the SEBServer schema, populated by SEB Server's Flyway migrations
• nginx reverse proxy on :80 to the SEB Server application, plus an unauthenticated /health endpoint
• A per-VM sebserver-admin administrator password generated at first boot, in a root-only file
• mariadb.service, seb-server.service and nginx.service as systemd units, enabled and active
• 24/7 cloudimg support

Prerequisites

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: allow 22/tcp from your management network and 80/tcp from the operators and Safe Exam Browser clients that reach the server. Front port 80 with TLS for public exposure, see Enabling HTTPS.

Step 1 — Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for SEB Server by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22) and HTTP (80). Then Review + create then Create.

Step 2 — Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name seb-server \
  --image <marketplace-image-urn> \
  --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 to rotate the per-VM secrets and seed 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, and the nginx reverse proxy fronts the SEB Server web console so /gui returns HTTP 200.

Step 6 — Retrieve your administrator password

The administrator password is generated uniquely on the first boot of your VM and written to a root-only file:

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; the account is created on first boot 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 reads the per-VM password and the client secret from their root-only files, proves a wrong password is rejected with HTTP 400 (invalid_grant), and then obtains 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.

You are prompted to change the generated password on first sign in; set a strong password and store it securely.

Step 9 — Explore the administration console

After signing 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, assign an exam configuration, and the Safe Exam Browser clients 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 clients reach it by your own domain.

First-boot gating and patching

SEB Server never serves traffic before the per-VM credentials exist: the seb-server.service unit is gated on a first-boot sentinel, and the base image ships fully patched 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. For production, terminate TLS at nginx with a real domain pointed at the VM's public IP. Install certbot and request a certificate (replace the domain):

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

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

Backup and maintenance

All SEB Server data, institutions, users, exams and client connection records, lives in the SEBServer schema in MariaDB. Snapshot the VM's disk in Azure to back up your data, and keep the OS patched with sudo apt update && sudo apt upgrade. The platform restarts cleanly with sudo systemctl restart mariadb seb-server nginx.

Support

This image is backed by 24/7 cloudimg support. Contact us by email and 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.