Step-by-Step Guide to Configure JSS Clock Sync SecurelyKeeping accurate and secure time across your Jamf Pro (JSS) managed fleet is crucial: time skew can break authentication, patching, logging, and scheduled tasks. This guide walks you through planning, configuring, testing, and maintaining secure clock synchronization for macOS devices managed by Jamf Pro (JSS), with examples, commands, and security hardening steps.

Why secure clock sync matters

• Authentication and certificates rely on correct timestamps; large clock drift can cause Kerberos, SAML, and TLS failures.
• Package installs and scheduled tasks may fail or run at unintended times.
• Logs and forensics become unreliable when devices report inconsistent timestamps.
• Compliance and auditing requirements often mandate accurate, tamper-resistant time.

Overview of approaches

You can synchronize clocks in several ways:

• Using the built-in macOS time synchronization (timed/ntpd/ntpdate or systemsetup + network time).
• Configuring macOS to use authenticated NTP (NTP with symmetric keys or NTS — Network Time Security).
• Leveraging an internal trusted NTP server (recommended for air-gapped or enterprise environments).
• Using Jamf-provided configuration profiles or scripts to enforce time settings.

Recommended architecture:

• Primary internal NTP servers (redundant, geographically distributed if possible).
• Upstream synchronization from those servers to reliable external NTP sources (e.g., pool.ntp.org or vendor-provided NTP with NTS).
• Devices configured to use internal servers, with secure authentication where supported.

Preparations and prerequisites

1. Inventory current state:
   • Identify which devices are managed by Jamf and their macOS versions.
   • Determine current NTP configuration: whether devices use system default ntpd/timed or a custom configuration.
2. Choose your NTP servers:
   • Use at least two redundant internal NTP servers.
   • Ensure upstream sources are reliable; consider servers that support NTS if you need encryption.
3. Decide on authentication:
   • For highest security, use NTS where possible (requires NTP servers and clients that support it).
   • If NTS isn’t available, use symmetric keys (shared secrets) or restrict by firewall and ACLs and use internal servers only.
4. Ensure Jamf Pro (JSS) has network access and privileges to deploy configuration profiles, scripts, and packages.

Step 1 — Configure internal NTP servers

Set up at least two internal NTP servers. Common implementations: chrony, ntpd, or timesyncd (Linux), or a dedicated appliance.

Example chrony server (Linux) minimal /etc/chrony.conf entries:

# Use public upstream servers (replace with your chosen upstreams) server 0.pool.ntp.org iburst server 1.pool.ntp.org iburst # Allow client subnet (replace with your CIDR) allow 10.0.0.0/16 # Local stratum if isolated local stratum 10 # Log measurements log tracking measurements statistics 

Security hardening:

• Restrict access to NTP service to your internal IP ranges via firewall and the server’s allow/acl settings.
• Disable broadcast/multicast NTP unless required.
• Enable NTS on the server if supported (chrony 4.0+ has NTS support with an NTS-KE service and certificates).

Step 2 — Configure Jamf Pro to deploy time settings

Jamf can enforce time servers through configuration profiles or scripts. Use a Configuration Profile (Profile Manager style) when possible for clarity and easier maintenance.

Option A — Configuration Profile (recommended)

• Create a new Configuration Profile in Jamf Pro.
• Payload: System Preferences > Date & Time (Network Time).
• Set Network Time to enabled and provide the hostname(s) of your internal NTP servers (enter multiple entries separated by commas if Jamf UI allows).
• Scope to device groups or smart groups (e.g., All macOS devices, or specific network segments).
• Save and deploy.

Option B — Script (when fine-grained control needed)

• Script can use systemsetup or /usr/sbin/ntpdate/ntpd configuration edits. Example script to set network time servers and enable network time: “`bash #!/bin/bash

  Replace with your NTP servers

  SERVERS=(“ntp1.example.local” “ntp2.example.local”)

  Enable network time

  /usr/sbin/systemsetup -setusingnetworktime on

macOS Big Sur+ uses /etc/ntp.conf for ntpd or timed; write servers to /etc/ntp.conf

cat >/etc/ntp.conf <

Jamf-deployed NTP config

driftfile /var/db/ntp.drift pool 0.us.pool.ntp.org iburst EOF

Append internal servers

for s in “\({SERVERS[@]}"; do echo "server \)s iburst” >> /etc/ntp.conf done

Restart time service

if launchctl print system/com.apple.timed &>/dev/null; then launchctl kickstart -k system/com.apple.timed else serveradmin stop ntpd 2>/dev/null serveradmin start ntpd 2>/dev/null fi

- Upload the script to Jamf and scope appropriately. Use careful testing before wide deployment. --- ### Step 3 — Enforce secure authentication (NTS or symmetric keys) NTS (Network Time Security) - Best option when supported by both servers and clients. Provides TLS-based key exchange and AEAD encryption for NTP. - Deploy NTS-KE on your NTP servers and obtain/issue certificates for that service. - Client-side: macOS support for NTS begins to appear in later versions and may require open-source clients (chrony with NTS support) or third-party agents. Verify client compatibility before rolling out. Symmetric keys (ntpd with keys) - Generate a symmetric key file (e.g., /etc/ntp.keys) on servers and distribute to clients securely via Jamf as a payload (File or Script). - Example /etc/ntp.conf server lines:   server ntp1.example.local key 42 - Example /etc/ntp.keys:   42 M mylongsecretkeyhere - Protect the key file with strict permissions (600) and ensure transport via Jamf is secure and restricted to targeted devices. Notes: - Symmetric keys require key management (rotation, revocation). Plan key rotation (e.g., annually or after compromise). - If you can’t use NTS or symmetric keys, at minimum ensure only internal devices can reach your NTP servers (network ACLs + firewall). --- ### Step 4 — Test on pilot devices - Create a small smart group in Jamf for pilot devices (representative mix of macOS versions).   - Deploy the configuration profile/script to that group.   - Verify settings on a pilot Mac:   - systemsetup -getnetworktimeserver   - systemsetup -getusingnetworktime   - sudo ntpq -p  (or chronyc sources) to check peers and offsets   - log show --predicate 'process == "timed"' --last 1h  (for timed logs) - Verify authentication: if using symmetric keys, check ntpq -c "rv 0" or ntpdc output; if using NTS, confirm the NTP client reports NTS associations (client-specific commands). --- ### Step 5 — Monitor and alert - Configure monitoring for time offset and service availability:   - On NTP servers: use monitoring tools (Nagios, Zabbix, Prometheus) to check server reachability, stratum, and reachability.   - On clients: collect ntpq or chronyc metrics via existing management/logging solutions. - Create alerts for:   - Large offsets (>100 ms may be concerning for some services; >1 second is problematic).   - Clients unable to reach NTP servers.   - Authentication failures. - Use Jamf’s inventory extension attributes to record NTP server configuration and last sync time; build smart groups for noncompliant devices. --- ### Step 6 — Rollout and continuous maintenance - Gradually expand scope after pilot success: staging → production groups.   - Maintain redundancy: ensure multiple internal NTP servers and multiple upstream sources.   - Key/certificate rotation: schedule regular rotations for symmetric keys or NTS certificates.   - Update documentation and runbooks for on-call teams to troubleshoot clock issues. --- ### Troubleshooting common issues - Devices still using public NTP servers: ensure profile/script scoped correctly and do not conflict with other profiles or MDM settings. Use mdmclient and profiles command to inspect applied settings.   - Check: profiles -P and /var/db/ConfigurationProfiles - Large initial offset causing ntpd to refuse sync: run sudo sntp -sS <server> or ntpdate once to step the time if needed (careful on domain-joined systems — avoid large steps during Kerberos use). - Timed vs ntpd conflicts on modern macOS: macOS has historically used timed and ntpd; newer macOS versions centralize on timed. Restarting timed after config changes often required:   - sudo launchctl kickstart -k system/com.apple.timed - Authentication failures: check /var/log/system.log and ntpd/chrony logs for errors; ensure key files and permissions are correct. - NTS issues: ensure NTS-KE port (4460/TCP) is reachable from clients and certificates are valid. --- ### Example: Jamf configuration profile settings (summary) - Payload: Date & Time (Network Time)   - Network Time Enabled: Yes   - Time Servers: ntp1.example.local, ntp2.example.local - Scope: Smart Group — All macOS devices on corporate subnets - Maintenance script (optional): Force restart of timed after profile applies --- ### Security checklist (quick) - **Use internal NTP servers** and restrict access via firewall.   - **Prefer NTS**; if not available, use symmetric keys and rotate them.   - **Deploy via Jamf configuration profiles** where possible for consistency.   - **Monitor offsets and authentication** and alert on anomalies.   - **Document procedures and rotation schedules.** --- ### Useful commands reference ```bash # Check if network time is enabled /usr/sbin/systemsetup -getusingnetworktime # Get configured network time server /usr/sbin/systemsetup -getnetworktimeserver # Restart macOS timed service sudo launchctl kickstart -k system/com.apple.timed # Check ntp peers (ntpd) ntpq -p # Check chrony sources chronyc sources # One-time step adjustment (use with caution) sudo sntp -sS ntp1.example.local 

Final notes

Secure, reliable time is foundational for a stable, auditable environment. Use Jamf Pro to centrally enforce settings, prefer authenticated time sync (NTS or symmetric keys), and monitor continuously. Start small with a pilot group, validate across macOS versions, and expand once confidence is established.