Monitor unlimited number of servers
Filter log events
Create email and web-based reports

Direct access to Microsoft articles
Customized keywords for major search engines
Access to premium content

Event ID: 675 Source: Security

Source
Description
Pre-authentication failed:
User Name: Administrator
User ID: <user sid>
Service Name: krbtgt/<domain>
Pre-Authentication Type: <authentication type>
Failure Code: <failure code>
Client Address: <ip address>
Comments
 
I was receiving a few hundred of these daily. The source client was a Windows 7 PC running Symantec Backup Exec System Recovery (BESR). At one time, I was using a USB hard drive that was attached to an XP  PC in the network. BESR's VProSvc was still trying to ping the non-existent drive every few minutes, which accounted for the errors. Removing the location from BESR resolved.
Pre-authentication can fail in environments where Vista/7/Server 2008/R2 systems are deployed within a 2003 Forest Functional Level (or below) AD domain. This is because the accounts first attempt AES Kerberos encryption, fail and then fall back to RC4-HMAC.  DES encryption types are disabled by default on Vista+ systems.

This is found in Failure code 0x19, pre-authentication type 0x0 events in a 2003 domain with Vista+ clients and can be safely ignored.
In our case, this error was fixed by updating the password for the credentials DHCP used for its DNS Dynamic updates registration.
This can occur when trying to authenticate from a Samba server and not using CAPSLOCK when writing the domain name (eg: Service Name: krbtgt/domain.local failed, while krbtgt/DOMAIN.LOCAL did not).
A faulty machine DNS record led me to the solution. In my case, although the domain security policy was set for account lockout after 8 failed logon attempts, one user's account was locking out after every second attempt, even with the correct password. After unlocking his account, the user could logon but he had 1 try to get it right or the account would once again need to be unlocked. The DNS A record for this user's statically IP'd machine was registered in DNS, but inexplicably, it only had the “write” permission assigned. Rather than granularly re-ACL this record, I simply re-added the machine to the domain after making sure the original DNS record/computer account were deleted post domain disjoin. After rejoining the domain, the issue was resolved.


I just had this event appear on my domain controller for a user who could not log onto one of our file servers. Turns out, he had saved a domain password in his MS Passport. The domain password was changed while Passport stored password did not change. Windows continued sending the old password when the login script was processed. The Passport stored passwords can be accessed in XP from Control Panel - User Accounts.
See ME888612 for a hotfix applicable to Microsoft Windows 2000.

This event is logged when a user attempts to use a different username (i.e., a username other than the one he or she used for the current workstation logon) to connect to a server. For example, a user might try to use the Connect using a different user name feature to use someone else's account to map a drive to a server. See the link to "Audit Account Logon Events" for more information on this issue.
In one case, this Event ID with Failure Code 24 (or 0x18) occured for the IWAM_MachineName account on a domain controller, when the Kerberos settings were put right in the Default Domain Controllers Policy. They had previously been set to "Not defined". This Event ID was followed by Event ID 529, Source Security. The password for the IWAM_MachineName account was mismatched between the Windows Active Directory and the IIS metabase.
As per Microsoft: "After you upgrade the domain to Active Directory, existing Windows 2000-based computers and Windows XP-based computers may not be updated to the DNS-style domain name. As a result, the servers may not receive a Kerberos ticket. If you investigate the computer account attributes for the affected computers by using LDIFDE, the dNSHostName property and the servicePrincipalName property are left blank. If you turn on auditing for logon failures, a security event ID 675 message ("Pre-authentication failed") is intermittently logged for the affected computers". See ME328570 for a hotfix.

See ME824209 on how to use the EventCombMT utility to search the event logs of multiple computers for account lockouts.

See the links to "Auditing and Intrusion Detection" and MSW2KDB for additional information on this event.
Microsoft says that EventID 675 is also logged when there is a different time set on the client machine compared to the server.
This can also occur if terminal sessions remain open on the terminal device (sessions that are not disconnected normally). The Citrix or Terminal Server will still be attempting to reconnect with the old session (old password) information causing the account to lock out.
This error can also be generated when one attempts to re-add the same computer to a domain after a rebuild using an account granted the "Add Workstation" right. See ME329195 for information on why the error occurs. Though the article does not mention event ID 675, that is what we were getting using a scripted build that used the same “add workstation” account each time and failed only when trying to re-add a freshly re-imaged to the domain.
From a newsgroup post: "Check the DNS records and see if that machine's name and IP address are correct there. I had a very similar error in my logs and it was DNS related. Netdiag found the problem for me. The machine failed the dns test (fatal). The records for that machine were missing. Added them back in and problem solved."
When a user attempts to log on at a Windows 2000 Pro workstation and uses a valid domain account name but enters a bad password, the DC records event ID 675 (pre-authentication failed) with Failure Code 24 (or 0x18).By reviewing each of your DC Security logs for this event and failure code, you can track every domain logon attempt that failed as a result of a bad password. In addition to providing the username and domain name, the event provides the IP address of the system from which the logon attempt originated. Windows 2000 also logs event ID 675 when a user attempts to use a different username (i.e. a username other than the one he or she used for the current workstation logon) to connect to a server.


If you experience 675 errors or if you find your account locked out suddently on Win2000 networks after changing your domain password, ensure that you are not logged on another Win2000 machine (apart from the one from which you changed your password). The system tries to renew the Kerberos ticket using the old password and fails.

Windows Event Log Analysis Splunk App

Build a great reporting interface using Splunk, one of the leaders in the Security Information and Event Management (SIEM) field, linking the collected Windows events to www.eventid.net.

Read more...

 

Cisco ASA Log Analyzer Splunk App

Obtain enhanced visibility into Cisco ASA firewall logs using the free Firegen for Cisco ASA Splunk App. Take advantage of dashboards built to optimize the threat analysis process.

Read more...