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. The EventId.Net for Splunk Add-on assumes that Splunk is collecting information from Windows servers and workstation via the Splunk Universal Forwarder.
|Type: Failure Audit|
Reason: An unexpected error occurred during logon
User Name: <user name>
Domain: <domain name>
Logon Type: <logon type>
Logon Process: <logon process>
Authentication Package: <package name>
Workstation Name: <workstation name>
Status code: <error code>
Substatus code: <error code 2>
Caller User Name: <name>
Caller Domain: <domain>
Caller Logon ID: <ID>
Caller Process ID: <ID>
Transited Services: <services>
Source Network Address: <address>
Source Port: <value>.
|English: This information is only available to subscribers. An example of English, please!|
|Concepts to understand:|
Why are some errors “unexpected”?
What is an authentication protocol?
If this event occurs when you try to log on to a computer that is running Windows XP SP2 by using a Remote Desktop Protocol connection, see ME939682 for a hotfix applicable to Microsoft Windows XP.
This behavior can occur because Kerberos authentication is turned on. As a result, an authentication issue occurs between Internet Information Services (IIS) 5.0 and the Exchange virtual server's IIS resources. See ME329938 for a hotfix applicable to Microsoft Windows 2000 Advanced Server SP3.
See ME908355, ME917463 and ME926642 for additional information about this event.
When using IAS for RADIUS authentication in an EAP / 802.1X setup, if you are using MD5-Challenge or MD5-CHAP as your supplicant's EAP Type, look for a corresponding System Event ID 2 from source IAS. Active Directory requires a Password Policy change to enable reversibly encrypted passwords for the specified user account.
I received this error while trying to install an Exchange 2003 to coexist with an Exchange 5.5 site. The problem was caused by a missing C$ Administrative Share. The share was removed as part of the security configuration of the server. Adding the C$ share back resolved the problem.
This event record indicates that a logon attempt was made and rejected for some reason other than those covered by explicit audit records. See MSW2KDB for more details.
This problem may occur if Exchange Server 2003 is installed on a computer that is running Windows 2000 Server Service Pack 3 and the Exchange Server 2003 computer is heavily loaded. See ME817310 and ME318922 for more details.
From a newsgroup post: "The 537 event is common when Kerberos fails. The operation will not necessarily fail, as the Kerberos failure might be followed immediately by a successful NTLM logon (look up "SNEGO" on MSDN to see how we try Kerberos first, then NTLM, for many authentication operations).
There are two likely reasons why this occurred:
1) No explicit Kerberos trust between the domain containing the machine doing the accessing and the domain containing the machine being accessed; in other words only an external trust or no trust between the domains.
2) The SPN for the target machine was unavailable to the requesting machine, at the time of the request. This could be due to a lack of routing hints on the trust, or due to the absence of the SPN in the directory. The SETSPN utility in the Windows 2000 Resource Kit can be used to see if the SPN is in place, and to re-register it if not (SETSPN.EXE -L COMPUTERNAME)".
From a newsgroup post: "If you are using protocol transition, this means you have to satisfy the following requirements:
1) The Domain must be in Windows 2003 native mode.
2) Act as part of operating system (TCB) privilege has to be granted to the process that calls “WindowsIdentity” on the front-end machine (where the code runs) and not on the domain controller. Please see the Kerberos protocol transition whitepaper for more details on these requirements".
- Error code: 0xC000006D - From a newsgroup post: "Generally speaking, status code 0xC000006D means "STATUS_LOGON_FAILURE, the attempted logon is invalid. This is either due to bad username or authentication information. Status code 0xC0000133 means STATUS_TIME_DIFFERENCE_AT_DC. The problem could be caused because there is a time difference (greater than 5 minutes) between the two computers. Can you logon the domain from this workstation or can you access the network sharing from this workstation? Please go to the workstations and check the time settings. If you can successfully logon to the domain from the workstations and access the network resources, you can ignore this event message.
I would like to suggest you go to the SBS 2003 server and check the time service status. Open “Services” console in “Administrative Tools”. Double-click “Windows Time” service. If the time service is disabled, please follow the steps below to start the services:
1. Open Services console in “Administrative Tools”.
2. Double-click Windows Time service. Change the startup type from Disabled to Automatic.
3. Open Registry editor (regedit); navigate to the following registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\. Double-click “Type” value in the right panel. Change the value data from NoSync to NT5DS.
4. Go to the service console, double-click the Windows Time service, and click “Start” button to start the service.
5. Check the settings on the firewall (router or ISA firewall). Make sure that outgoing UDP 123 port request is allowed. The SBS server will use this port to synchronize the time with an external time source (on the Internet).
6. This problem can also occur if the Time service is not started on the client computers or the clients are pointing to the wrong timeserver for sync. By default, it should be the SBS 2K3 server.
For a Windows XP computer, you should run the following at a command prompt:
“w32tm /monitor /computers:localhost”.
ICMP: 0ms delay.
NTP: +0.0000000s offset from local clock
RefID: ntdev-dc-10.ntdev.microsoft.com [x.x.x.x]
The computer returned on the RefID line is the timeserver with whom the client is synchronizing its time.
For a Windows 2000 computer you should run the following at a command prompt:
w32tm -v –once.
In the output, search for the following lines:
NTP: ntpptrs  - <IP address>
PORT pinging to -123
Connecting to "\\<fqdn>" (IP address).
The "Connecting to" line gives you fully qualified domain name and IP address of the SBS server that is providing time synchronization. It also provides the port (123) that the Windows Time Service is utilizing. You can find more information by reading ME314054".
This problem might also be caused by a “loopback check” security feature that is designed to help prevent reflection attacks on your computer. This feature was introduced in Windows XP SP2 and Windows Server 2003 SP1. Read ME896861 for information on resolving this problem.
See MSW2KDB for additional information on this event.
I had this problem on one of the Win2k Domain Controllers in a remote office. It turns out that although the time on the DC was correct, the date was wrong. This caused Kerberos authentication to fail. Correcting the date solved the problem.
In my case the Netlogon Service and LSA were disabled by a hardware profile. Getting a default HW profile solved the issue.
I had this problem because the time on the other DCs was not sync with the PDC.
If the "Logon Failure Auditing" local policy is in use on a Windows XP-based computer that is a member of a domain, the following entry may be recorded in the Security event log if you log on to the local computer instead of to the domain. See ME327889.
This may occur if a a forged SID is used to elevates one privileges. See ME289243 for Windows 2000 and ME289246 for Windows NT.
From a newsgroup post: "I am running a W2K active directory domain in native mode. I have both W2K and NT clients and I noticed lots of event id 537 in the Security event log. I have followed the steps by MS that suggests in ME262177 to enable Kerberos logging to pinpoint the errors. What I found is that these errors relate to the NTLM 2 security protocol. Basically the computer account tries to use NTLM 2, if not successfull that it uses NTLM then just LM. Mainly for downlevel clients. The error event ID 537, source Kerberos, is just basically indicating that the NTLM 2 failed, therefore creating the event in the log.
To resolve these errors in the event log you must first follow the steps in ME262177 to turn on Kerberos event logging. Once done restart the computer then view your event log. You can now match up the kerberos detailed error with one in ME230476 which can help you pinpoint the issue. What I have found is that most of this is due to down level client not being able to use Kerberos. The quick resolution is to enable NTLM authentication for all clients.
In my case this event was generated by a logon failure due to the NetLogon component not being active.
One scenario as per Microsoft: "There is a Windows NT server with the same name as the Windows NT FPNW server service name on your network. This FPNW service name must be different than the regular Windows NT server name". See ME145828.
Also they mention this event in ME289243: "Forged SID Could Result in Elevated Privileges in Windows 2000".
You may want to read ME174073 for Auditing User Authentication related information.
|Private comment: Subscribers only. See example of private comment|
|Links: Online Analysis of Security Event Log, Securing Windows 2000 Server - Auditing and Intrusion Detection, SNEGO on MSDN, Kerberos Protocol Transition Whitepaper, Event ID 2 from source IAS, Tracking Logon and Logoff Activity in Windows 2000|
|Search: Google - Bing - Microsoft - Yahoo - EventID.Net Queue (2) - More links...|
|Custom search for *****: Google - Bing - Microsoft - Yahoo|
Send comments or solutions
- Notify me when updated