Authelia with LLDAP

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is a comfortable starting size for both services.

Configure the network security group (NSG) with these inbound rules:

• Allow 22/tcp from your management network for SSH.
• Allow 443/tcp for the sign-in portal.
• Allow 80/tcp so that plain HTTP requests are redirected to HTTPS.
• Allow 17170/tcp (LLDAP admin UI) and 3890/tcp (LDAP) only from the networks that need them, normally your own VNet. The LDAP endpoint is a plain connection.

You also need a hostname, not just the VM's IP address. Authelia scopes its session cookie to a domain and marks it secure, so a browser keeps you signed in only when you reach the portal over HTTPS at a hostname under that domain.

Step 6 shows a one-line workstation change that lets you try the portal immediately. Step 10 shows how to switch to your own domain for production.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Authelia with LLDAP by SecureAnyCloud, and select Create.

On the Basics tab, 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 HTTPS (443).

Review the dedicated data disk on the Disks tab, then select Review + create and Create. After deployment, add inbound rules for HTTP 80, and for 17170 and 3890 restricted to your VNet.

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:authelia-lldap-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name authelia-lldap \
  --image sac1647283583153:authelia-lldap-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --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 authelia-lldap --port 443 --priority 1010
az vm open-port --resource-group <your-rg> --name authelia-lldap --port 80 --priority 1020
az vm open-port --resource-group <your-rg> --name authelia-lldap --port 17170 --priority 1030
az vm open-port --resource-group <your-rg> --name authelia-lldap --port 3890 --priority 1040

Step 3 - Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 - Confirm both services are running

The portal and the directory are separate systemd units. Both must be active, and the first-boot unit must have completed.

systemctl is-active lldap.service authelia.service nginx.service

Confirm that each service is listening where it should. Authelia binds only to loopback, and nginx is the single public front door. Port 9091 must therefore never appear on 0.0.0.0.

sudo ss -tlnp | grep -E ':(80|443|3890|9091|17170) ' | awk '{print $1, $4}'

Confirm that the shared data disk carrying both datastores is mounted.

findmnt -no SOURCE,TARGET,FSTYPE /srv/sso && df -h /srv/sso | tail -1

Step 5 - Retrieve your per-VM admin login

The VM generates the admin password on first boot and writes it to a root-only file. The same password signs in to both the Authelia portal and the LLDAP admin UI.

sudo cat /root/authelia-lldap-credentials.txt

Confirm that only root can read the file, and that this VM generated its own TLS key instead of shipping one baked into the image.

sudo stat -c '%a %U:%G' /root/authelia-lldap-credentials.txt
sudo stat -c '%a %U:%G' /etc/nginx/ssl/authelia-selfsigned.key

Step 6 - Reach the portal

Authelia is domain-based. It marks its session cookie secure and scopes it to the configured cookie domain. If you browse to https://<vm-public-ip>/, the sign-in page renders, but the browser discards the session cookie and sign-in does not stick. This is Authelia's design, not a limitation of the image.

The image ships with the default domain auth.example.com. To try the portal straight away, point that name at your VM by adding one line to your workstation's hosts file (/etc/hosts on macOS and Linux, C:\Windows\System32\drivers\etc\hosts on Windows):

<vm-public-ip> auth.example.com

Then open https://auth.example.com/ and accept the certificate warning. The warning appears because the VM generated its own self-signed certificate on first boot. Step 10 replaces both the default domain and the self-signed certificate for production.

Before you open a browser, you can confirm from the VM itself that the portal and the redirect are healthy:

curl -s -o /dev/null -w 'portal https: %{http_code}\n' --resolve auth.example.com:443:127.0.0.1 -k https://auth.example.com/
curl -s -o /dev/null -w 'http redirect: %{http_code}\n' -H 'Host: auth.example.com' http://127.0.0.1/

Step 7 - Sign in to the single sign-on portal

Open https://auth.example.com/ and sign in as admin with the password from Step 5.

The portal greets you by display name and shows an Authenticated status. The display name comes from the LLDAP directory entry, so this screen confirms that the portal and the directory are talking to each other.

Step 8 - Manage users and groups in the directory

Open the LLDAP admin UI at http://<vm-public-ip>:17170/ and sign in with the same admin credentials. The Users page lists every account in your SSO estate.

The Groups page shows LLDAP's three built-in groups: lldap_admin, lldap_password_manager and lldap_strict_readonly. Use them to delegate directory administration. Create your own groups alongside them to drive Authelia access control rules.

Step 9 - Create a user and prove single sign-on works

In the LLDAP admin UI, choose Create a user. Give the account a user ID, a display name and an email address, then set a password from the user's detail page.

Because Authelia has no user database of its own, that account can sign in to the portal immediately, with no restart and nothing to synchronise.

You can prove the whole path from the command line. The commands below bind to LDAP as the new account, then sign the same account in through the Authelia portal.

ldapwhoami -x -H ldap://127.0.0.1:3890 \
  -D "uid=<new-user>,ou=people,dc=example,dc=com" -w '<their-password>' curl -s --resolve auth.example.com:443:127.0.0.1 -k \
  -H 'Content-Type: application/json' \
  -d '{"username":"<new-user>","password":"<their-password>","keepMeLoggedIn":false}' \
  https://auth.example.com/api/firstfactor

A response containing "status":"OK" means Authelia authenticated that user against LLDAP.

To check the current directory contents at any time, bind as the admin and list the accounts:

PW=$(sudo grep -m1 '^AUTHELIA_LLDAP_ADMIN_PASSWORD=' /root/authelia-lldap-credentials.txt | cut -d= -f2-) ldapsearch -x -LLL -H ldap://127.0.0.1:3890 \
  -D 'cn=admin,ou=people,dc=example,dc=com' -w "$PW" \
  -b 'ou=people,dc=example,dc=com' '(objectclass=person)' uid mail displayName

Step 10 - Switch to your own domain and a real certificate

For production, point a hostname you control at the VM and tell Authelia about it. Edit /etc/authelia/configuration.yml. Set session.cookies[].domain to your registered domain, and set session.cookies[].authelia_url to the HTTPS URL of the portal on that domain.

The authelia_url value must use https://. Authelia refuses to start otherwise.

sudo nano /etc/authelia/configuration.yml
# session:
# cookies:
# - name: 'authelia_session'
# domain: 'your-domain.com'
# authelia_url: 'https://auth.your-domain.com'
sudo systemctl restart authelia

Replace the self-signed certificate with one issued by a certificate authority. Install your certificate and key at the paths nginx already reads, then reload nginx:

sudo install -o root -g www-data -m 0644 fullchain.pem /etc/nginx/ssl/authelia-selfsigned.crt
sudo install -o root -g www-data -m 0640 privkey.pem /etc/nginx/ssl/authelia-selfsigned.key
sudo nginx -t && sudo systemctl reload nginx

To use Let's Encrypt instead, install certbot and point the nginx TLS directives at the issued certificate.

sudo apt-get update && sudo apt-get install -y certbot
sudo certbot certonly --standalone -d auth.your-domain.com

Step 11 - Protect an application with forward authentication

Authelia sits in front of your other applications. On any nginx that fronts an app, send each request to Authelia first, and proxy it on only if Authelia approves. The essentials look like this:

location /authelia { internal; proxy_pass http://<sso-vm-ip>:443/api/authz/auth-request; proxy_set_header X-Original-URL $scheme://$http_host$request_uri; } location / { auth_request /authelia; auth_request_set $user $upstream_http_remote_user; proxy_set_header Remote-User $user; error_page 401 =302 https://auth.your-domain.com/?rd=$scheme://$http_host$request_uri; proxy_pass http://<your-app>; }

Add access control rules to /etc/authelia/configuration.yml to decide which LLDAP groups may reach which applications. Until you add rules, the shipped default_policy of one_factor lets any account in the directory sign in.

Maintenance

Both datastores live on the dedicated data disk, so a snapshot of that disk captures your whole directory and the portal's session state.

sudo ls -l /srv/sso/lldap /srv/sso/authelia

Check the health endpoint, which stays on plain HTTP so monitoring never needs the certificate:

curl -s -o /dev/null -w 'health: %{http_code}\n' http://127.0.0.1/health

Review the logs for either service:

sudo journalctl -u authelia.service -n 30 --no-pager sudo journalctl -u lldap.service -n 30 --no-pager

Apply operating system updates on your normal patching schedule:

sudo apt-get update && sudo apt-get -y upgrade

Support

SecureAnyCloud provides 24/7 support for this image. Contact sales@secureanycloud.com with your Azure subscription ID and the VM name. For questions about Authelia or LLDAP themselves, see the Authelia documentation and the LLDAP project.

Deploy on Azure

Launch Authelia with LLDAP 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