You will have to dig a little deeper. Check scheduled tasks, services, applications
that may use credentials and such on the source server and such. The link below may
help even though it relates to account lockouts since account lockouts are caused by
logon failures. I copied and pasted the most pertinent part of the article below.
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/bpactlck.mspx
Common Causes for Account Lockouts
This section describes some of the common causes for account lockouts The common
troubleshooting steps and resolutions for account lockouts are also described in this
section.
To avoid false lockouts, check each computer on which a lockout occurred for the
following behaviors:
. Programs: Many programs cache credentials or keep active threads that retain
the credentials after a user changes their password.
. Service accounts: Service account passwords are cached by the service control
manager on member computers that use the account as well as domain controllers. If
you reset the password for a service account and you do not reset the password in the
service control manager, account lockouts for the service account occur. This is
because the computers that use this account typically retry logon authentication by
using the previous password. To determine whether this is occurring, look for a
pattern in the Netlogon log files and in the event log files on member computers. You
can then configure the security control manager to use the new password and avoid
future account lockouts.
. Bad Password Threshold is set too low: This is one of the most common
misconfiguration issues. Many companies set the Bad Password Threshold registry value
to a value lower than the default value of 10. If you set this value too low, false
lockouts occur when programs automatically retry invalid passwords. Microsoft
recommends that you leave this value at its default value of 10. For more
information, see "Choosing Account Lockout Settings for Your Deployment" in this
document.
. User logging on to multiple computers: A user may log onto multiple computers
at one time. Programs that are running on those computers may access network
resources with the user credentials of that user who is currently logged on. If the
user changes their password on one of the computers, programs that are running on the
other computers may continue to use the original password. Because those programs
authenticate when they request access to network resources, the old password
continues to be used and the users account becomes locked out. To ensure that this
behavior does not occur, users should log off of all computers, change the password
from a single location, and then log off and back on.
Note: Commuters running Windows XP or a member of the Windows Server 2003
family automatically detect when the users password has changed and prompt the user
to lock and unlock the computer to obtain the current password. No logon and logoff
is required for users using these computers.
. Stored user names and passwords retains redundant credentials: If any of the
saved credentials are the same as the logon credential, you should delete those
credentials. The credentials are redundant because Windows tries the logon
credentials when explicit credentials are not found. To delete logon credentials, use
the Stored User Names and Passwords tool. For more information on Stored User Names
and Passwords, see online help in Windows XP and the Windows Server 2003 family.
Note: Computers that are running Windows 95, Windows 98, or Windows Millennium
Edition do not have a Stored User Names and Passwords file. Instead, you should
delete the users .pwl file. This file is named Username.pwl, where Username is the
users logon name. The file is stored in the Systemroot folder.
. Scheduled tasks: Scheduled processes may be configured to using credentials
that have expired.
. Persistent drive mappings: Persistent drives may have been established with
credentials that subsequently expired. If the user types explicit credentials when
they try to connect to a share, the credential is not persistent unless it is
explicitly saved by Stored User Names and Passwords. Every time that the user logs
off the network, logs on to the network, or restarts the computer, the authentication
attempt fails when Windows attempts to restore the connection because there are no
stored credentials. To avoid this behavior, configure net use so that is does not
make persistent connections. To do this, at a command prompt, type net use
/persistent:no. Alternately, to ensure current credentials are used for persistent
drives, disconnect and reconnect the persistent drive.
. Active Directory replication: User properties must replicate between domain
controllers to ensure that account lockout information is processed properly. You
should verify that proper Active Directory replication is occurring.
. Disconnected Terminal Server sessions: Disconnected Terminal Server sessions
may be running a process that accesses network resources with outdated authentication
information. A disconnected session can have the same effect as a user with multiple
interactive logons and cause account lockout by using the outdated credentials. The
only difference between a disconnected session and a user who is logged onto multiple
computers is that the source of the lockout comes from a single computer that is
running Terminal Services.
. Service accounts: By default, most computer services are configured to start
in the security context of the Local System account. However, you can manually
configure a service to use a specific user account and password. If you configure a
service to start with a specific user account and that accounts password is changed,
the service logon property must be updated with the new password or that service may
lock out the account.
