Ghost trust object caused the network share inaccessible

A while back we got involved in a weird issue where a network user encountered network share access problems. The symptom or the error message might be different in some scenarios:

1. Domain controller’s share folders cannot be accessed by the NETBIOS name, but the folders can be accessed by the IP address several times.

2. The access to the \\servername\ could be succeeded, but the error message will be shown if to access the shared folder under it, such as \\servername\netlogon or \\servernam\sysvol.

3. \\machinename\folder is not accessible, the message says that you might not have permission to use this network resource. Contact the Administrator of this server to find out if you have access permission. Configuration information could not be read from the domain controller, either because the machine is unavailable, or access has been denied. See the below screen capture.

When the problem happens, we always get the following error message:

"LSASRV EVENT ID:32772 The interdomain trust account for the domain <Domain> could not be created."

This "LSASRV EVENT ID: 32772 message would be a good hint to help us narrow down the issue and figure out the root cause. At this moment, when opening the “Active Directory Domains and Trusts”, we can see there is an invalid trust existing and the trust was created to setup trust with the DC itself, which is abnormal behavior.

Unfortunately, when trying to delete the trust object from trust list, there will be error showing as “An internal error occurred” or “the directory service is busy”. We have to go to Adsiedit.msc console to delete the trust object directly:

CN=<Trusted/Trusting Domain NETBIOS name>,CN=system,DC=Domainname,DC=com

After deleting the invalid trust objects and restarting the domain controllers, the Drive mapping and the share folder can be accessed by the machine NETBIOS name turn to be successful.

NOTE: After removing the trust object, it is recommended to restart all domain controllers within the domain. If not , the trust list is not consistent throughout the domain controllers. Some domain controllers UI reported the trusts were there but “nltest /domain_trusts” returned the correct result. So the restart of all the domain controllers after the removal operation will purge the netlogon trust list cache. It is also recommended to restart the problematic clients to make the changes effective.