Posted on 03-12-2024 10:27 AM
I recently had a test MacBook Air on which I had deployed Jamf Protect and also used Jamf Compliance Editor to generate CIS Level 1 controls for macOS Sonoma - all via Jamf Pro.
Jamf Pro, Jamf Protect and the CIS Level 1 controls had all been successfully deployed and were operating on this laptop.
As mentioned in the subject, the laptop battery ended up going flat. I therefore had plugin it in for a while to get enough charge to turn it on. Nothing unusual so far. The laptop as a result had also had its clock reset, again nothing unusual so far.
When booted the Mac did not do a successful NTP sync to reset the clock correctly. This could be argued as being unusual. I am presuming this is because it was trying to do a secure e.g. SSL connection and because the clock was years incorrect that failed - certainly the web browser failed to load websites because of this and also the Jamf Pro agent was not able to sync to the Jamf Pro server for the same reason.
Now where it gets more interesting and problematic is that the CIS Level 1 Controls install a profile which locks the date/time settings to sync to time.apple.com and this being a managed profile cannot be overridden and even if the file itself is deleted it is automatically restored on the next login. It has also been set to disallow removal via the normal Profiles preference pane. All intended to prevent users from messing with the CIS Level 1 controls.
In this case it was preventing me manually correcting the Mac clock to get it back in to a working state.
I then thought I was being clever by booting in to recovery mode and running Terminal and in Terminal running the following command -
sntp -sS time.apple.com
This then via the date command indicated the clock was now corrected. I then rebooted as normal and initially at the login window the clock still looked correct. However once I logged in the clock was unfortunately returned to a wildly incorrect date/time and then it was again still unable to talk to Internet services due to this discrepancy.
Note: Trying the above command when booted as normal was also being blocked by the CIS Level 1 Controls.
Has anyone else seen a similar problem and have a better solution than the following?
As the moment it looks like either I will have to remove the main MDM Profile which had been installed during the initial enrolment by Jamf Pro, this should also then remove all the children profiles including the CIS Level 1 profiles. I then hope that I could manually set the clock and manually re-enrol it. The other option would be to completely erase and reinstall of course.
It could possibly be argued that the CIS Level 1 controls are causing this although they are doing what they are designed to do. What is surprising is that macOS fails to sync at boot/login and this could possibly be consider a bug. One might also consider this to be a Catch22 caused by the CIS controls. What I cannot understand is that when I apparently have corrected the clock via Recovery mode it goes wrong again after a normal login, it is not a timezone error it resets to being years out of sync again.