The following issue came up the other day:
Users from a trusting domain could not see shared folders or printers in the trusted domain. Our very first troubleshooting step was to validate the trust which we did and this did not resolve the issue. At that point we knew the issue was going to be more involved.
In our network we have multiple domains trusted to a “main” domain and then we have multiple domain controllers that are geographically dispersed which are optimized using Active Directory Sites and Services.
We performed the basic troubleshooting steps of ping and tracert and determined there was no network issue. We knew the domain trust was working and we verified that name resolution was also working from pc’s in the trusting domain to resolve names in the trusted domain.
The issue became a little bit clearer when I went to the share permissions and didn’t find the users from the trusting domain on the share or ntfs permissions and when attempting to add these users to the share or ntfs permission we got an error message that there was no authentication server found.
We turned on Wireshark and watched the authentication handshake. We could see the traffic go to the server where the shared resource should be, we could see the server then send the authentication check to the nearest domain controller and then the request died. Ah ha. So we logged on to this domain controller and found that the DNS settings on this domain controller had been changed to point to external DNS servers. Fumbled by a rookie administrator. *sigh*
This however brings up a good object lesson. DNS settings on a domain controller are of vital importance. The issue in this case that when the DC received the authentication request it couldn’t send the ack back to the requesting server because it couldn’t resolve the name of the server that made the request.