NTP, Clock Drift, and Service Accounts Unavailable Oddity

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.

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.

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.

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?

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.

@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.

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.