Authelia with LLDAP 4.39.28

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, select your Region, and choose Launch through EC2.

Choose m5.large, your key pair and the security group from the prerequisites. The AMI already carries the 10 GiB state volume, and you can make it larger on the launch page.

To launch with the AWS CLI instead, 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.

Connect over SSH as the ubuntu user, which is the default user on Ubuntu 24.04:

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

Confirm that the services are running:

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 only:

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"}

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

The credentials file is readable by root only (mode 0600). It lists the portal and demo application addresses, the admin administrator user, 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. Every instance gets its own password. LLDAP stores passwords with the OPAQUE protocol, so the directory never holds the password itself.

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

<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 and check that its SHA-256 fingerprint matches authelia.tls.sha256_fingerprint from Step 4. Continue only if it matches.

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).

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, because password reset is off.

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

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

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.

The image includes a check that runs the whole flow on the instance. It confirms that:

• The administrator binds to LLDAP over LDAP, while a wrong password and an anonymous search are refused.
• An anonymous web request is sent to the portal.
• The administrator signs in through nginx, and the session opens the demo application.
• A wrong password is refused.

Passwords are passed to the tools in root-only temporary files, never on a command line. Run the check:

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

The LLDAP admin UI listens on the instance's loopback address only. Open an SSH tunnel from your workstation, and 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. The new user can sign in to the Authelia portal straight away. If you delete the user in LLDAP, 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 command lists the users. It reads the administrator password from the credentials file through a file descriptor, so the password 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

Check 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, because 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. It 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 = sac 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

The server refuses TLS 1.0 and 1.1, 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 command 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

Choose a domain you control, for example example.com. Create DNS records for auth.example.com (the portal) and secure.example.com (the demo application) that point at the instance's public IP, or at 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 then:

• Re-renders /etc/authelia/configuration.yml from the SecureAnyCloud template. Your previous file is kept as configuration.yml.prev, so run the helper before you customize 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.
• 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/

The output above is shown for the demo domain. After the change, it names your domain.

To use a certificate from a certificate authority, put the full chain and key at /etc/ssl/authelia/authelia.crt and /etc/ssl/authelia/authelia.key (key mode 0600, owner root). Then reload nginx with sudo systemctl reload nginx. You can get the certificate from AWS Certificate Manager on a load balancer in front of the instance, or from Let's Encrypt with certbot on the instance.

authelia-set-domain never replaces a certificate that is not SecureAnyCloud's own.

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. A one-time code that Authelia "sends" through its notifier confirms the registration.

The image uses the filesystem notifier, because there is no mail server until you configure one. 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, as described in the Authelia notifier documentation. Amazon SES works well. Then restart Authelia. Authelia sends each message to the e-mail address of the user in LLDAP.

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, take these steps:

• 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.
• Restart LLDAP.

Keep plain LDAP on the loopback address.

Put the application behind nginx on this instance, or on another server that uses this Authelia as its forward-auth endpoint. Then 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. 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. Then restart Authelia and reload nginx.

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.

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 up the volume with EBS snapshots (AWS Backup or Data Lifecycle Manager). Alternatively, copy the folder while LLDAP and Authelia are stopped (sudo systemctl stop authelia lldap). Treat backups as secrets.

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/

Ubuntu packages update automatically through unattended upgrades. Authelia and LLDAP are single binaries, which you update by hand:

• 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.

• Restrict the network. Keep port 22 open to your own networks only. Never open 3890 or 17170 in the security group.
• Set your domain and certificate. Use your own domain and a CA-issued certificate before real users sign in, and switch the rules you rely on to two_factor.
• Keep the default policy closed. Keep default_policy: 'deny' and list each application explicitly.
• Use individual accounts. Give people their own LLDAP accounts, and keep admin for administration.
• Review sign-in logs. 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. SecureAnyCloud tracks both projects and will publish an updated version.