Event ID 537 Source Security
| Event ID | 537 |
| Source | Security |
| Type | Failure Audit |
| Description | Logon Failure: 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, please! | 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? |
| Comments |
Mihai Andrei
(Last update 7/17/2007): 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 M939682 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 M329938 for a hotfix applicable to Microsoft Windows 2000 Advanced Server SP3. See M908355, M917463 and M926642 for additional information about this event. Jason Hammerschmidt (Last update 4/3/2007): 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. Paul Essick (Last update 2/3/2007): 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. Ionut Marin (Last update 8/19/2005): 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 M817310 and M318922 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”. Command output: localhost [127.0.0.1]: 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: BEGIN: GetSocketForSynch NTP: ntpptrs [0] - <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 M314054". 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 M896861 for information on resolving this problem. See MSW2KDB for additional information on this event. Paul (Last update 3/14/2005): 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. Why bother deciphering Event logs when GFI EventsManager can do everything for you? Free trial here! Robert Sieber (Last update 3/10/2004): In my case the Netlogon Service and LSA were disabled by a hardware profile. Getting a default HW profile solved the issue. Eran Guri (Last update 12/27/2003): I had this problem because the time on the other DCs was not sync with the PDC. JM (Last update 6/4/2003): To resolve these errors in the event log you must first follow the steps in M262177 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 M230476 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. Anonymous (Last update 6/4/2003): This may occur if a a forged SID is used to elevates one privileges. See M289243 for Windows 2000 and M289246 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 M262177 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. Bengt (Last update 6/4/2003): 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 M327889. Adrian Grigorof In my case this event was generated by a logon failure due to the NetLogon component not being active. Sorin Ciulpan 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 M145828. Also they mention this event in M289243: "Forged SID Could Result in Elevated Privileges in Windows 2000". You may want to read M174073 for Auditing User Authentication related information. |
| Links | M145828, M174073, M174074, M230476, M262177, M289243, M289246, M314054, M318922, M327889, M329938, M817310, M896861, M908355, M917463, M926642, M939682, 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, MSW2KDB |
| Search | Google Web - Microsoft Support - Bing - EventID.Net Queue - More links... |
| Custom search | The custom search information is available to subscribers only. |
| Feedback | Send comments - Notify me when updated |
| Print version |