Forum Discussion
Event 4625 status 0xC000035B on Server 2022
Hi all,
Two Windows Server 2022's running Exchange Server 2019 (latest patches) in a DAG .
Every 30 seconds or so we are getting event 4625 (as below) on both servers. The servers are running fine, Exchange is running fine.
An account failed to log on.
Subject:
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0
Logon Type: 3
Account For Which Logon Failed:
Security ID: NULL SID
Account Name:
Account Domain: -
Failure Information:
Failure Reason: An Error occured during Logon.
Status: 0xC000035B
Sub Status: 0x0
Process Information:
Caller Process ID: 0x0
Caller Process Name: -
Network Information:
Workstation Name: -
Source Network Address:127.0.0.1
Source Port: 55161
Detailed Authentication Information:
Logon Process: Kerberos
Authentication Package: Kerberos
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
I have searched this error but can't find anything with the same Status 0xC000035B. I assume it is something on the server itself judging by the source address but am unsure what. Does anyone have an idea what it could be?
FYI LMCompatibility is set to 3.
thanks
jc
2 Replies
@ I found this which is a possible explanation. This is an unverified source though. Running netstat, the connections that show in the events are listed as owned by PID 0. Perhaps one of those messages that doesn't mean anything and can be safely ignored.
https://stackoverflow.com/questions/22802847/tcp-connection-owned-by-pid-zero
- Loopback Connections (127.0.0.1):
The event shows a source network address of 127.0.0.1, indicating that the failed logon attempt is coming from the local server. This could suggest an issue with a service or scheduled task on the server trying to authenticate locally and failing.
Kerberos and DNS Issues:
Check DNS Configuration: Ensure that the DNS settings on the servers are correct and that the servers can resolve their own names and the names of domain controllers properly.
Service Principal Names (SPNs): Make sure that the SPNs for Exchange services are correctly registered in Active Directory. You can use the setspn -L <servername> command to list the SPNs for a given server.
Kerberos Delegation:
Verify if any Kerberos delegation is configured and ensure it is set up correctly. Misconfigured delegation can cause Kerberos failures.
Network Load Balancers: If you're using a load balancer, ensure it’s configured correctly for Kerberos. Improper configurations can lead to such failures.
Check Event Logs:
Review related logs on both the Exchange servers and the domain controllers to find additional clues. You might find corresponding Kerberos errors that can give more context.
Network Policy Server (NPS) or RADIUS Configuration:
If you are using NPS or a RADIUS server, check if they are configured to authenticate using Kerberos and verify that the server’s trust relationship is correctly established.
Review Scheduled Tasks and Services:
Since the event occurs every 30 seconds, it might be tied to a scheduled task or a service running on the server. Review scheduled tasks, services, or any background processes that might be attempting to authenticate.
LMCompatibility Setting:
Your LMCompatibility level is set to 3, which enforces NTLMv2 session security if negotiated. Ensure that this is consistent across all your servers and that there isn’t a mismatch causing the authentication issue.
If after checking these potential causes the issue persists, you may want to enable more detailed logging or use tools like NetMon or Wireshark to capture and analyze network traffic, focusing on Kerberos authentication attempts.
