tutorial

Monitoring Samba Active Directory with Vigilmon

Samba AD DC is the open source Active Directory replacement — and when it goes down, every Windows login fails. Here's how to monitor Samba AD health, Kerberos authentication, LDAP query latency, DNS resolution, and replication with Vigilmon.

Samba 4 turned Linux into a fully compatible Active Directory Domain Controller — Kerberos, LDAP, DNS, Group Policy, NetLogon, all of it. It's the cornerstone of mixed Linux/Windows environments that don't want a Windows Server license. But when the samba daemon crashes, every Windows machine on the domain loses authentication. When Kerberos clock skew exceeds five minutes, logins start failing with cryptic error messages. When DNS fails, clients can't even find the domain controller. Vigilmon watches all of these layers so you know before your users do.

What You'll Set Up

  • Samba daemon process and LDAP port monitoring
  • Kerberos authentication health checks
  • LDAP query response time monitoring
  • AD DNS SRV record resolution checks
  • SMB file share availability monitoring
  • Time synchronization (NTP) alerting
  • Samba log error rate monitoring

Prerequisites

  • Samba 4.x configured as an AD DC (server role = active directory domain controller)
  • Domain controller hostname and IP accessible from your monitoring node
  • A free Vigilmon account

Step 1: Monitor the Samba Daemon and LDAP Port

The samba process provides every AD DC service: Kerberos, LDAP, DNS, NetLogon. Monitor it at the TCP level first — Samba listens on port 389 (LDAP) and 636 (LDAPS).

LDAP port check (TCP):

  1. Log in to vigilmon.online and click Add Monitor.
  2. Set Type to TCP Port.
  3. Enter your Samba DC hostname and port 389.
  4. Set Check interval to 1 minute.
  5. Click Save.

Repeat for port 636 (LDAPS) if you have TLS configured.

Also add a TCP Port monitor for port 88 (Kerberos KDC) and port 445 (SMB):

| Port | Service | Alert if down | |------|---------|--------------| | 389 | LDAP | All directory queries failing | | 636 | LDAPS | Secure LDAP queries failing | | 88 | Kerberos KDC | All domain authentication failing | | 445 | SMB/CIFS | File shares and sysvol unavailable | | 53 | DNS (TCP) | AD DNS resolution failing |


Step 2: Monitor Kerberos Authentication Health

Kerberos is the primary AD authentication mechanism. Monitor KDC responsiveness by requesting a ticket granting ticket (TGT) from a monitoring account.

Create a monitoring service account:

# On the Samba DC, create a monitoring user
samba-tool user create vigilmon-monitor 'SecureMonitorPassword123!'
samba-tool user setexpiry vigilmon-monitor --noexpiry

Create the Kerberos health check script:

#!/bin/bash
# /usr/local/bin/samba-kerberos-check.sh
DOMAIN="example.com"
MONITOR_USER="vigilmon-monitor"
MONITOR_PASS="SecureMonitorPassword123!"
VIGILMON_WEBHOOK="https://vigilmon.online/api/webhook/YOUR_KERBEROS_WEBHOOK_ID"

# Attempt to get a Kerberos TGT
echo "${MONITOR_PASS}" | kinit "${MONITOR_USER}@${DOMAIN^^}" > /tmp/kinit-output.txt 2>&1
EXIT_CODE=$?

if [ "${EXIT_CODE}" -eq 0 ]; then
    kdestroy > /dev/null 2>&1
    curl -s -X POST "${VIGILMON_WEBHOOK}" \
        -H "Content-Type: application/json" \
        -d '{"status": "up", "message": "Kerberos TGT acquisition successful"}'
else
    ERROR=$(cat /tmp/kinit-output.txt | head -3 | tr '"' "'")
    curl -s -X POST "${VIGILMON_WEBHOOK}" \
        -H "Content-Type: application/json" \
        -d "{\"status\": \"down\", \"message\": \"Kerberos auth failed: ${ERROR}\"}"
fi

Schedule this every 5 minutes:

*/5 * * * * root /usr/local/bin/samba-kerberos-check.sh

Step 3: Monitor LDAP Query Response Time

Active Directory's LDAP queries drive logins, Group Policy application, and directory lookups. Latency above 100ms causes noticeable slowdowns in Windows logins. Monitor LDAP response time from a probe node.

Create the LDAP latency check:

#!/bin/bash
# /usr/local/bin/samba-ldap-check.sh
DC_HOST="dc1.example.com"
BASE_DN="dc=example,dc=com"
BIND_DN="cn=vigilmon-monitor,cn=users,dc=example,dc=com"
BIND_PASS="SecureMonitorPassword123!"
VIGILMON_WEBHOOK="https://vigilmon.online/api/webhook/YOUR_LDAP_WEBHOOK_ID"
MAX_LATENCY_MS=100

START=$(date +%s%3N)
ldapsearch -x -H "ldap://${DC_HOST}" \
    -D "${BIND_DN}" -w "${BIND_PASS}" \
    -b "${BASE_DN}" -s base "(objectclass=*)" dn > /dev/null 2>&1
EXIT_CODE=$?
END=$(date +%s%3N)

LATENCY=$((END - START))

if [ "${EXIT_CODE}" -ne 0 ]; then
    curl -s -X POST "${VIGILMON_WEBHOOK}" \
        -H "Content-Type: application/json" \
        -d "{\"status\": \"down\", \"message\": \"LDAP query failed (error ${EXIT_CODE})\"}"
elif [ "${LATENCY}" -gt "${MAX_LATENCY_MS}" ]; then
    curl -s -X POST "${VIGILMON_WEBHOOK}" \
        -H "Content-Type: application/json" \
        -d "{\"status\": \"down\", \"message\": \"LDAP latency ${LATENCY}ms exceeds ${MAX_LATENCY_MS}ms threshold\"}"
else
    curl -s -X POST "${VIGILMON_WEBHOOK}" \
        -H "Content-Type: application/json" \
        -d "{\"status\": \"up\", \"message\": \"LDAP responding in ${LATENCY}ms\"}"
fi

Run this every 2 minutes to catch latency spikes early.


Step 4: Monitor AD DNS Resolution

Samba AD requires its internal DNS to work correctly — Windows clients discover domain controllers by querying SRV records like _ldap._tcp.dc._msdcs.example.com. If these records fail to resolve, clients cannot join the domain or authenticate.

Create the DNS SRV record check:

#!/bin/bash
# /usr/local/bin/samba-dns-check.sh
DOMAIN="example.com"
DC_DNS="${DOMAIN}"  # Use the DC as the DNS server being tested
VIGILMON_WEBHOOK="https://vigilmon.online/api/webhook/YOUR_DNS_WEBHOOK_ID"

FAILURES=""

# Check critical AD SRV records
SRV_RECORDS=(
    "_ldap._tcp.dc._msdcs.${DOMAIN}"
    "_kerberos._tcp.dc._msdcs.${DOMAIN}"
    "_kerberos._udp.${DOMAIN}"
    "_kpasswd._tcp.${DOMAIN}"
)

for SRV in "${SRV_RECORDS[@]}"; do
    if ! host -t SRV "${SRV}" > /dev/null 2>&1; then
        FAILURES="${FAILURES}${SRV}; "
    fi
done

if [ -n "${FAILURES}" ]; then
    curl -s -X POST "${VIGILMON_WEBHOOK}" \
        -H "Content-Type: application/json" \
        -d "{\"status\": \"down\", \"message\": \"AD DNS SRV records missing: ${FAILURES}\"}"
else
    curl -s -X POST "${VIGILMON_WEBHOOK}" \
        -H "Content-Type: application/json" \
        -d '{"status": "up", "message": "All AD DNS SRV records resolving"}'
fi

Schedule every 5 minutes. A DNS failure is immediately impactful — Windows clients that can't find the DC will fail authentication on next login.


Step 5: Monitor NTP Time Synchronization

Kerberos requires that the time difference between the KDC and clients stay within 5 minutes. Even a 6-minute skew causes all Kerberos authentication to fail with KRB5KRB_AP_ERR_SKEW. Monitor NTP sync status on the DC itself.

Create the NTP skew check:

#!/bin/bash
# /usr/local/bin/samba-ntp-check.sh
MAX_OFFSET_SEC=60  # Alert at 60 seconds — well before the 5-minute Kerberos limit
VIGILMON_WEBHOOK="https://vigilmon.online/api/webhook/YOUR_NTP_WEBHOOK_ID"

# Get current NTP offset in milliseconds (chrony)
if command -v chronyc > /dev/null 2>&1; then
    OFFSET=$(chronyc tracking | grep "System time" | awk '{print $4}')
    OFFSET_SEC=$(echo "${OFFSET}" | awk '{print ($1 < 0) ? -$1 : $1}')
elif command -v ntpq > /dev/null 2>&1; then
    OFFSET=$(ntpq -p 2>/dev/null | grep '^\*' | awk '{print $9}')
    OFFSET_SEC=$(echo "${OFFSET}" | awk '{v=$1; if(v<0) v=-v; print v/1000}')
else
    OFFSET_SEC=0
fi

# Compare with max allowed skew
IS_HIGH=$(echo "${OFFSET_SEC} ${MAX_OFFSET_SEC}" | awk '{print ($1 > $2) ? "yes" : "no"}')

if [ "${IS_HIGH}" = "yes" ]; then
    curl -s -X POST "${VIGILMON_WEBHOOK}" \
        -H "Content-Type: application/json" \
        -d "{\"status\": \"down\", \"message\": \"NTP offset ${OFFSET_SEC}s exceeds ${MAX_OFFSET_SEC}s — Kerberos auth at risk\"}"
else
    curl -s -X POST "${VIGILMON_WEBHOOK}" \
        -H "Content-Type: application/json" \
        -d "{\"status\": \"up\", \"message\": \"NTP offset ${OFFSET_SEC}s — within safe range\"}"
fi

Step 6: Monitor Samba Log Error Rate

Samba logs critical errors to /var/log/samba/log.samba. A spike in error messages indicates authentication failures, replication problems, or database corruption before they become widespread outages.

Create the log error rate check:

#!/bin/bash
# /usr/local/bin/samba-logerrors-check.sh
LOG_FILE="/var/log/samba/log.samba"
WINDOW_MINUTES=5
ERROR_THRESHOLD=10
VIGILMON_WEBHOOK="https://vigilmon.online/api/webhook/YOUR_LOGERRORS_WEBHOOK_ID"

# Count errors in the last N minutes
SINCE=$(date --date="${WINDOW_MINUTES} minutes ago" '+%Y/%m/%d %H:%M:%S')
ERROR_COUNT=$(awk -v since="${SINCE}" '$0 > since && /\[error\]/ {count++} END {print count+0}' "${LOG_FILE}" 2>/dev/null)

if [ "${ERROR_COUNT}" -ge "${ERROR_THRESHOLD}" ]; then
    curl -s -X POST "${VIGILMON_WEBHOOK}" \
        -H "Content-Type: application/json" \
        -d "{\"status\": \"down\", \"message\": \"${ERROR_COUNT} Samba errors in last ${WINDOW_MINUTES} minutes\"}"
else
    curl -s -X POST "${VIGILMON_WEBHOOK}" \
        -H "Content-Type: application/json" \
        -d "{\"status\": \"up\", \"message\": \"${ERROR_COUNT} errors in last ${WINDOW_MINUTES} minutes (below threshold)\"}"
fi

Step 7: Monitor Group Policy (Sysvol Share)

Windows clients retrieve Group Policy Objects from the SYSVOL and NETLOGON shares on the DC. If these SMB shares are unavailable, clients cannot apply Group Policy at login.

Create a Vigilmon HTTP monitor pointing to a simple script that tests sysvol share accessibility:

#!/bin/bash
# /usr/local/bin/samba-sysvol-check.sh — run via CGI or mini HTTP server
DC_HOST="localhost"

# Test sysvol path accessibility
if [ -d "/var/lib/samba/sysvol" ] && [ -r "/var/lib/samba/sysvol" ]; then
    echo "Content-Type: text/plain"
    echo ""
    echo "OK: sysvol accessible"
    exit 0
else
    echo "Status: 503 Service Unavailable"
    echo "Content-Type: text/plain"
    echo ""
    echo "ERROR: sysvol not accessible"
    exit 1
fi

Alternatively, test an SMB connection directly from a monitoring node:

smbclient -L "${DC_HOST}" -N 2>/dev/null | grep -q "SYSVOL" && echo "UP" || echo "DOWN"

Step 8: Configure Alert Channels

  1. In Vigilmon, go to Alert Channels and connect Slack, email, or PagerDuty.
  2. For the LDAP TCP port monitor, set Consecutive failures before alert to 1 — LDAP being down means immediate impact.
  3. For the Kerberos check, alert immediately on first failure.
  4. For the NTP skew monitor, use a warning threshold at 60 seconds and critical at 240 seconds (one minute before Kerberos breaks at 300 seconds).
  5. Set a Maintenance window during Samba DC upgrades to suppress planned downtime alerts.

Summary

| Monitor | Type | What It Catches | |---|---|---| | LDAP port 389 | TCP port | Samba daemon crash | | Kerberos port 88 | TCP port | KDC unavailable | | SMB port 445 | TCP port | File shares down | | Kerberos TGT | Webhook push | Auth service broken end-to-end | | LDAP latency | Webhook push | Slow directory queries affecting logins | | AD DNS SRV records | Webhook push | Clients unable to find DC | | NTP sync | Webhook push | Clock skew approaching Kerberos limit | | Samba log errors | Webhook push | Error spike before visible failure | | Sysvol share | HTTP/webhook | Group Policy delivery blocked |

When Samba AD fails, it takes every Windows login with it. With Vigilmon monitoring the full stack — from TCP port to Kerberos ticket to NTP skew — you catch problems at the infrastructure layer before users start calling IT wondering why they can't log in.

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →