I'm having a really strange issue.

I have 2 domains, we'll call them A and B.

There is a two way trust set up, A trusts B and vice-versa.

Clients in domain B are having trouble accessing shares on two servers in domain A. I have ~40 servers in this environment, and these two seem to be the only ones having the issue.

I get an error message that the server cannot be accessed, there are no logon servers available to service the login request.

They can access other servers fine, even ones in the same subnet. pinging the domain name returns the IP for the closest DC, and nslookups work fine for both the servers in question, and the domain name.

Both of the problem servers are Server 2003. The domains are 2000 functional level. The trust seems to be intact, as they can access shares on other servers.

I really appreciate any ideas!

  • Something to test. While logged into Domain A as a domain admin, go to one of the problem servers and then to the comp management and then users and groups. Create a group called "TEST". Now try to add a user from Domain B to the TEST group. Does it work and resolve their name? Also look at the existing share/NTFS permissions...does it resolve their names there or are they showing as UNKNOWN SIDS? And of course, check the event logs and the security logs on the problem server. – TheCleaner Jul 29 '11 at 14:19
  • @TheCleaner They are showing unknown SIDS, good catch! The event logs look clean. What would cause them to not resolve the SID for the other domain? They can ping the FQDN for the other domain, and it resolves with an nslookup. – Mike Morris Jul 29 '11 at 14:37
  • I had the same thing happen once. It turned out that the replication between the domain controllers within the domain, in your case domain A, was the problem. Verify the trust first (in AD Trusts) and then verify with repladmin and dcdiag in Domain A that everything is working ok within that domain. Somehow everything continued to work within Domain A, but Domain B couldn't access it anymore. Once we cleared up the replication issues within Domain A everything was fine again. – TheCleaner Jul 29 '11 at 21:09

I know this is a very rudimentary answer/idea, but have you tried "bouncing" the two servers that are having issues? What I mean is, remove them from the domain to a workgroup, reboot, put them back on the domain, reboot? If you have ~40 servers in environment A that are working flawlessly with workstations in B, then I wouldn't considering futzing with major configuration changes until you have to.

  • disjoining and rejoining the domain is not a step I would undertake or recommend unless I had pretty strong evidence that that would resolve the issue, such as a corrupted trust relationship between the server and the domain. – joeqwerty Jul 29 '11 at 14:08
  • I agree. :) But - two servers out of 40 is generally indicative of something (corrupted trust, etc), is it not? I'm asking as a general question, not to be contentious. :) – Mountainerd Jul 29 '11 at 14:14
  • It's indicative of something, but disjoining and rejoining the domain smacks of a pretty radical step to take without supporting evidence that that's what the problem is. It's analogous to using a sledge hammer to drive in a push pin. I'm assuming that the clients in the same domain don't have issues with these 2 servers and that the issue only manifests itself when users from the trusted domain try to access them, which might point to a borked domain trust. – joeqwerty Jul 29 '11 at 14:22
  • bows in deference – Mountainerd Jul 29 '11 at 14:32
  • I haven't tried bouncing them yet, as they're in production for a large ERP system. I'd need to schedule the downtime, even for a reboot. I don't know that I'd want to disjoin them from the domain at this point. Possibly as a last resort, but I think it's a bit premature. – Mike Morris Jul 29 '11 at 14:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.