NTP, Clock Drift, and Service Accounts Unavailable Oddity

[kendalljjohnson]

We have been having the popular issue of clock drift which I recently addressed by changing out NTP server to our DC server. A new symptom I am now seeing on a specific lab of 13 Late 2012 Mac minis:

When waking them from sleep the clock will be off (sometimes 30-40minutes) but within a couple seconds it corrects itself to the current time. The problem is, despite correcting the time it will still say "Service accounts unavailable" indefinitely. If I login and logout with a local/cached account or restart the computer it will fix itself.

I'm guessing I can resolve this by telling them to never sleep, but wondering if anyone has any insight on what might be cause this drift specifically within sleep.

Thanks!

[kendalljjohnson]

New development: it appears the network accounts unavailable is a false negative. After the time updates, I confirmed that an account that has never logged into that computer is able to login despite the alert.

[FastGM3]

This false negative is seen far too often in our district. It leads to quick conclusions that something is broke, which means calls to the support desk. Another problem is the red dot is actually something you can select, so when you tab from username to password it ends up being a double tab to get past the red dot. This fouls up password entries and for those not paying attention after a few tries can result in being locked out. Techs will also jump to conclusions and re-bind. It's a mess, I really dis-like the red dot.

[AVmcclint]

Are you sure the clock is actually off by 30-40 minutes? If the computer was sleeping and just woke up, maybe it's just a delay in displaying the time correctly after being alseep for 30-40 minutes. Any difficulty connecting to the network immediately after waking up could also be the lag between your computer and the DHCP server or the switch. If an entire lab of Macs is truly 30-40 minutes out of skew, that's the real problem. However such a thing to affect that many Macs at the same time would be far-fetched. That's why I lean toward the slowness of waking up. Setting the hard drive to not go to sleep makes for a faster wakeup. And I agree, the false negative of the red dot is a real pain made especially worse by having to double-tab to get to the password box in Sierra.

[itupshot]

We've been seeing this problem too for months (maybe a year now). It started happening when we upgraded to macOS Sierra. It didn't happen with previous versions of the OS. We usually see it on laptops, since they are most likely to go to sleep. All our desktop systems are set for not sleeping (only the screen).

The drift can be a few seconds, or minutes. It's really annoying because it doesn't seem to recover automatically. Usually one of our IT staff has to uncheck the "Set date and time automatically" box, and check it again to bring it back.

The clock drift causes the computer to not allow network users to log in until it's corrected.

I don't know how to point the machines to our AD server for NTP so the time matches. Do we just use the FQDN, or IP address of the server, or is there a specific address for the NTP service?

[AVmcclint]

I put this command in my daily inventory collection policy to sync up with our AD servers every day:

ntpdate -u 10.1.1.1

And that's it. Since doing that, the only clock problems I've had are if a user lets the battery drain completely when off-network. The only way to fix that is to get hands-on and set the clock manually as the local admin.

[itupshot]

@AVmcclint Hmm, I'm going to try that.

EDIT (3/28/18):
Has setting the policy once per day worked for you? I'm testing with a couple of laptops that I'm setting to sleep on battery during the day for a while, and then check if the time drifted again after correcting it.

[AVmcclint]

Yeah it works like a champ for me. There is still going to be a little drift by maybe a minute +/- but that's well within the tolerances for most network services.