Security AWS

Apache Directory Server 2.0.0.AM27 on AWS User Guide

Last updated: 2026-10-28 | Product: Apache Directory Server 2.0.0.AM27 on Ubuntu 24.04 on AWS

Overview

This guide covers launching and using the Apache Directory Server 2.0.0.AM27 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.

Apache Directory Server (ApacheDS) is the Apache Software Foundation's LDAP v3 directory server, written in Java. Applications use it to look up users and groups, check passwords with an LDAP bind, and store directory data such as organisational units, group memberships and contact attributes.

Upstream ApacheDS starts with a well known administrator password (secret), answers anonymous binds and searches, and serves plain LDAP on every interface. The cloudimg image changes that:

No directory ships in the image. The directory instance (configuration, system and data partitions) is created on your instance's first boot, so no two customers share a database, a password hash or a key.
A per instance administrator password, never the default. First boot replaces secret for uid=admin,ou=system with a random 32 character password while the server runs inside a private network namespace that nothing else can reach, proves secret is refused, and only then starts the real listeners. The password is written to /root/apacheds-credentials.txt (root only); the server stores only a salted SHA-512 hash.
LDAPS from the first boot, through a dedicated TLS front. Port 10636 is served by stunnel, which terminates TLS 1.2/1.3 with a certificate generated on your instance and forwards to the directory on plain LDAP 127.0.0.1:10389. The certificate is an end entity certificate (CA:FALSE): you pin it in your clients after comparing its fingerprint, and it can never sign a certificate for anything else. Plain LDAP (10389) listens on 127.0.0.1 only, and the directory's own LDAPS and StartTLS are switched off, so a refused or malformed TLS handshake only ever reaches the hardened front, never the directory engine.
Anonymous access off, access control on. Anonymous binds, searches and even the root DSE are refused; a user who binds sees nothing until you grant access; userPassword is never returned by a search; failed binds lock a user out for 15 minutes (the administrator is exempt, so nobody can lock you out over the network).
Only the directory. Replication is off, the Kerberos KDC is not configured, and the change password and HTTP servers are disabled; SASL is limited to simple binds.
Fail closed and locked down. The directory will not start until first boot has created the hardened instance, and the TLS front will not start until the per-instance certificate exists. Both run as unprivileged users (apacheds and ldaptls) under systemd sandboxing with no capabilities, Java deserialization filtered, and no access to the instance metadata service; the AMI requires IMDSv2.
Your directory on its own disk. The instance lives on a separate 10 GiB EBS volume mounted at /var/lib/apacheds that you can grow, snapshot and back up on its own.
The official release, verified, and fully patched Ubuntu 24.04 LTS at build time, with unattended security upgrades switched on.

What is on the image: Apache Directory Server 2.0.0.AM27 (the official binary release, signature checked, in /opt/apacheds-2.0.0.AM27), OpenJDK 17 headless runtime, the OpenLDAP client tools (ldapsearch, ldapmodify, ldapwhoami), stunnel (the LDAPS TLS front), 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) from your own networks only, and TCP 10636 (LDAPS) only from the networks your applications and administrators connect from. Plain LDAP (10389) never needs a rule: it only listens on the instance itself.

Step 1: Launch the instance

In the AWS Marketplace listing choose Continue to Subscribe, then Continue to Configuration, pick Apache Directory Server 2.0.0.AM27 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 directory volume; you can make it larger on the launch page.

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

aws ec2 run-instances --region <region> --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=apacheds}]'

Step 2: Connect to your instance

Version	SSH user
Apache Directory Server 2.0.0.AM27 on Ubuntu 24.04	`ubuntu`

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

Step 3: Check the service

First boot creates the directory instance (about 20 seconds); then the directory (apacheds.service) and the LDAPS TLS front (apacheds-ldaps.service, stunnel) start:

systemctl is-active apacheds apacheds-ldaps apacheds-firstboot
sudo test -f /var/lib/cloudimg/apacheds-firstboot.done && echo FIRSTBOOT_DONE

active
active
active
FIRSTBOOT_DONE

Only SSH and LDAPS (10636, the stunnel front) listen on the network. Plain LDAP (10389) and the directory's shutdown port are bound to 127.0.0.1:

sudo ss -lntp | awk 'NR>1 {print $4, $6}' | sed -E 's/pid=[0-9]+,fd=[0-9]+/.../g' | sort

0.0.0.0:10636 users:(("stunnel",...))
0.0.0.0:22 users:(("sshd",...),("systemd",...))
127.0.0.53%lo:53 users:(("systemd-resolve",...))
127.0.0.54:53 users:(("systemd-resolve",...))
[::]:22 users:(("sshd",...),("systemd",...))
[::ffff:127.0.0.1]:10389 users:(("java",...))
[::ffff:127.0.0.1]:<shutdown-port> users:(("java",...))

The public 10636 socket belongs to the stunnel front; the Java directory process listens only on loopback (10389 and its shutdown port).

Step 4: Your connection details and administrator password

The credentials file is readable by root only. These are the connection details in it:

sudo grep -E '^APACHEDS_(ADMIN_DN|LDAPS_URL|LDAP_URL|BASE_DN|TLS_CERT)=' /root/apacheds-credentials.txt

APACHEDS_ADMIN_DN=uid=admin,ou=system
APACHEDS_LDAPS_URL=ldaps://ec2-<public-ip-dashed>.<region>.compute.amazonaws.com:10636
APACHEDS_LDAP_URL=ldap://127.0.0.1:10389
APACHEDS_BASE_DN=dc=cloudimg,dc=local
APACHEDS_TLS_CERT=/etc/apacheds/tls/apacheds.crt

The file also holds APACHEDS_ADMIN_PASSWORD (the directory administrator's password). When you need the administrator password itself (for example to type it into an LDAP browser), read it with sudo grep '^APACHEDS_ADMIN_PASSWORD=' /root/apacheds-credentials.txt | cut -d= -f2-. The command line tools in this guide never print it: they read it from a private file.

The LDAPS URL uses the instance's public DNS name from EC2 instance metadata. To serve the directory under your own DNS name, see Step 9.

Step 5: The certificate and its fingerprint

The certificate was generated on your instance's first boot. It names the instance's DNS name and addresses and is an end entity certificate: CA:FALSE, usable for a TLS server only, so trusting it can never let anyone sign a certificate for another site:

sudo openssl x509 -in /etc/apacheds/tls/apacheds.crt -noout -subject -fingerprint -sha256 \
  -ext subjectAltName,basicConstraints,keyUsage,extendedKeyUsage

subject=CN = ec2-<public-ip-dashed>.<region>.compute.amazonaws.com, O = cloudimg
sha256 Fingerprint=<fingerprint>
X509v3 Subject Alternative Name:
    DNS:ec2-<public-ip-dashed>.<region>.compute.amazonaws.com, IP Address:<public-ip>, IP Address:<private-ip>, DNS:localhost, IP Address:127.0.0.1
X509v3 Basic Constraints: critical
    CA:FALSE
X509v3 Key Usage: critical
    Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
    TLS Web Server Authentication

Note the sha256 Fingerprint. Before a client relies on the certificate, check that the server it reaches presents the same one (Step 8). Do not add this certificate to an operating system or browser trust store; pin it in the LDAP clients that connect to this directory, or replace it with a certificate from your own certificate authority (Step 9).

The server speaks TLS 1.2 and 1.3 only:

echo | openssl s_client -connect 127.0.0.1:10636 2>/dev/null | grep -E '^New, '
for v in tls1_1 tls1_2 tls1_3; do
  if echo | openssl s_client -connect 127.0.0.1:10636 -$v -cipher 'DEFAULT@SECLEVEL=0' >/dev/null 2>&1; then echo "$v accepted"; else echo "$v refused"; fi
done

New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
tls1_1 refused
tls1_2 accepted
tls1_3 accepted

Step 6: Bind and search over LDAPS

The OpenLDAP tools read the password from a file with -y, so it never appears in the process list or your shell history. This block pins the instance's certificate for the tools (LDAPTLS_CACERT), puts the password in a private temporary file, binds as the administrator and searches the demo entries:

set -e
sudo cat /etc/apacheds/tls/apacheds.crt > /tmp/apacheds.crt
export LDAPTLS_CACERT=/tmp/apacheds.crt
URL=$(sudo grep '^APACHEDS_LDAPS_URL=' /root/apacheds-credentials.txt | cut -d= -f2-)
PWF=$(mktemp); sudo grep '^APACHEDS_ADMIN_PASSWORD=' /root/apacheds-credentials.txt | cut -d= -f2- | tr -d '\n' > "$PWF"
# the TLS front may take a few seconds to accept connections just after boot
for i in $(seq 1 15); do ldapwhoami -x -H "$URL" -D uid=admin,ou=system -y "$PWF" >/dev/null 2>&1 && break; sleep 2; done
ldapwhoami -x -H "$URL" -D uid=admin,ou=system -y "$PWF"
ldapsearch -x -LLL -H "$URL" -D uid=admin,ou=system -y "$PWF" -b dc=cloudimg,dc=local '(objectClass=inetOrgPerson)' uid cn mail
rm -f "$PWF"

dn:uid=admin,ou=system
dn: uid=bob,ou=people,dc=cloudimg,dc=local
mail: bob@cloudimg.local
cn: Bob Brown
uid: bob

dn: uid=alice,ou=people,dc=cloudimg,dc=local
mail: alice@cloudimg.local
cn: Alice Anderson
uid: alice

The image ships a small demo tree under dc=cloudimg,dc=local: ou=people with alice and bob, and ou=groups with the group engineers. The demo users have no password, so nobody can bind as them. Delete them, or the whole tree, once you have loaded your own data.

Step 7: Check the security posture

Anonymous access is refused, the root DSE included, and so is the upstream default password:

export LDAPTLS_CACERT=/tmp/apacheds.crt
URL=$(sudo grep '^APACHEDS_LDAPS_URL=' /root/apacheds-credentials.txt | cut -d= -f2-)
ldapsearch -x -LLL -H "$URL" -b dc=cloudimg,dc=local '(uid=alice)' 2>&1 | head -1
ldapsearch -x -LLL -H "$URL" -s base -b '' namingContexts 2>&1 | head -1
S=$(mktemp); printf secret > "$S"; ldapwhoami -x -H "$URL" -D uid=admin,ou=system -y "$S" 2>&1 | head -1; rm -f "$S"

ldap_bind: Invalid credentials (49)
ldap_bind: Invalid credentials (49)
ldap_bind: Invalid credentials (49)

Plain LDAP is not reachable on the instance's own network address:

timeout 3 bash -c "exec 3<>/dev/tcp/$(hostname -I | awk '{print $1}')/10389" 2>/dev/null && echo OPEN || echo "10389 closed on the private address"

10389 closed on the private address

StartTLS is switched off on the plain channel, so it cannot reach the directory's TLS code either:

if ldapsearch -x -H ldap://127.0.0.1:10389 -ZZ -b '' -s base >/dev/null 2>&1; then
  echo "UNEXPECTED: StartTLS was accepted"; false
else
  ldapsearch -x -H ldap://127.0.0.1:10389 -ZZ -b '' -s base 2>&1 | head -2 || true
fi

ldap_start_tls: Protocol error (2)
    additional info: Unrecognized extended operation EXTENSION_OID: 1.3.6.1.4.1.1466.20037

The directory runs as apacheds and the TLS front as ldaptls, both with no capabilities and no access to the instance metadata service; the directory will not start until first boot has finished:

systemctl show apacheds -p User -p NoNewPrivileges -p ProtectSystem -p CapabilityBoundingSet -p IPAddressDeny
systemctl show apacheds-ldaps -p User -p IPAddressDeny
sudo stat -c '%a %U:%G %n' /root/apacheds-credentials.txt /etc/apacheds/tls/apacheds.crt /etc/apacheds/tls/apacheds.key /var/lib/apacheds/default

IPAddressDeny=169.254.169.254/32 fd00:ec2::254/128 ::ffff:169.254.169.254/128 168.63.129.16/32
CapabilityBoundingSet=
User=apacheds
ProtectSystem=strict
NoNewPrivileges=yes
User=ldaptls
IPAddressDeny=169.254.169.254/32 fd00:ec2::254/128 ::ffff:169.254.169.254/128 168.63.129.16/32
600 root:root /root/apacheds-credentials.txt
644 root:root /etc/apacheds/tls/apacheds.crt
640 root:ldaptls /etc/apacheds/tls/apacheds.key
750 apacheds:apacheds /var/lib/apacheds/default

SSH accepts keys only, with no root login:

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

permitrootlogin no
passwordauthentication no
x11forwarding no

Step 8: Connect from your workstation or application

Allow TCP 10636 from your network in the security group. Then, on your workstation, check that the server presents the certificate whose fingerprint you noted in Step 5:

echo | openssl s_client -connect <public-ip>:10636 2>/dev/null | openssl x509 -noout -fingerprint -sha256

If the fingerprint matches, save that certificate and pin it for your LDAP client. With the OpenLDAP tools:

echo | openssl s_client -connect <public-ip>:10636 2>/dev/null | openssl x509 > apacheds.crt
LDAPTLS_CACERT=$PWD/apacheds.crt ldapwhoami -x -H ldaps://<public-ip>:10636 -D uid=admin,ou=system -W

Applications connect the same way: LDAPS URL ldaps://<your-host>:10636, bind DN and password of an account you create for them (Step 10), base DN dc=cloudimg,dc=local or your own suffix, and the pinned certificate (for Java clients, a truststore that holds only this certificate). Use the host name the certificate names (the EC2 public DNS name, its IP addresses, or the name you set in Step 9).

Step 9: Your own DNS name and certificate

Point a DNS record at the instance, then set the name LDAPS is served as. This mints a new certificate and key for the name (the instance's addresses are added to it), installs them where the stunnel front reads them, restarts the front, updates the URL in the credentials file and keeps the name across reboots. Clients that pinned the old certificate need the new one:

sudo apacheds-set-hostname <your-domain>

To use a certificate from your own certificate authority instead, install your PEM certificate (with the chain) and key where the stunnel front reads them and restart the front. Running apacheds-set-hostname again replaces them with a generated certificate:

sudo install -o root -g root   -m 0644 <your-domain>.crt /etc/apacheds/tls/apacheds.crt
sudo install -o root -g ldaptls -m 0640 <your-domain>.key /etc/apacheds/tls/apacheds.key
sudo systemctl restart apacheds-ldaps

Step 10: Add users and grant access

Create entries with ldapadd, and give a user a password by replacing userPassword from a private file (the server hashes it with salted SHA-512; ApacheDS's password modify operation only changes an existing password). This adds carol, sets her a random password and binds as her:

set -e
export LDAPTLS_CACERT=/tmp/apacheds.crt
URL=$(sudo grep '^APACHEDS_LDAPS_URL=' /root/apacheds-credentials.txt | cut -d= -f2-)
PWF=$(mktemp); sudo grep '^APACHEDS_ADMIN_PASSWORD=' /root/apacheds-credentials.txt | cut -d= -f2- | tr -d '\n' > "$PWF"
cat > /tmp/carol.ldif <<'EOF'
dn: uid=carol,ou=people,dc=cloudimg,dc=local
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
cn: Carol Clark
sn: Clark
uid: carol
mail: carol@cloudimg.local
EOF
ldapdelete -x -H "$URL" -D uid=admin,ou=system -y "$PWF" uid=carol,ou=people,dc=cloudimg,dc=local 2>/dev/null || true
ldapadd -x -H "$URL" -D uid=admin,ou=system -y "$PWF" -f /tmp/carol.ldif
CPW=$(mktemp); MOD=$(mktemp); V=$(openssl rand -base64 30 | tr -dc 'A-Za-z0-9' | head -c 24)
printf '%s' "$V" > "$CPW"
printf 'dn: uid=carol,ou=people,dc=cloudimg,dc=local\nchangetype: modify\nreplace: userPassword\nuserPassword: %s\n' "$V" > "$MOD"; unset V
ldapmodify -x -H "$URL" -D uid=admin,ou=system -y "$PWF" -f "$MOD"
ldapwhoami -x -H "$URL" -D uid=carol,ou=people,dc=cloudimg,dc=local -y "$CPW"
ldapsearch -x -LLL -H "$URL" -D uid=carol,ou=people,dc=cloudimg,dc=local -y "$CPW" -b dc=cloudimg,dc=local '(uid=alice)' dn
echo "entries carol can read: $(ldapsearch -x -LLL -H "$URL" -D uid=carol,ou=people,dc=cloudimg,dc=local -y "$CPW" -b dc=cloudimg,dc=local '(objectClass=*)' dn | grep -c '^dn:')"
shred -u "$CPW" "$MOD"; rm -f "$PWF" /tmp/carol.ldif

adding new entry "uid=carol,ou=people,dc=cloudimg,dc=local"

modifying entry "uid=carol,ou=people,dc=cloudimg,dc=local"

dn:uid=carol,ou=people,dc=cloudimg,dc=local
entries carol can read: 0

Carol can bind (so applications can check her password), but she reads nothing, because access control is on and no access control item grants her anything. Grant read access with ApacheDS access control items (ACIs), for example an accessControlSubentry under your suffix that lets authenticated users read and search the ou=people entries except userPassword. See the ApacheDS Access Control documentation. Give each application its own service account with read access to the part of the tree it needs, rather than the administrator password.

The password policy requires at least 12 characters and locks a user for 15 minutes after 5 failed binds; the administrator account is exempt so it cannot be locked out from the network.

Step 11: Change the administrator password

apacheds-set-admin-password generates a new random 32 character password, changes it in the directory and records it in /root/apacheds-credentials.txt:

sudo apacheds-set-admin-password

To choose the password yourself, hand it over on standard input (12 to 128 characters from A-Z a-z 0-9 . _ ~ @ % + = , -; printf is a shell builtin, so the password never appears in the process list; start the line with a space so most shells keep it out of your history):

 printf '%s\n' '<new-password>' | sudo apacheds-set-admin-password --stdin

Step 12: The directory volume and backups

The instance (configuration, partitions and the server log) lives on its own EBS volume, mounted without device files, set-uid programs or execution:

findmnt -no SOURCE,FSTYPE,OPTIONS /var/lib/apacheds
df -h --output=size,used,avail,target /var/lib/apacheds
sudo ls /var/lib/apacheds/default

/dev/nvme1n1 ext4   rw,nosuid,nodev,noexec,relatime
 Size  Used Avail Mounted on
 9.8G  6.3M  9.3G /var/lib/apacheds
cache
conf
log
partitions
run
tmp

The complete backup is an EBS snapshot of this volume, taken from the EC2 console or with aws ec2 create-snapshot; stop the server first (sudo systemctl stop apacheds) for a consistent copy, then start it again. It keeps everything, password hashes and the server configuration included, so protect the snapshot like the directory itself.

For a portable copy of your entries, export them as LDIF. Passwords are hidden from searches, so the export carries no userPassword values: users need a new password after a restore from LDIF:

set -e
export LDAPTLS_CACERT=/tmp/apacheds.crt
URL=$(sudo grep '^APACHEDS_LDAPS_URL=' /root/apacheds-credentials.txt | cut -d= -f2-)
PWF=$(mktemp); sudo grep '^APACHEDS_ADMIN_PASSWORD=' /root/apacheds-credentials.txt | cut -d= -f2- | tr -d '\n' > "$PWF"
ldapsearch -x -LLL -H "$URL" -D uid=admin,ou=system -y "$PWF" -b dc=cloudimg,dc=local '(objectClass=*)' '*' > /tmp/directory-export.ldif
rm -f "$PWF"
echo "entries exported: $(grep -c '^dn:' /tmp/directory-export.ldif), userPassword lines: $(grep -ci '^userPassword' /tmp/directory-export.ldif)"

entries exported: 7, userPassword lines: 0

To grow the volume, modify its size in the EC2 console, then run sudo resize2fs on its device (shown by findmnt above).

Step 13: Server components

Component	Path
ApacheDS release (read only, owned by root)	`/opt/apacheds-2.0.0.AM27` (`/opt/apacheds`)
Directory instance (EBS volume)	`/var/lib/apacheds/default`
Hardened configuration template	`/etc/apacheds/config.ldif.cloudimg`
TLS front certificate and key	`/etc/apacheds/tls/apacheds.crt` + `apacheds.key`
LDAPS TLS front (stunnel)	`/etc/apacheds/stunnel/ldaps.conf`, `apacheds-ldaps.service`
JVM options	`/etc/default/apacheds`
Server log	`/var/lib/apacheds/default/log/apacheds.log`
Licence, notice and build notes	`/usr/share/doc/apacheds/`
First boot script	`/usr/local/sbin/apacheds-firstboot.sh`
Password and host name helpers	`/usr/local/sbin/apacheds-set-admin-password`, `/usr/local/sbin/apacheds-set-hostname`
Credentials	`/root/apacheds-credentials.txt` (mode 0600)

readlink -f /opt/apacheds
sha256sum /opt/apacheds/lib/*.jar | awk '{print $1}'
java -version 2>&1 | head -1

/opt/apacheds-2.0.0.AM27
b57e249325284ef8533d3d7522a980151c5baf778051c9f644f6918297021d43
openjdk version "17.0.20.1" 2026-08-18

The release archive labels its build tree 2.0.0.AM28-SNAPSHOT (an upstream packaging quirk); it is the signed 2.0.0.AM27 release, and /usr/share/doc/apacheds/README.cloudimg.txt records its SHA-512, the release manager's signing key and the bundled library versions.

Bundled libraries with published advisories. The ApacheDS release bundles libraries in its single service JAR, and some of them have published advisories that the image cannot fix without modifying the release. None is reachable in this image, and we checked each one:

Apache MINA 2.2.3 (CVE-2024-52046 and its follow ups CVE-2026-41409, CVE-2026-41635, CVE-2026-42778, CVE-2026-42779, CVE-2026-47065): the flaws are in MINA's Java object serialization decoder. ApacheDS uses MINA only for LDAP networking with its own LDAP codec and never calls the object serialization decoder (checked in the bytecode at build time); the JVM also runs with a deserialization filter.
Eclipse Jetty 9.4.52: ApacheDS's embedded HTTP server is disabled, so Jetty never starts and nothing listens on 8080 or 8443.
Apache MINA TLS: the directory's own LDAPS transport and its StartTLS extended operation are switched off, and TLS is terminated instead by a dedicated front (stunnel), so MINA's TLS code never handles a network handshake. The front (stunnel from the Ubuntu universe repository) carries no security fix pending only in Ubuntu Pro ESM; it is checked at build time.
Bouncy Castle 1.70 (moderate advisories): ApacheDS serves no TLS of its own (the stunnel front does), so the affected Bouncy Castle TLS, PEM and LDAP store code is never used.
Apache Commons Lang 3.13.0 (CVE-2025-48924, moderate): no ApacheDS code calls the affected ClassUtils.getClass.

We re-check these at every ApacheDS release and move to it once it is available.

Step 14: Updating

Ubuntu security updates install automatically (unattended upgrades are on), and sudo apt-get update && sudo apt-get upgrade applies everything else, the Java runtime included. ApacheDS itself is the release in /opt/apacheds-2.0.0.AM27; when Apache publishes a newer release, cloudimg adds it to the listing as a new software version. Your directory stays on its own volume, so you can move it to a new instance by attaching the volume (or a snapshot of it).

Step 15: Security recommendations

Allow port 22 from your own networks only, and port 10636 only from the networks your applications and administrators use. Never open 10389: it only listens on the instance.
Keep the administrator password for administration; give every application its own service account with access control items that grant only what it needs (Step 10).
Pin the instance's certificate in each client after comparing its fingerprint, or use a certificate from your own certificate authority (Step 9). Do not add the generated certificate to a system trust store.
Snapshot the directory volume regularly and protect the snapshots like the directory.
Keep the operating system patched; unattended security upgrades are on.

Support and licensing

Apache Directory Server is open source under the Apache License 2.0; there is no per user or per CPU licence fee. The licence and notice are in /usr/share/doc/apacheds/. Apache, Apache Directory and ApacheDS are trademarks of the Apache Software Foundation; cloudimg is not affiliated with or endorsed by the Apache Software Foundation. The AMI price covers cloudimg's hardening, first boot setup and support.

Email: support@cloudimg.co.uk
Website: https://www.cloudimg.co.uk
Support: 24/7, with a 24 hour response SLA