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 runnin...
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.
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.