How inaccurate must the clock's time be for NTLM requests to be denied due to the time being incorrect?

We have a network where the time on some of the client workstations is inaccurate. There is a problem with NTP on the clients or domain controllers causing the time to not synchronize. We are working on that problem separately.

In the meantime, authentication requests on the domain via NTLM fail after a period of time when the clock drifts away from the domain controller and server's times. What is the threshold of clock accuracy needed for these requests to succeed? Do the clocks have to be accurate to 10 seconds of each other? 30 seconds? One minute?

EDIT: An answer that specifies NTLM does not rely on the correct time is incorrect. According Microsoft KB Article 976918: http://support.microsoft.com/kb/976918

Windows 7 and Windows Server 2008 R2 support Extended Protection for Integrated Authentication which includes support for Channel Binding Token (CBT) by default. [...] You may experience one or more of the following symptoms: [...] NTLM authentication failures when there is a time difference between the client and DC or workgroup server.

Solution 1:

As far as I know, timestamps are not used in NTLM at all.

On the other hand, Kerberos (which is the primary authentication protocol in Active Directory), generally requires the clocks to be within a few minutes. Microsoft Windows has 5 minutes as the default MaxClockSkew, as does MIT Kerberos.