Apache Directory Server 2.0.0 AM27

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

Choose m5.large, your key pair and a security group as above. The AMI already carries the 10 GiB directory volume, and you can make it larger on the launch page.

Or launch 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}]'

The default SSH user for Apache Directory Server 2.0.0.AM27 on Ubuntu 24.04 is ubuntu. Connect with your key pair:

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

First boot creates the directory instance, which takes 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/sac/data/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).

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=sac,dc=local APACHEDS_TLS_CERT=/etc/apacheds/tls/apacheds.crt

The file also holds APACHEDS_ADMIN_PASSWORD (the directory administrator's password). To get the administrator password itself, for example to type it into an LDAP browser, run 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.

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 = sac 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

The OpenLDAP tools read the password from a file with -y, so it never appears in the process list or your shell history.

The following commands pin the instance's certificate for the tools (LDAPTLS_CACERT), put the password in a private temporary file, bind as the administrator and search 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=sac,dc=local '(objectClass=inetOrgPerson)' uid cn mail rm -f "$PWF"

dn:uid=admin,ou=system dn: uid=bob,ou=people,dc=sac,dc=local mail: bob@sac.local cn: Bob Brown uid: bob dn: uid=alice,ou=people,dc=sac,dc=local mail: alice@sac.local cn: Alice Anderson uid: alice

The image ships a small demo tree under dc=sac,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.

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=sac,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

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. They need:

• The LDAPS URL ldaps://<your-host>:10636
• The bind DN and password of an account you create for them (Step 10)
• The base DN dc=sac,dc=local or your own suffix
• 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.

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, and restarts the front. It also 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

Create entries with ldapadd. Give a user a password by replacing userPassword from a private file. The server hashes it with salted SHA-512, and ApacheDS's password modify operation only changes an existing password.

This example 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=sac,dc=local objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top cn: Carol Clark sn: Clark uid: carol mail: carol@sac.local EOF ldapdelete -x -H "$URL" -D uid=admin,ou=system -y "$PWF" uid=carol,ou=people,dc=sac,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=sac,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=sac,dc=local -y "$CPW" ldapsearch -x -LLL -H "$URL" -D uid=carol,ou=people,dc=sac,dc=local -y "$CPW" -b dc=sac,dc=local '(uid=alice)' dn echo "entries carol can read: $(ldapsearch -x -LLL -H "$URL" -D uid=carol,ou=people,dc=sac,dc=local -y "$CPW" -b dc=sac,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=sac,dc=local" modifying entry "uid=carol,ou=people,dc=sac,dc=local" dn:uid=carol,ou=people,dc=sac,dc=local entries carol can read: 0

Carol can bind, so applications can check her password. 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.

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

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. For a consistent copy, stop the server first (sudo systemctl stop apacheds), then start it again.

The snapshot keeps everything, including password hashes and the server configuration, so protect it 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=sac,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).

The image places its components at these paths:

• 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.sac
• TLS front certificate and key: /etc/apacheds/tls/apacheds.crt and 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)

Check the installed release and the Java runtime:

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.sac.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, and this 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.

Ubuntu security updates install automatically, because unattended upgrades are on. Run sudo apt-get update && sudo apt-get upgrade to apply everything else, the Java runtime included.

ApacheDS itself is the release in /opt/apacheds-2.0.0.AM27. When Apache publishes a newer release, SecureAnyCloud 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).

• Allow port 22 from your own networks only, and port 10636 only from the networks your applications and administrators use. Never open 10389, because it listens only 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.