Event ID 1309 ASP.NET 4.0.30319.0 Warning

wwwillster07

New Member
Joined
Oct 3, 2023
I see a lot of talk online with this particular event id relating to Exchange. This is not an Exchange server. It's an IIS server running a web page for an inhouse application.

I don't really know how to debug it. It only happens very randomly and I'm unsure of the catalyst so far. One thing I'm 100% certain of and that is there is no trust relationship error on this server with the domain, but that seems to be the focus based on this error ASP.Net is spitting out, though I wouldn't be surprised when it happens that there's a communication problem with the DC....

I'm just at a loss how to troubleshoot it further. The development team states there is no changes to the code in the last 2 years so if this issue just started 5 months ago out of nowhere it's got to be the server. Can't argue that logic right?

Event code: 3005 Event message: An unhandled exception has occurred. Event time: 9/27/2023 8:45:46 AM Event time (UTC): 9/27/2023 12:45:46 PM Event ID: 3f6529ce78f1489fb1392a78c510954b
Event sequence: 3922 Event occurrence: 1 Event detail code: 0 Application information:
Application domain: /LM/W3SVC/2/ROOT-1-133402281845197659 Trust level: Full
Application Virtual Path: / Application Path: C:\WebSites\ImageClearing\ Machine name: BFXP8 Process information:
Process ID: 3856 Process name: w3wp.exe Account name: DOM\serivceacct
Exception information:
Exception type: SystemException
Exception message: The trust relationship between this workstation and the primary domain failed.

at System.Security.Principal.NTAccount.TranslateToSids(IdentityReferenceCollection sourceAccounts, Boolean& someFailed)
at System.Security.Principal.NTAccount.Translate(IdentityReferenceCollection sourceAccounts, Type targetType, Boolean forceSuccess)
at System.Security.Principal.WindowsPrincipal.IsInRole(String role)
at System.Web.Configuration.AuthorizationRule.IsTheUserInAnyRole(StringCollection roles, IPrincipal principal)
at System.Web.Configuration.AuthorizationRule.IsUserAllowed(IPrincipal user, String verb)
at System.Web.Configuration.AuthorizationRuleCollection.IsUserAllowed(IPrincipal user, String verb)
at System.Web.Security.UrlAuthorizationModule.OnEnter(Object source, EventArgs eventArgs)
at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step)
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Request information: Request URL: http://dst-bfxp8.dst.local/AMP/X9BrowseDocument.aspx?M=Home
Request path: /AMP/X9BrowseDocument.aspx User host address: 10.22.38.6 User: DOM\FOD0134 Is authenticated: True
Authentication Type: Negotiate Thread account name: DOM\Serviceacct Thread information: Thread ID: 39 Thread account name: DOM\Serviceacct Is impersonating: False

Stack trace: at System.Security.Principal.NTAccount.TranslateToSids(IdentityReferenceCollection sourceAccounts, Boolean& someFailed)
at System.Security.Principal.NTAccount.Translate(IdentityReferenceCollection sourceAccounts, Type targetType, Boolean forceSuccess)
at System.Security.Principal.WindowsPrincipal.IsInRole(String role)
at System.Web.Configuration.AuthorizationRule.IsTheUserInAnyRole(StringCollection roles, IPrincipal principal)
at System.Web.Configuration.AuthorizationRule.IsUserAllowed(IPrincipal user, String verb)
at System.Web.Configuration.AuthorizationRuleCollection.IsUserAllowed(IPrincipal user, String verb)
at System.Web.Security.UrlAuthorizationModule.OnEnter(Object source, EventArgs eventArgs) at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step) at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
 
Based on the information provided, it seems that the issue you are experiencing is related to a trust relationship problem between the server and the domain. This error usually occurs when the server is unable to authenticate with the domain controller.

Here are a few troubleshooting steps you can try:

1. Verify the server's trust relationship: Ensure that the server's trust relationship with the domain is intact. You mentioned that there is no trust relationship error, but it may still be worth checking. You can remove the server from the domain and rejoin it to test if that resolves the issue.

2. Check network connectivity: Make sure there is no network issue between the server and the domain controller. Test the network connectivity using tools like ping and tracert. Verify that the server can successfully communicate with the domain controller.

3. Verify DNS configuration: Ensure that the server's DNS settings are correct and that it can resolve the domain controller's hostname. Check the DNS settings on the server and make sure they point to the correct DNS server.

4. Review security settings: Review the security settings on the server to ensure there are no misconfigurations or conflicts that could cause authentication issues. Check the local security policies, group membership, and any other security-related settings.

5. Check event logs: Examine the event logs on both the server and the domain controller for any related errors or warnings. Look for authentication failures, trust relationship errors, or any other clues that could help identify the root cause.

6. Update/reinstall .NET framework: If the issue persists, consider updating or reinstalling the .NET Framework on the server. It's possible that there could be a compatibility issue or a corrupted installation causing the error.

If these steps do not resolve the issue, it may be helpful to engage your system administrator or IT support team to further diagnose and troubleshoot the problem. They may have additional insights or access to resources that can assist with resolving the trust relationship error.
 
This is most likely the problem.

Exception message: The trust relationship between this workstation and the primary domain failed.

Run the following powershell command to verify the issue
Code:
# Test for trust relationship issue
Test-ComputerSecureChannel

# Fix trust relationship
Test-ComputerSecureChannel -Repair
 
Test-ComputerSecureChannel comes back true all the time, even while the issue is happening. I'm debug logging in the netlogon log there's no issue with the trust. There are no security audit failures pointing to a trust relationship error. There's no NTP errors in the system log which are indicative of a trust relationship problem. In fact, trust relationship errors do not fix themselves, and once that trust is broken it needs to be manually fixed, and the only really successful way is to remove it from the domain and add it back. This has never needed to happen so it's not a trust relationship error. Now it may be some sort of communication with the DC is randomly failing for a short period of time, and ASP.Net is just spitting out a generic error, but this happens so rarely they may just deal with it for the time being and I'll roll out a new server before year end.
 
That command will fix a trust relationship without removing the device, but if it comes back true then I would agree there's probably another issue. Also not a lot to go on from one error. How about adding any steps you've already taken to troubleshoot?
 
If you haven't already grab the LDP tool from Microsoft and test binding with the service account with the same authentication type in iis
 
Back
Top Bottom