This guide provides hands-on, compliance-focused steps to configure Network Time Protocol (NTP) on Windows and Chrony on Linux so your small business can demonstrate adherence to the Compliance Framework requirement AU.L2-3.3.7 (NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2) for accurate system time and synchronized timestamps across devices.
Implementation objectives and what auditors expect
AU.L2-3.3.7 requires that system clocks be synchronized with an authoritative time source to ensure reliable timestamps in logs used for audit, incident response, and forensics. For Compliance Framework evidence you should be able to produce: configuration files (chrony.conf or Windows Time settings), verification outputs (chronyc tracking, w32tm /query /status), screenshots of Group Policy or systemd configuration, firewall rules allowing UDP/123, and a log of periodic monitoring/alerts that show synchronization status over time.
Risk of not implementing accurate time synchronization
Without consistent, accurate time you face several risks: inability to correlate events across systems, failed or delayed incident detection, lost forensic integrity, authentication failures (Kerberos relies on time skew limits), and non-compliance findings that can lead to contractual penalties. Small businesses often misattribute root causes when timestamps disagree — fixing time sync early prevents cascading operational and compliance failures.
Windows (NTP / Windows Time) — step-by-step
Domain controllers should be configured as the authoritative time source for domain-joined hosts and should themselves sync to a reliable external source. For a domain controller, use Group Policy or direct commands. Example commands (run elevated): w32tm /config /syncfromflags:manual /manualpeerlist:"0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.org" /reliable:yes /update then w32tm /resync /rediscover. For domain-joined workstations and servers, use GPO: Computer Configuration → Administrative Templates → System → Windows Time Service → Time Providers → Configure Windows NTP Client and set NtpServer to your DCs (use FQDNs) with Type=NTP and SpecialPollInterval as appropriate.
For standalone Windows servers (not AD-joined) run: w32tm /config /syncfromflags:manual /manualpeerlist:"0.us.pool.ntp.org,1.us.pool.ntp.org" /update then w32tm /resync. Verify with w32tm /query /status and w32tm /query /peers. Ensure UDP port 123 is allowed outbound/inbound per your topology. Collect evidence by exporting the w32tm outputs and taking screenshots of the GPO settings; schedule a weekly or daily automated script that logs w32tm /query /status to a central log store for audit.
Linux (Chrony) — step-by-step
Chrony is recommended for modern Linux systems because it handles intermittent connections and large initial offsets well. Install and enable Chrony: on Debian/Ubuntu: sudo apt update && sudo apt install chrony; on RHEL/CentOS: sudo yum install chrony. Edit /etc/chrony/chrony.conf to point to at least 3 reliable servers, for example: pool 2.pool.ntp.org iburst. Useful config additions: driftfile /var/lib/chrony/drift, makestep 1.0 3 (allow large steps during boot), rtcsync (if hardware RTC should be kept in sync), and allow
If your small business has an internal master NTP server (recommended for air-gapped or controlled environments), configure that host with GPS/atomic source or the upstream ISP NTP servers, set local stratum (local stratum 10 using the 'local' directive) only when necessary, and restrict queries using firewall rules. Chrony supports NTS (Network Time Security) and symmetric key authentication — consider these for higher assurance deployments; for most SMBs, using multiple validated public pools and network restrictions is acceptable with documented justification.
Small business scenarios and practical examples
Scenario A: A 10-user office without AD uses a single Linux server as local NTP (Chrony) configured to pool 2.pool.ntp.org and serves the local LAN; all endpoints are pointed at that server. Evidence: chrony.conf, chronyc sources log, firewall allowing UDP/123, and scheduled verification script output. Scenario B: A small shop with AD uses the PDC Emulator as the authoritative time source syncing to NIST/public pool via GPO; workstations use domain time via Kerberos — evidence includes GPO screenshots, w32tm query outputs, and DC w32tm config. Scenario C: High-security contractor with controlled environment uses a GPS-stratum 1 appliance to serve time internally; Chrony is configured with the internal appliance and NTS or symmetric key authentication; maintain key and device custody logs for auditors.
Compliance tips and best practices
Best practices include: use at least three independent time sources (mix pools or vendor servers), prefer geographically close or same-region servers to reduce network latency, lock down UDP/123 to known hosts, keep logs in UTC across all systems, document your time topology and change control, and implement monitoring (Nagios, Zabbix, Splunk alerts) that triggers when offset exceeds your threshold (e.g., >1 second for Kerberos-sensitive environments). Regularly collect verification evidence (monthly) and keep it in your compliance evidence repository with timestamps and signer verification where needed.
Also ensure you have operational SOPs: how to replace an upstream NTP server, how to respond to time drift alerts, and how to validate a new time source (trial period, compare offsets). For audits, provide chronyc outputs, w32tm status, GPO exports, firewall rule sets, and monitoring alerts correlating to your timeline of checks.
In summary, meeting AU.L2-3.3.7 is practical for small businesses if you implement consistent time synchronization: configure Windows Time correctly (GPO for AD or w32tm for standalone), use Chrony on Linux with multiple, reliable sources, secure UDP/123, monitor offsets, document the topology, and retain verification evidence. Doing so reduces forensic risk, ensures Kerberos reliability, and provides the demonstrable controls auditors expect under the Compliance Framework.
