Monitoring OpenLDAP with Vigilmon

OpenLDAP (slapd) is the most widely deployed open-source LDAP directory server in the world, serving as the authentication backbone for enterprise Linux environments, cloud-init user provisioning, and application authentication across thousands of organizations. When slapd is healthy, authentication is instant and invisible. When it fails — or when replication silently diverges — SSH logins hang, application auth breaks, and users can't access anything. Vigilmon provides continuous monitoring of your OpenLDAP infrastructure, watching LDAP ports, TLS certificates, and replication health before failures cascade.

What You'll Set Up

TCP port monitors for LDAP (389) and LDAPS (636)
HTTP monitor for phpLDAPadmin web UI (if deployed)
SSL certificate alerts for LDAPS TLS certificates
Cron heartbeat for OpenLDAP replication (syncrepl) health verification

Prerequisites

OpenLDAP (slapd) 2.5+ running on Linux
LDAP accessible on port 389 and/or LDAPS on port 636
Optionally: phpLDAPadmin installed at http://your-server/phpldapadmin
A free Vigilmon account

Step 1: Monitor the LDAP TCP Port

The most direct way to monitor slapd is a TCP connection check on port 389. A successful TCP connection confirms the process is running and accepting connections — no LDAP query required:

Log in to vigilmon.online and click Add Monitor.
Set Type to TCP Port.
Enter Host: ldap.yourdomain.com (or the server's IP address).
Enter Port: 389
Set Check interval to 5 minutes.
Click Save.

This is a lightweight check that works regardless of bind credentials or directory content. A failed TCP connection is the fastest signal that slapd has crashed or the server is unreachable.

Step 2: Monitor the LDAPS Port

LDAPS (port 636) provides TLS-encrypted LDAP — many enterprise environments require all LDAP traffic to use LDAPS, and applications may be configured to refuse plain LDAP. Monitor LDAPS independently because the TLS stack adds additional failure modes (certificate expiry, protocol mismatch):

Click Add Monitor → TCP Port.
Enter Host: ldap.yourdomain.com
Enter Port: 636
Set Check interval to 5 minutes.
Click Save.

If your environment uses StartTLS on port 389 instead of dedicated LDAPS on 636, the port 389 monitor from Step 1 covers that path. Both LDAP and LDAPS monitors together confirm the directory is reachable across all access methods your clients use.

Step 3: Monitor phpLDAPadmin (If Deployed)

phpLDAPadmin provides a web-based interface for browsing and managing your LDAP directory. If your team uses it for user administration, its availability is operationally important:

For HTTP deployments:

Click Add Monitor → HTTP / HTTPS.
Enter the URL: http://your-server/phpldapadmin
Set Check interval to 5 minutes.
Set Expected HTTP status to 200.
Click Save.

For HTTPS deployments:

Use https://your-server/phpldapadmin as the URL.
Enable Monitor SSL certificate (covered in Step 4).

If phpLDAPadmin is not part of your stack, skip this step — the TCP port monitors from Steps 1 and 2 are the critical monitors.

Step 4: SSL Certificate Alerts for LDAPS

The TLS certificate on port 636 is one of the most operationally dangerous expiry scenarios in LDAP infrastructure. When it expires, LDAP clients that validate certificates will immediately start rejecting connections — breaking application authentication across every service that uses LDAPS. Unlike a web server certificate, there's no browser warning giving users a chance to click through; applications fail hard.

Add a certificate expiry monitor:

Click Add Monitor → HTTP / HTTPS.
Enter the URL: https://ldap.yourdomain.com (Vigilmon will connect to the HTTPS port and read the certificate).

If your LDAPS certificate is on a non-standard HTTPS URL, add the monitor against the LDAPS host and enable SSL monitoring.
Enable Monitor SSL certificate under the SSL section.
Set Alert when certificate expires in less than 30 days.
Click Save.

Use a 30-day window — LDAPS certificate renewal often requires coordinating client certificate trust stores, and you need time to roll out the new certificate before the old one expires.

To check the current certificate expiry on the LDAP server directly:

echo | openssl s_client -connect ldap.yourdomain.com:636 -quiet 2>/dev/null \
  | openssl x509 -noout -dates

To renew a Let's Encrypt certificate used for LDAPS (with a post-renewal hook to restart slapd):

# /etc/letsencrypt/renewal-hooks/post/restart-slapd.sh
#!/bin/bash
systemctl restart slapd

Step 5: Heartbeat Monitoring for OpenLDAP Replication

OpenLDAP's syncrepl replication keeps directory data synchronized between provider (master) and consumer (replica) servers. Replication failures are silent — the provider continues serving requests while the consumer diverges, and you only discover the gap during a failover when the replica is serving stale user data.

Use a scheduled verification script and Vigilmon's cron heartbeat to catch replication divergence early:

In Vigilmon, click Add Monitor → Cron Heartbeat.
Set the expected ping interval to 60 minutes (run the check hourly).
Copy the heartbeat URL (e.g. https://vigilmon.online/heartbeat/abc123).

Create a replication health check script on the OpenLDAP server:

#!/bin/bash
# /usr/local/bin/ldap-replication-check.sh
# Checks that the consumer's contextCSN matches the provider's

PROVIDER="ldap://ldap-provider.internal"
CONSUMER="ldap://ldap-consumer.internal"
BIND_DN="cn=monitor,dc=example,dc=com"
BIND_PW="your-monitor-password"
BASE_DN="dc=example,dc=com"

PROVIDER_CSN=$(ldapsearch -x -H "$PROVIDER" \
  -D "$BIND_DN" -w "$BIND_PW" \
  -b "$BASE_DN" -s base contextCSN 2>/dev/null | grep contextCSN | head -1)

CONSUMER_CSN=$(ldapsearch -x -H "$CONSUMER" \
  -D "$BIND_DN" -w "$BIND_PW" \
  -b "$BASE_DN" -s base contextCSN 2>/dev/null | grep contextCSN | head -1)

if [ "$PROVIDER_CSN" = "$CONSUMER_CSN" ] && [ -n "$PROVIDER_CSN" ]; then
    curl -s https://vigilmon.online/heartbeat/abc123
fi

Make it executable and schedule it hourly:

chmod +x /usr/local/bin/ldap-replication-check.sh
echo "0 * * * * root /usr/local/bin/ldap-replication-check.sh" | sudo tee /etc/cron.d/ldap-replication-check

The heartbeat fires only when the contextCSN values match — confirming the consumer is fully in sync. If they diverge, or if either server is unreachable, the ping is withheld and Vigilmon alerts after the expected interval.

To check replication status interactively on the provider:

ldapsearch -x -H ldap://localhost -b "dc=example,dc=com" \
  -s base contextCSN

Step 6: Configure Alert Channels

Go to Alert Channels in Vigilmon and add email, Slack, or PagerDuty.
Set Consecutive failures before alert to 1 on the TCP port monitors — LDAP is a synchronous dependency for authentication, and a single missed check is already impacting users.
Set the heartbeat alert to 1 missed ping — a replication gap caught within an hour is recoverable; caught after days it may require a full resync.

Summary

| Monitor | Target | What It Catches | |---|---|---| | TCP port | :389 LDAP | slapd crash or network failure | | TCP port | :636 LDAPS | LDAPS stack failure | | HTTP (phpLDAPadmin) | /phpldapadmin | Web UI unavailable | | SSL certificate | ldap.yourdomain.com:636 | LDAPS cert expiry | | Cron heartbeat | Replication check script | syncrepl divergence |

OpenLDAP is the identity foundation that everything else depends on — when slapd is down, nothing authenticates. With Vigilmon monitoring both TCP ports, the TLS certificate on LDAPS, and the syncrepl replication health via heartbeat, you'll catch failures at every layer before they escalate into infrastructure-wide authentication outages.