Authelia with LLDAP 4.39.28 on AWS User Guide

Overview

This guide covers launching and using the Authelia with LLDAP 4.39.28 on Ubuntu 24.04 AMI from cloudimg on Amazon EC2. It is one version of the cloudimg identity, secrets and PKI listing on AWS Marketplace; you pick it as the software version when you subscribe and launch.

Two open source projects work together on one instance:

• Authelia is an authentication and authorisation server. It sits beside a reverse proxy and answers one question for every request to the applications behind it: is this person signed in, and are they allowed here? People sign in once at the Authelia portal, with a password and optionally a second factor (one-time codes from an authenticator app, security keys or passkeys), and that single sign-on session opens every application you put behind the proxy.
• LLDAP is a light LDAP directory with a web interface for managing users and groups. Authelia uses it as its only user store: the people you create in LLDAP are the people who can sign in, and their LLDAP groups can be used in Authelia's access rules. Other software on the instance can use the same directory over LDAP.

The cloudimg image is a working forward-authentication gateway with a directory out of the box:

• nginx in front, Authelia and LLDAP behind it. nginx is the only public listener (ports 80 and 443). Authelia listens on 127.0.0.1:9091, LLDAP's LDAP service on 127.0.0.1:3890 and its web admin UI on 127.0.0.1:17170, all on the loopback address only. You open the LLDAP admin UI through an SSH tunnel. A demo protected application shows the whole sign-in flow.
• HTTPS from the first boot. nginx serves the portal and the demo application with a certificate generated on your instance's first boot (an end-entity certificate, not a certificate authority), and port 80 redirects to HTTPS.
• No default login, nothing shared. The administrator password, Authelia's session secret, storage encryption key and directory bind password, and LLDAP's token signing secret and key seed are generated on the first boot of each instance. The image contains no directory, no secret and no certificate, and LLDAP, Authelia and nginx refuse to start until first boot has created them.
• Least privilege between the two. Authelia connects to LLDAP with its own account, authelia, which is in LLDAP's lldap_strict_readonly group: it can look users up and check passwords, but it cannot change anything in the directory.
• Closed by default. Password reset and password change are switched off in the internet-facing portal (users and passwords are managed in LLDAP), LLDAP's own password reset is off (no mail server is configured), there is no self-registration, the access policy for anything you have not listed is deny, and failed sign-ins are rate limited (a user is banned for 5 minutes after 4 failures in 2 minutes).
• Fixed host names. Authelia is handed the configured portal name, never the name a client sends; requests for any other host name are dropped, and the client address Authelia records is the real TCP peer, never a forwarded header.
• Locked down serving. TLS 1.2 and 1.3 only; the session-state endpoints of the portal refuse cross-site requests; LLDAP, Authelia, nginx and the first-boot service are blocked from the instance metadata service and the AMI requires IMDSv2.
• Your state on its own disk. The directory, Authelia's encrypted storage (second-factor devices, consent) and the secrets live on a separate 10 GiB EBS volume mounted at /srv/sso.
• The official releases, verified, and fully patched Ubuntu 24.04 LTS at build time, with unattended security upgrades switched on.

What is on the image: Authelia 4.39.28 (the official authelia-v4.39.28-linux-amd64 release binary, sha256 verified, in /usr/local/bin/authelia), LLDAP 0.6.3 (the official amd64-lldap release, sha256 verified, in /opt/lldap), nginx, the OpenLDAP command-line tools (ldapsearch, ldappasswd), Ubuntu 24.04 LTS, cloud-init and the AWS Systems Manager agent.

Default user: ubuntu · Architecture: x86_64 · Recommended instance type: m5.large

Prerequisites

• An AWS account subscribed to the listing, an EC2 key pair and a VPC subnet with a route to the internet (or a private route you use for management).
• A security group that allows TCP 22 (SSH, also used for the LLDAP admin tunnel) from your own networks only, and TCP 443 (the portal and your applications) and TCP 80 (redirects to HTTPS) from the networks your users sign in from. Do not open 3890 or 17170: those services listen on the loopback address only.
• For production, a DNS domain you control (for example example.com), so the portal can be auth.example.com. Authelia's session cookie must belong to a domain: it cannot use an IP address or an EC2 public DNS name (those are public suffixes). Until you set your own, the image uses the demo domain authelia.local.

Step 1: Launch the instance

In the AWS Marketplace listing choose Continue to Subscribe, then Continue to Configuration, pick Authelia with LLDAP 4.39.28 on Ubuntu 24.04 as the software version and your Region, then Launch through EC2. Choose m5.large, your key pair, and a security group as above. The AMI already carries the 10 GiB state volume; you can make it larger on the launch page.

With the AWS CLI (replace the values in angle brackets):

aws ec2 run-instances --image-id <ami-id-from-the-listing> --instance-type m5.large \
  --key-name <your-key-pair> --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=authelia-lldap}]'

First boot takes a few seconds after the instance is running.

Step 2: Connect to your instance

Operating system	SSH user
Ubuntu 24.04	ubuntu

ssh -i <your-key.pem> ubuntu@<public-ip>

Step 3: Check the services

systemctl is-active authelia-lldap-firstboot lldap authelia nginx

active
active
active
active

Only SSH, HTTP and HTTPS are public. Authelia (9091) and LLDAP (LDAP on 3890, the admin UI on 17170) listen on the loopback address:

sudo ss -tln | grep -E ':(22|80|443|9091|3890|17170) '

LISTEN 0      2048       127.0.0.1:3890       0.0.0.0:*
LISTEN 0      511          0.0.0.0:443        0.0.0.0:*
LISTEN 0      2048       127.0.0.1:17170      0.0.0.0:*
LISTEN 0      4096       127.0.0.1:9091       0.0.0.0:*
LISTEN 0      4096         0.0.0.0:22         0.0.0.0:*
LISTEN 0      511          0.0.0.0:80         0.0.0.0:*
LISTEN 0      511             [::]:443           [::]:*
LISTEN 0      4096            [::]:22            [::]:*
LISTEN 0      511             [::]:80            [::]:*

The portal answers its health check through nginx:

curl -sk --resolve auth.authelia.local:443:127.0.0.1 https://auth.authelia.local/api/health; echo

{"status":"OK"}

Step 4: Get your password and the certificate fingerprint

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

The file (root only, mode 0600) gives the portal and demo application addresses, the administrator user admin, its per-instance password (shown here as <redacted>), the directory's base DN and the SHA-256 fingerprint of this instance's certificate:

authelia.portal_URL=https://auth.authelia.local/
authelia.demo_app_URL=https://secure.authelia.local/
admin.user=admin
admin.pass=<redacted>
lldap.base_dn=dc=authelia,dc=local
lldap.admin_dn=uid=admin,ou=people,dc=authelia,dc=local
authelia.tls.sha256_fingerprint=82:9D:47:2A:F0:5F:44:C8:F7:9F:16:20:27:81:34:FB:B5:E7:A9:F8:76:84:C1:E6:1E:FC:9B:84:56:2E:59:86

The same admin account signs in to the Authelia portal and to the LLDAP admin UI. LLDAP stores passwords with the OPAQUE protocol, so the directory never holds the password itself. Every instance gets its own password.

Step 5: Reach the portal from your workstation

Authelia serves two names: the portal auth.<domain> and the demo application secure.<domain>. With the demo domain, tell your workstation where they are by adding one line to its hosts file (/etc/hosts on Linux and macOS, C:\Windows\System32\drivers\etc\hosts on Windows), using your instance's public IP address:

<public-ip>  auth.authelia.local secure.authelia.local

Requests that use any other name, including the bare IP address, are dropped by design. Skip this step once you have set your own domain (Step 10).

The certificate is self-signed and unique to your instance, so your browser warns about it. Open the certificate details in the browser, check that its SHA-256 fingerprint matches authelia.tls.sha256_fingerprint from Step 4, and only then continue. Do not add the certificate to your operating system's trust store; for production, replace it with a certificate from a certificate authority (Step 10).

Step 6: Sign in

Browse to https://secure.authelia.local/. The demo application is protected, so nginx asks Authelia, and Authelia sends you to the portal to sign in. There is no "forgot password" link: password reset is off.

Sign in as admin with the password from Step 4. Authelia checks the password against LLDAP:

Authelia returns you to the page you asked for, now served because the session is authorised:

The same session opens every application you protect under the same domain. Your own settings, including second-factor devices, are at https://auth.authelia.local/settings.

Step 7: Check the sign-in flow from the command line

The image includes a check that runs the whole flow on the instance: the administrator binds to LLDAP over LDAP, a wrong password and an anonymous search are refused, an anonymous web request is sent to the portal, the administrator signs in through nginx, the session opens the demo application, and a wrong password is refused. Passwords are passed to the tools in root-only temporary files, never on a command line:

sudo /usr/local/sbin/authelia-cred-roundtrip.sh

AUTHELIA_ROUNDTRIP_OK ldap-bind=ok ldap-wrong=49 ldap-anon=refused anon=302 admin=200 app=200 wrong=401

An anonymous request to the demo application is redirected to the portal, with the page you wanted as the return address:

curl -sk -o /dev/null -w '%{http_code} %{redirect_url}\n' --resolve secure.authelia.local:443:127.0.0.1 https://secure.authelia.local/

302 https://auth.authelia.local/?rd=https%3A%2F%2Fsecure.authelia.local%2F&rm=GET

Step 8: Manage users and groups in LLDAP

The LLDAP admin UI listens on the instance's loopback address only. Open an SSH tunnel from your workstation (keep it running while you use the UI):

ssh -i <your-key.pem> -N -L 17170:127.0.0.1:17170 ubuntu@<public-ip>

then browse to http://localhost:17170/ on the same workstation and sign in as admin with the password from Step 4:

The Users page lists the directory. A new instance holds two accounts: admin (the administrator, in the lldap_admin group) and authelia, the read-only account Authelia uses to look users up. Do not delete authelia or remove it from lldap_strict_readonly, or nobody can sign in to the portal.

To give someone access, choose Create a user, fill in the user name, e-mail and display name, set a password, and save. They can sign in to the Authelia portal straight away; delete the user in LLDAP and the portal refuses them. The Groups page holds LLDAP's built-in groups and any you create; group names can be used in Authelia's access rules (Step 13):

• lldap_admin: full control of the directory (and of the LLDAP UI).
• lldap_password_manager: can reset the passwords of users who are not administrators. Useful for a help-desk account.
• lldap_strict_readonly: can read the whole directory but change nothing. The authelia account is in this group.

Users who are not administrators can sign in to the LLDAP UI to change their own password, if you give them a way to reach it (the tunnel above). The portal itself never changes passwords.

You can also query the directory from the instance. This lists the users, with the administrator password read from the credentials file through a file descriptor, so it never appears on a command line:

sudo bash -c 'ldapsearch -x -LLL -H ldap://127.0.0.1:3890 -D uid=admin,ou=people,dc=authelia,dc=local -y <(sed -n "s/^admin.pass=//p" /root/authelia-lldap-credentials.txt | tr -d "\n") -b ou=people,dc=authelia,dc=local "(objectClass=person)" uid mail'

dn: uid=admin,ou=people,dc=authelia,dc=local
mail: admin@authelia.local
uid: admin

dn: uid=authelia,ou=people,dc=authelia,dc=local
mail: authelia@authelia.local
uid: authelia

An anonymous search returns nothing: LLDAP only answers bound clients.

n=$(ldapsearch -x -LLL -H ldap://127.0.0.1:3890 -b ou=people,dc=authelia,dc=local '(uid=admin)' uid 2>&1 | grep -c '^uid:' || true); echo "anonymous results: $n"; [ "$n" = 0 ]

anonymous results: 0

Step 9: Check the security posture

The versions, the closed features, the directory connection and the default policy:

authelia --version
/opt/lldap/lldap --version
sudo grep -E 'default_policy|disable:|authelia_url|implementation|user: .uid' /etc/authelia/configuration.yml

authelia version v4.39.28
lldap 0.6.3
    disable: true
    disable: true
    implementation: 'lldap'
    user: 'uid=authelia,ou=people,dc=authelia,dc=local'
  default_policy: 'deny'
      authelia_url: 'https://auth.authelia.local'

The two disable: true lines are authentication_backend.password_reset.disable and authentication_backend.password_change.disable: nobody can reset or change a password from the internet-facing portal; users and passwords are managed in LLDAP (Step 8). The bind password for the authelia account is not in the file: Authelia reads it from /srv/sso/authelia/secrets/ldap-bind.

LLDAP listens on the loopback address only, with its own password reset and LDAPS off:

sudo grep -E '^(ldap_host|ldap_port|http_host|http_port|ldap_base_dn|enable_password_reset|enabled)' /etc/lldap/lldap_config.toml

ldap_host = "127.0.0.1"
ldap_port = 3890
http_host = "127.0.0.1"
http_port = 17170
ldap_base_dn = "dc=authelia,dc=local"
enable_password_reset = false
enabled = false

The certificate is an end-entity certificate for the two names, which cannot sign other certificates:

openssl x509 -in /etc/ssl/authelia/authelia.crt -noout -subject -ext basicConstraints,keyUsage,extendedKeyUsage,subjectAltName

subject=CN = auth.authelia.local, O = cloudimg
X509v3 Subject Alternative Name: 
    DNS:auth.authelia.local, DNS:secure.authelia.local
X509v3 Basic Constraints: critical
    CA:FALSE
X509v3 Key Usage: critical
    Digital Signature, Key Encipherment
X509v3 Extended Key Usage: 
    TLS Web Server Authentication

TLS 1.0 and 1.1 are refused by the server, and a request for a name the instance does not serve gets no answer:

echo | openssl s_client -tls1_1 -cipher 'DEFAULT@SECLEVEL=0' -connect 127.0.0.1:443 -servername auth.authelia.local 2>&1 | grep -o 'alert protocol version' | head -1
code=$(curl -sk -o /dev/null -w '%{http_code}' --resolve evil.example:443:127.0.0.1 https://evil.example/ || true); echo "$code"; [ "$code" = 000 ]

alert protocol version
000

The services are blocked from the instance metadata service. The first command shows the systemd rule on each service; the second makes a metadata request from inside LLDAP's own service, as its user, and gets no connection (000):

systemctl show -p IPAddressDeny lldap authelia nginx authelia-lldap-firstboot
sudo bash -c 'cg=$(systemctl show -p ControlGroup --value lldap.service); echo $$ > /sys/fs/cgroup$cg/cgroup.procs; setpriv --reuid=lldap --regid=lldap --init-groups curl -s -m 5 -o /dev/null -w "imds from lldap: %{http_code}\n" -X PUT -H "X-aws-ec2-metadata-token-ttl-seconds: 60" http://169.254.169.254/latest/api/token; true' | grep -x 'imds from lldap: 000'

IPAddressDeny=168.63.129.16/32 fd00:ec2::254/128 ::ffff:169.254.169.254/128 169.254.169.254/32

IPAddressDeny=168.63.129.16/32 fd00:ec2::254/128 ::ffff:169.254.169.254/128 169.254.169.254/32

IPAddressDeny=168.63.129.16/32 fd00:ec2::254/128 ::ffff:169.254.169.254/128 169.254.169.254/32

IPAddressDeny=168.63.129.16/32 fd00:ec2::254/128 ::ffff:169.254.169.254/128 169.254.169.254/32
imds from lldap: 000

SSH accepts keys only:

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication|x11forwarding|permitemptypasswords) '

permitrootlogin no
passwordauthentication no
kbdinteractiveauthentication no
x11forwarding no
permitemptypasswords no

Step 10: Use your own domain and certificate

Choose a domain you control, for example example.com, and create DNS records for auth.example.com (the portal) and secure.example.com (the demo application) pointing at the instance's public IP (or an Elastic IP). Then run:

sudo authelia-set-domain example.com

The helper sets the session cookie domain to example.com, the portal to https://auth.example.com/ and the demo application to https://secure.example.com/. It re-renders /etc/authelia/configuration.yml from the cloudimg template (your previous file is kept as configuration.yml.prev, so run it before you customise the configuration, or copy your changes back afterwards), updates the nginx site and the cross-site guard, issues a new self-signed certificate for the new names, and restarts Authelia. The directory is not affected: its base DN stays dc=authelia,dc=local. Check the result with:

authelia-set-domain --show

domain:  authelia.local
portal:  https://auth.authelia.local/
demo app: https://secure.authelia.local/

(Shown for the demo domain; after the change it names yours.)

To use a certificate from a certificate authority, for example from AWS Certificate Manager on a load balancer in front of the instance, or Let's Encrypt with certbot on the instance, put the full chain and key at /etc/ssl/authelia/authelia.crt and /etc/ssl/authelia/authelia.key (key mode 0600, owner root) and reload nginx with sudo systemctl reload nginx. authelia-set-domain never replaces a certificate that is not cloudimg's own.

Step 11: Turn on two-factor authentication

The demo rule asks for one factor so you can try the flow straight away. To require two factors, change the rule in /etc/authelia/configuration.yml:

access_control:
  default_policy: 'deny'
  rules:
    - domain: 'secure.authelia.local'
      policy: 'two_factor'

then restart Authelia with sudo systemctl restart authelia. At the next sign-in Authelia offers to register a second factor (a one-time password app such as Google Authenticator or Microsoft Authenticator, a security key or a passkey). Registering a device is confirmed with a one-time code that Authelia "sends" through its notifier. The image uses the filesystem notifier (there is no mail server until you configure one), so read the code on the instance:

sudo cat /srv/sso/authelia/notification.txt 2>/dev/null || echo 'no notification has been sent yet'

To send these messages by e-mail instead, replace the notifier: section with an smtp: block for your mail service (Amazon SES works well) as described in the Authelia notifier documentation, and restart Authelia. Authelia sends each message to the e-mail address of the user in LLDAP.

Step 12: Connect other services to the directory

LLDAP speaks standard LDAP on ldap://127.0.0.1:3890, so other software on the same instance (or in containers on it) can use the directory: bind as a dedicated read-only account rather than admin. Create the account in the LLDAP UI, add it to lldap_strict_readonly, and use these settings:

Setting	Value
Server	ldap://127.0.0.1:3890
Base DN	dc=authelia,dc=local
Users	ou=people,dc=authelia,dc=local, attribute uid, object class person
Groups	ou=groups,dc=authelia,dc=local, object class groupOfUniqueNames, attribute member
Bind DN	uid=<account>,ou=people,dc=authelia,dc=local

The image does not expose LDAP to the network. If other servers in your VPC must use it, enable LDAPS in /etc/lldap/lldap_config.toml ([ldaps_options], with a certificate for the instance's name), set ldap_host accordingly, open the LDAPS port in the security group to those servers only, and restart LLDAP. Keep plain LDAP on the loopback address.

Step 13: Protect your own application

Put the application behind nginx on this instance (or on another server that uses this Authelia as its forward-auth endpoint) and add an access_control rule for its name. On this instance, copy the demo server block in /etc/nginx/sites-available/authelia for the new name (for example grafana.example.com), keep the location = /internal/authelia/authz block and the auth_request lines, and replace the root/try_files lines with a proxy_pass to your application. Then add a rule that uses an LLDAP group, such as:

    - domain: 'grafana.example.com'
      policy: 'two_factor'
      subject: 'group:grafana-users'

create the grafana-users group in LLDAP and add the people who need access, restart Authelia and reload nginx. Remember that authelia-set-domain re-renders the nginx site from its template, so keep your own server blocks in a separate file under /etc/nginx/sites-enabled/. The certificate must cover the new name too.

Step 14: Your state and backups

Everything Authelia and LLDAP keep is on the state volume at /srv/sso:

sudo ls -l /srv/sso /srv/sso/authelia /srv/sso/authelia/secrets /srv/sso/lldap /srv/sso/lldap/secrets
df -h /srv/sso | tail -1

/srv/sso:
total 24
drwx------ 3 authelia authelia  4096 Oct 28 21:31 authelia
drwx------ 3 lldap    lldap     4096 Oct 28 21:30 lldap
drwx------ 2 root     root     16384 Oct 28 21:00 lost+found

/srv/sso/authelia:
total 308
-rw------- 1 authelia authelia 311296 Oct 28 21:31 db.sqlite3
drwx------ 2 authelia authelia   4096 Oct 28 21:28 secrets

/srv/sso/authelia/secrets:
total 12
-rw------- 1 authelia authelia 48 Oct 28 21:28 ldap-bind
-rw------- 1 authelia authelia 64 Oct 28 21:28 session
-rw------- 1 authelia authelia 64 Oct 28 21:28 storage-encryption

/srv/sso/lldap:
total 144
drwx------ 2 lldap lldap   4096 Oct 28 21:28 secrets
-rw-r--r-- 1 lldap lldap 139264 Oct 28 21:30 users.db

/srv/sso/lldap/secrets:
total 8
-rw------- 1 lldap lldap 64 Oct 28 21:28 jwt-secret
-rw------- 1 lldap lldap 64 Oct 28 21:28 key-seed
/dev/nvme1n1    9.8G  504K  9.3G   1% /srv/sso

• lldap/users.db: the directory (users, groups, attributes and OPAQUE password files). Only the lldap user can enter its folder.
• lldap/secrets/key-seed: derives the key that protects the stored passwords. Keep it with users.db: without it no password in a restored directory works.
• lldap/secrets/jwt-secret: signs LLDAP's admin UI sessions.
• authelia/db.sqlite3: Authelia's storage (second-factor devices, preferences, consent), encrypted with the key in authelia/secrets/storage-encryption. Keep the key with the database.
• authelia/secrets/session: signs portal session cookies. Changing it signs everyone out. authelia/secrets/ldap-bind is the password of the authelia directory account.

Back the volume up with EBS snapshots (AWS Backup or Data Lifecycle Manager), or copy the folder while LLDAP and Authelia are stopped (sudo systemctl stop authelia lldap). Treat backups as secrets.

Step 15: Server components

Component	Where
Authelia 4.39.28	/usr/local/bin/authelia, unit authelia.service, user authelia, 127.0.0.1:9091
Authelia configuration	/etc/authelia/configuration.yml (no secrets), /etc/authelia/authelia.env (0600, file paths of the secrets)
LLDAP 0.6.3	/opt/lldap/lldap and /opt/lldap/app, unit lldap.service, user lldap, LDAP 127.0.0.1:3890, UI 127.0.0.1:17170
LLDAP configuration	/etc/lldap/lldap_config.toml (no secrets), /etc/lldap/lldap.env (0600, file paths of the secrets)
State	/srv/sso (own EBS volume)
nginx site	/etc/nginx/sites-available/authelia, certificate /etc/ssl/authelia/
Domain helper	/usr/local/sbin/authelia-set-domain
First boot	authelia-lldap-firstboot.service, /usr/local/sbin/authelia-lldap-firstboot.sh
Logs	journalctl -u authelia, journalctl -u lldap, /var/log/nginx/

Step 16: Updating Authelia and LLDAP

Ubuntu packages update automatically through unattended upgrades. Authelia and LLDAP are single binaries:

• Authelia: download the new authelia-v<version>-linux-amd64.tar.gz from the Authelia releases page, verify its checksum, read the release notes for configuration changes, stop Authelia, back up /srv/sso, replace /usr/local/bin/authelia (owner root, mode 0755) and start Authelia again. Authelia migrates its storage on start.
• LLDAP: download the new amd64-lldap.tar.gz from the LLDAP releases page, verify it, read the release notes, stop Authelia and LLDAP, back up /srv/sso, replace /opt/lldap/lldap and the /opt/lldap/app folder (owner root), and start LLDAP, then Authelia. LLDAP migrates its database on start.

Step 17: Security notes

• Keep port 22 open to your own networks only. Never open 3890 or 17170 in the security group.
• Set your own domain and a CA-issued certificate before real users sign in, and switch the rules you rely on to two_factor.
• Keep default_policy: 'deny' and list each application explicitly.
• Give people their own LLDAP accounts; keep admin for administration.
• Authelia logs every sign-in attempt with the client address; failed attempts trigger the ban in regulation.

Known advisories in the shipped releases.

• Authelia 4.39.28 (the newest release) is built with Go 1.27.1. Go fixed these standard-library advisories in Go 1.27.2 and 1.27.3, after that release: GO-2026-6599, GO-2026-6600 (html/template), GO-2026-6603, GO-2026-6605, GO-2026-6609, GO-2026-6610, GO-2026-6611, GO-2026-6613 (net/http), GO-2026-6607 (crypto/tls), GO-2026-6608 (net/textproto) and GO-2026-6809 (crypto/x509). Authelia serves HTTP through fasthttp, not Go's net/http server, so the server-side items do not apply. The rest are only reachable through outbound connections Authelia makes: e-mail templates sent through an SMTP notifier, TLS connections to SMTP or LDAP servers, OpenID Connect sector-identifier, WebAuthn metadata and OCSP fetches, and the authelia debug commands. In the image Authelia's only outbound connection is plain LDAP to LLDAP on the loopback address; none of the others is configured.
• LLDAP 0.6.3 (the newest release, April 2026). The RustSec advisory database lists advisories against libraries LLDAP 0.6.3 is built with. Those in TLS, e-mail and HTTP-client code (rustls, rustls-webpki, webpki-roots, lettre, h2 as a client) apply only to LDAPS, mail and outbound connections, none of which is enabled; rsa is used only by the MySQL driver (the image uses SQLite); the h2 and zstd items concern the HTTP server and its compression, which listen on the loopback address only; RUSTSEC-2024-0344 (a timing variation in curve25519-dalek, used by the OPAQUE password protocol) has no practical remote exploit. Three fixes are on LLDAP's main branch but not yet in a release: refresh and password-reset tokens drawn from the operating system's random generator (the image has password reset off; tokens come from a freshly seeded generator), and two LDAP request handlers that could fail on unusual requests from a signed-in LDAP user (a Password Modify request for another user drops that one connection; LLDAP keeps serving). LDAP is reachable only from the instance itself. cloudimg tracks both projects and will publish an updated version.

Support and licensing

Authelia is licensed under the Apache License 2.0. LLDAP is licensed under the GNU General Public License version 3; its complete source code for the shipped release is at github.com/lldap/lldap, tag v0.6.3. cloudimg is not affiliated with or endorsed by the Authelia or LLDAP projects. The image is built and supported by cloudimg: contact support@cloudimg.co.uk for help with deployment, access rules, two-factor enrolment, the directory, mail and certificates.

See the identity, secrets and PKI listing guide for the other versions in this listing.