You are being told by users, staff, and network admins that services and/or logons are failing to authenticate. When you look in the System Event Log, you see entries such as those below.
The kerberos client received a KRB_AP_ERR_TKT_NYV error from the server host/COMPANYXdc02.COMPANYX.EXAMPLE.local. This indicates that the ticket used against that server is not yet valid (in relationship to that server time). Contact your system administrator to make sure the client and server times are in sync, and that the KDC in realm COMPANYX.EXAMPLE.LOCAL is in sync with the KDC in the client realm.
Event Category:SPNEGO (Negotiator)
The Security System detected an authentication error for the server ldap/COMPANYXDC03.COMPANYX.EXAMPLE.local. The failure code from authentication protocol Kerberos was “The time at the Primary Domain Controller is different than the time at the Backup Domain Controller or member server by too large an amount.
The network time is most probably off somehow. Here’s the tricky bit, it may not be off in a way you think.
The first thing to do is to compile a list of DCs and member servers and run net time on them:
C:> for %a in (dc1 dc2 exchange1 exchange2) do net time \%a >> out.txt
All of the times should match within a few seconds of one another. If not, you hvae a network time issue. Your AD PDC is the authorative time source. Start debugging there.
Let’s say that your network time appears correct however. Now what? I’ve seen an instance where an upgrade of a Windows 2003 to Windows 2008 R2 server has corrupted the timezone setting. In that case, reset the TZ.
- Open the system clock.
- Notice that the TZ setting isn’t just wrong, but invalid.
- Set the correct TZ.