Windows Forum

Ask something
Discussion Locked

NT Domain problems

0 helpful
19 replies

by joshg 1 view

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

We have 5 offices connected to our main office via varying speed T1's. Each office has its own Domain and Exchange server. I have setup two way trusts with all domains. We use the lines for Internet and Exchange. This morning two of the remote domains started experiencing problems logging into Proxy. The log files on the proxy server show no domain controller available to validate logon. So I Ping the DC's of the two domains, that works. I ping the NetBIOS name of the DC's, that works. I verify that I have WINS working and that the DC shows in the cache. When I pull up the Trust Relationship box it says unable to find DC. I can connect to that domain and transfer files and verify backups worked etc. just cant get Inet access working. They can however connect using an account from another domain. I have event ID's of 5719, 537, and 100. I can't find anything conclusive.

Servers are NT4.0 SP6a, Proxy 2.0 SP1, IIS4.0, Exchange 5.5 SP4

19 replies

by don christner

Josh, you should checkout Q150737 which is suggested from Q150520. I don't know if this is your problem or not, but it sounds like it could be.

Don

by stillatit

It is the Proxy server which cannot find the DC, so hopefully you did the ping and other tests on the Proxy server.

The number one question is "What changed?" If it worked yesterday, something in the mix changed overnight. You might want to checklogs on all DC's.

One of the things which may have changed is someone from another site is visiting your site with a laptop. If they plug into your network, they may become the browse master for their domain on your segment. This would mask theDC as a controller. To avoid this and similar problems, put entries for all DC's in the LMHOSTS file on the Proxy server (and for that matter, on the DC's). The entries should all use the #PRE and #DOM: tags. This should cause validation requests to go to the right place, even if the browse system is messed up.

Also check that all of the boxes involved are actually using WINS. If you are using multiple WINS servers, check the replication.

Good luck.

by joshg

Here's how it shook out. The day before this happended I was bringing another office online with the WAN. I couldn't get the WINS to replicate without the Trust working. So I put the WINS\Proxy servers name in the remote WINS static cache. Everything worked then. The problem was that when the replication started it sent that static addr back to the WINS\Proxy box and caused a duplicate name on the network. This disabled authentication to the DC's. So no Trusts will work. (this is why I give credit to Brian) I traced the duplicate name back to that remote office's cache, then deleted it. I then dumped the WINS cache at the WINS\PROXY box and let replication start agian. After that was resolved, a reboot allowed the machine to communicate with the DC's again. Still no logon by the remote sites through Proxy yet. (now I give credit to MTEFF) I broke the trusts with the two remote sites and rebuilt. Everyones happy again, end of story.

by brianbarber

This is by no means a complete answer, but force a synchronization for all domain controllers from Server Manager and look for errors. This should also confirm connectivity, refresh caches, etc. Also check to see that you can access the Netlogon share on every DC, just to ensure that everything is accessible.

It might also be time to re-index and compress your WINS database.

Post your progress and I'll watch for your answers.

BB

by mteff

Windows NT 4.0 Trust Relationships are not the most sturdy thing in the world. I'd try to rebuild the trusts, during off hours if possible. I have seen a simple change to a WINS entry to cause the trust relationship between domains to break. Having them come across the internet, probably would increase that chance greatly. Just a suggestion.

by cstaunton

check your proxy configuration. in IE5 it is tools>internet options>connections>lan settings and check to see if script path is correct. Also make sure the proxy address and port are set correctly. Good luck!

by joshg

The users can get to the proxy okay. The proxy however cannot pass the logon request back to the Trust.

by m.s.khalid

Please see that you are receiving the ipaddress propely that is when u release and renew it in winipcf or ipconfig the ip address should renew automaically if not check the configuration of the winproxy wheather it is getting external ip properly it think it may solve the problem

khalid

by joshg

The addresses are registered correctly in WINS, the user can ping by name and IP.

by m.s.khalid

It is the Proxy server which cannot find the DC, so hopefully you did the ping and other tests on the Proxy server.

The number one question is "What changed?" If it worked yesterday, something in the mix changed overnight. You might want to check logs on all DC's.

One of the things which may have changed is someone from another site is visiting your site with a laptop. If they plug into your network, they may become the browse master for their domain on your segment. This would mask theDC as a controller. To avoid this and similar problems, put entries for all DC's in the LMHOSTS file on the Proxy server (and for that matter, on the DC's). The entries should all use the #PRE and #DOM: tags. This should cause validation requests togo to the right place, even if the browse system is messed up.

by joshg

From my browser this is an identical answer as Stillatit's. I am giving the credit to the earliest repsonse.

by johnscrooby

This is also by no means a solution, but i had a similar problem with trusts not able to find the DC. I worked around it bu adding host information to the host file depicting the DCs in each domain. I can for the life of me remember the cmd line butiwas something like PRE_domainName or something - Check the support base for the exact lines.

by toliveri

We have problems with domain trusts every once in a while. An alternative to breaking and re-creating the trusts is to use the NETDOM command in the NT resource kit. With it you can check trust realtionships as well as the secure channels between your PDC's and BDC's. You can even reset the relationships from a command prompt with no disruptions. Use the NETDOM HELP to get the syntax for the commands. You can also lookup NETDOM in technet or in the knowledge base for more info.

This discussion is closed to new replies.