A number of different problems can lead to users (or computers) being unable to authenticate to the domain. To easily resolve these problems, you need an ordered troubleshooting methodology that simply moves from one possibility to another until you arrive at the actual root cause of the problem.
The symptoms of this problem are obvious: Users can't log on to the domain. However, keep in mind that an underlying problem might be that the user's client computer might not be logging onto the domain either. Client computers that are domain members maintain their own security account in the domain, and must authenticate to the domain before they are able to log on a user account. Normally, client computers attempt to authenticate to the domain as soon as Windows starts. Log on locally and check the System and Security event logs for error messages that indicate that the computer was unable to authenticate.
I'll assume that you've already attempted to reset the user's domain password, checked the Caps Lock key, and the other common culprits of logon problems. For the sake of this discussion, I'm assuming that the user's domain password isn't the problem.
First, ensure that the computer is authenticating to the domain. You can use the Nltest utility from the Support Tools package on the Windows CD-ROM to verify authentication. If authentication isn't working, use the same verification steps presented here, but focus on the computer's domain account rather than the user's account.
First, verify that the computer is able to locate a domain controller. Check the System event log of the client computer for messages indicating that a domain controller couldn't be found. If error message are present, troubleshoot the domain controller location process.
You can also force the domain controller location process to run by using the Nltest support tool and running
Nltest /dsgetdc:domain
on a client computer (replacing domain with the appropriate domain name). If Nltest fails to locate a domain controller, you've found your logon problem.
By default, Windows' Kerberos authentication protocol allows for a 5-minute difference between the clocks of client computers and domain controllers. Kerberos messages are time-stamped at their source and cannot be more than 5 minutes old when they arrive at their destination. If your computers are not time-synchronized correctly, packets might be considered old by the destination even if they arrive almost immediately.
You can configure your domain security policies to allow a longer period of time difference. However, doing so makes your network more vulnerable, as it gives attackers additional time to decrypt and reuse Kerberos messages captured from the network. Rather than extending the Kerberos time tolerance, you should correct the time synchronization problem.
Checking time synchronization is easy: Simply check the clocks on the client computer and a domain controller. If they are more than a minute or two off, troubleshoot time synchronization problems.
Use Active Directory Users and Computers to verify that the computer's domain account isn't locked out or disabled. Also, a computer account that has been cloned from one domain to another can cause problems until the original source account is deleted. If event log messages on the client computer continue to indicate logon problems, you might need to reset the computer's domain account.
Corrective action for logon problems will be determined by the root cause of the problem: