usnistgov/macos_security
1
0
Fork 0
mirror of https://github.com/usnistgov/macos_security.git synced 2026-02-09 08:12:18 +00:00
Code Issues 21 Actions Packages Projects Releases Wiki Activity

Computers that fail os_time_offset_limit_configure #163

New Issue
Closed
opened 2026-01-19 18:29:28 +00:00 by michael · 5 comments
michael commented 2026-01-19 18:29:28 +00:00
Owner
Copy Link

Originally created by @Tribruin on GitHub.

Summary

On a small number of computer, the rule os_time_offset_limit_configure is failing due to being unable to check the time. In the Jamf policy logs I can see this output:

sntp: Exchange failed: Timeout
[message repeats 4 times]
sntp: Clock select failed

Steps to reproduce

This issue is occuring only about 5% of the computers. But, the failures are repeatable on those computers.

Operating System version

mix of 13.4.0 & 13.4.1

Intel or Apple Silicon

Both types of computers are failing due to this issue

What is the current bug behavior?

The time results are not reported, instead an error is shown.

What is the expected correct behavior?

computer should pass the test

Relevant logs and/or screenshots

(Paste any relevant logs - please use code blocks (```) to format console output, logs, and code as it's tough to read otherwise.)

Output of checks

sntp: Exchange failed: Timeout
[message repeats 4 times]
sntp: Clock select failed

Originally created by @Tribruin on GitHub. ### Summary On a small number of computer, the rule os_time_offset_limit_configure is failing due to being unable to check the time. In the Jamf policy logs I can see this output: sntp: Exchange failed: Timeout [message repeats 4 times] sntp: Clock select failed ### Steps to reproduce This issue is occuring only about 5% of the computers. But, the failures are repeatable on those computers. ### Operating System version mix of 13.4.0 & 13.4.1 ### Intel or Apple Silicon Both types of computers are failing due to this issue ### What is the current *bug* behavior? The time results are not reported, instead an error is shown. ### What is the expected *correct* behavior? computer should pass the test ### Relevant logs and/or screenshots (Paste any relevant logs - please use code blocks (```) to format console output, logs, and code as it's tough to read otherwise.) ### Output of checks sntp: Exchange failed: Timeout [message repeats 4 times] sntp: Clock select failed
michael commented 2026-01-19 18:29:28 +00:00
Author
Owner
Copy Link

@brodjieski commented on GitHub:

What do you have your time server set to? Do you have the same issue when setting it to time.apple.com?

@brodjieski commented on GitHub: What do you have your time server set to? Do you have the same issue when setting it to time.apple.com?
michael commented 2026-01-19 18:29:28 +00:00
Author
Owner
Copy Link

@Tribruin commented on GitHub:

Time server is set to time.apple.com using a configuration profile.

@Tribruin commented on GitHub: Time server is set to time.apple.com using a configuration profile.
michael commented 2026-01-19 18:29:28 +00:00
Author
Owner
Copy Link

@robertgendler commented on GitHub:

This seems to be more of a bug or issue with SNTP reaching the server and getting the information it needs.

@robertgendler commented on GitHub: This seems to be more of a bug or issue with SNTP reaching the server and getting the information it needs.
michael commented 2026-01-19 18:29:28 +00:00
Author
Owner
Copy Link

@jmahlman commented on GitHub:

FWIW, I see this often as well. I don't think this is anything the script is doing, I think it's an issue with SNTP. The output is not very useful...

Running the command to configure the settings for: os_time_offset_limit_configure ...
sntp: Exchange failed: Timeout
[message repeats 4 times]
sntp_exchange {
        result: 6 (Timeout)
        header: 00 (li:0 vn:0 mode:0)
       stratum: 00 (0)
          poll: 00 (1)
     precision: 00 (1.000000e+00)
         delay: 0000.0000 (0.000000000)
    dispersion: 0000.0000 (0.000000000)
           ref: 00000000 ("    ")
         t_ref: 00000000.00000000 (0.000000000)
            t1: E844077C.6FDEA465 (3896772476.436990999)
            t2: 00000000.00000000 (0.000000000)
            t3: 00000000.00000000 (0.000000000)
            t4: 00000000.00000000 (0.000000000)
        offset: FFFFFFFF8BDDFC41.C810ADCD80000000 (-1948386238.218495607)
         delay: FFFFFFFF17BBF883.90215B9B00000000 (-3896772476.436991215)
          mean: 0000000000000000.0000000000000000 (0.000000000)
         error: 0000000000000000.0000000000000000 (0.000000000)
          addr: 17.253.126.125
}
@jmahlman commented on GitHub: FWIW, I see this often as well. I don't think this is anything the script is doing, I think it's an issue with SNTP. The output is not very useful... ``` Running the command to configure the settings for: os_time_offset_limit_configure ... sntp: Exchange failed: Timeout [message repeats 4 times] sntp_exchange { result: 6 (Timeout) header: 00 (li:0 vn:0 mode:0) stratum: 00 (0) poll: 00 (1) precision: 00 (1.000000e+00) delay: 0000.0000 (0.000000000) dispersion: 0000.0000 (0.000000000) ref: 00000000 (" ") t_ref: 00000000.00000000 (0.000000000) t1: E844077C.6FDEA465 (3896772476.436990999) t2: 00000000.00000000 (0.000000000) t3: 00000000.00000000 (0.000000000) t4: 00000000.00000000 (0.000000000) offset: FFFFFFFF8BDDFC41.C810ADCD80000000 (-1948386238.218495607) delay: FFFFFFFF17BBF883.90215B9B00000000 (-3896772476.436991215) mean: 0000000000000000.0000000000000000 (0.000000000) error: 0000000000000000.0000000000000000 (0.000000000) addr: 17.253.126.125 } ```
michael commented 2026-01-19 18:29:28 +00:00
Author
Owner
Copy Link

@brodjieski commented on GitHub:

This issue pops up every now and again, and it basically boils down to sntp' s ability to reach the NTP server without issue. If it time's out or fails to communicate for whatever reason, the check cannot parse any results and will fail.

Frankly, this isn't a security control, rather an operational check to make sure your time is close to being in sync for TLS and other secure communications to be valid. There isn't a setting you can change to alter the behavior or make this more "secure". If you're time is off, you'll have issues with communications.

Since this rule originates and is only applicable to CIS benchmarks, it might make sense to bring it up in their forum.

Closing this issue since there isn't much we can really do about it.

@brodjieski commented on GitHub: This issue pops up every now and again, and it basically boils down to `sntp`' s ability to reach the NTP server without issue. If it time's out or fails to communicate for whatever reason, the check cannot parse any results and will fail. Frankly, this isn't a security control, rather an operational check to make sure your time is close to being in sync for TLS and other secure communications to be valid. There isn't a setting you can change to alter the behavior or make this more "secure". If you're time is off, you'll have issues with communications. Since this rule originates and is only applicable to CIS benchmarks, it might make sense to bring it up in their forum. Closing this issue since there isn't much we can really do about it.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
michael
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: usnistgov/macos_security#163
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?