VERY URGENT: Remote offices can't find Domain Controllers at headquarters.

Hi,

I have a client with the following details:

2 DC 2003 at the headquarters.
Several remote offices with XP workstations and NT4 File & Print servers (Remote offices at different subnets from the headquarters).

Every service and workstation is working correctly at the headquarters, they can contact the DCs, DNS and WINS, but none of the remote office machines can authenticate at  the domain controllers from the headquarters, as a consequence, no services provided by the NT4 servers are available, and XP machines are login on with cached credentials only.

All tcp-ip communications to the DCs, DNS, and Wins servers at the headquarters are available, any machine from the remote offices is able to ping these servers at the headquarters.

This network made an upgrade from NT4 domain to 2003 on the last weekend, I can't confirm the remote offices were able to log on to the upgraded 2003 DCs at the headquarters after the upgrade, or if they have been login on with cached credentials since.

Someone tells me that they did manage to log on to the File & Print NT4 servers from the remote offices since the upgrade before these problems, but since It wasn't me, I'm not absolutely sure that is true. If that was true, and since NT4 doens't keep the credentials in cache as far as I know, this would confirm that they were previously able to contact the 2003 DCs at the headquarters.

I can't be sure the customer hasn't done any changes to the routers also.

Any thoughts?
MenshenAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Walter PadrónCommented:
Make sure you permit ports 88 and 445 on your routers.

Do you have DCs on those branch offices?
0
JacquesKrugerCommented:
Hi,

I'm not at all sure why you can't authenticate, but I suggest that you have a look at the DNS setup. Make sure that the one of the following scenarios are applicable

     - All PC's have only the domain controllers as DNS servers,
     - You set up the NT servers as slave DNS servers and point each subnet to its local NT server. I'd guess this would be the better implementation as there would be less traffic across the WAN link.

Check the service pack level of the NT servers. I'm not sure if NT servers cannot participate in a 2003 domain at all or if it needs a specific service pack. Check it out, it may point you into a direction.

Lastly, if you don't mind sacrificing your domain functional level and you can actually (see previous) join an NT server to the domain, why don't you make them BDCs and use domain replication to have the logon occur locally? Then you'd have some rdundancy as well.

Good Luck

Jacques
0
MenshenAuthor Commented:
Hi, there are no DCs at the remote offices, except for one which still has a NT4 BDC, but the machines at this site are experiencing exactly the same problems as the others, which makes sense to me because of some info I read recently, according to it, XP machines after an upgrade, will only log on in active directory, they will never use NT DCs again... So this could be seen as a confirmation that this XP machines were able to log on to the 2003 AD after de upgrade, but now, although they can't contact the AD, they will not use the local NT4 BDC in according to taht info.

I also learned that all the remote offices enter the headquarters through the same router... That could defintly be a point of failure.

Regarding communications, I could ping servers at the headquarters from the remote offices, I can Even VNC and Remote Desktop to worktations at remote offices from the headquarters...

I don't know routers, but maybe this one is affecting traffic regarding authentication somehow?
0
Cloud Class® Course: Amazon Web Services - Basic

Are you thinking about creating an Amazon Web Services account for your business? Not sure where to start? In this course you’ll get an overview of the history of AWS and take a tour of their user interface.

MenshenAuthor Commented:
JacquesKruger...

All PCs, have only the DCs at the headquarters as their DNS and WINS servers, all NT4 machines have SP6, but notice that they are only member servers, the XP machines at the remote offices authenticate only at the headquarters, and they also are not able to do it.
0
Walter PadrónCommented:
Menshen, IF your users at headquarters can authenticate AND your remote users don't AND all remote traffic comes through the central router THEN in my opinion this one is affecting authentication traffic.

If you can't access the router you can make a fool proof of this, using a laptop test that you can logon at the headquarters and then test that you can't logon at the remote office, or viceversa.

If the router is a Cisco device i can help you too, let me know.
0
MenshenAuthor Commented:
Some more details...

The following errors are from a XP machine on monday, after the user logged on for the first time on the upgraded domain:

Event ID 3224

Source: Netlogon

Changing machine account password for account COMPUTER failed with the following error:
There are currently no logon servers available to service the logon request.

Event ID 28

Source W32Time

The time provider NtpClient is configured to acquire time from one or more time sources, however none of the sources are accessible. NtpClient has no source of accurate time.

This could indicate that the machines from the remote offices are having trouble locating the 2003 DCs since the upgrade was done, but this is not happening with the machines at the headquarters.

Previously this was an NT4 domain with two DCs at the headquarters. The WINS servers were the DCs, and there was no DNS.
During the upgrade I configured DNS at the DNS and maintained the WINS servers, so the only new info the heardquarter and remote machines had, was a new DNS server.
0
fnbgpplCommented:
Check to make sure that they are pointing to the proper gateway.
0
MenshenAuthor Commented:
Also... There is still a live NT4 BDC at the headquarters from the domain before the upgrade was done (this was left up because it is also a proxy server), so if for some reason the remote XP machines were not able to log on to the 2003 DCs, they woudl have this one available... Honestly I feel a bit lost.
0
MenshenAuthor Commented:
fnbgppl ... They are
0
Walter PadrónCommented:
Event ID 3224 Source: Netlogon

"The security database on the server does not have a computer account for this workstation trust relationship" - I received this error on a number of servers and Windows XP machines. This problem occurred when I upgraded a NT4 PDC to a 2K server. Somehow, the security records on the PDC and BDC had got out of sync. My solution was to remove the offending PC from the domain, remove its account from both the 2K server (acting as a PDC) and from the BDC. I waited 15 minutes for all the updates to filter through and then rejoined the domain.



Try to remove/rejoin a workstation in a remote office, logon and check for errors
0
MenshenAuthor Commented:
wpadron, I asked one of the technicians from the client to delete one of the accounts, and recreate it a few hours ago, I know now he didn't wait enought time to ensure that operation was replicated between DCs before creating it again. I will have to retry it tomorrow morning.
0
JacquesKrugerCommented:
Hi,

Have you tried the deleting a computer account and then running a network ID wizard for that machine?
0
MenshenAuthor Commented:
Important... very important detail I noticed. I was bothered by the fact that only machines on other subnets didn't find the server, so I did a test, I installed a 2003 machine and joined it to the domain on the headquarters, and then took it to another subnet and it coulnd't authenticate of find log on servers... This from a machine that was done after the upgrade, and that can log on perfectly once it is returned to the headquarters...

So definitly the problem is from the fact that the machine is on another subnet. And this only became a problem after the upgrade, these same machines on the NT4 were able to log on without problems, and without even a DNS at the remote offices.

So...What do these machines need to contact a 2003 domain controller on another subnet? They have the correct gateway, they have the correct DNS, which is the DC at the headquarters... They even have WINS configured, which is also the DC...
0
davidsummersCommented:
Just a quick question.

Your Machines, do they have any static IP settings.

Any custom entries in the C:\WINDOWS\system32\drivers\etc\hosts file pointing to your DC's?

Also do you have any static WINS entries pointing to DC's.

On your Machines in the remote offices, can they Ping and tracert your 2003 DC's can you run an nslookup on a server and return the name server?

another thing you can try is the following command
nltest sc_query:%Your Domain name%
from one of your workstations, this will test the secure channel between your machine and your domain.

Also, I assume your domain is running in Mixed AD mode and not Native AD mode.

0
MenshenAuthor Commented:
They all have static IP addresses, something that obviously does not please me, I plan to implement DHCP soon.
They have static entries point to the DNS, and WINS servers, which in this case are the DCs at the headquarters.

I can Ping the DCs servers from the machines at the remote offices, I'll have to confirm nslookup queries and your next command in the morning.

The domain is still in mixed mode.

0
davidsummersCommented:
can you ping your workstations from your DC, if so, then you might be able to use a utility called Rclient (Part of the MS windows Resource Kit)

Usage run from a  command line, rsetup \\PCNAME

this will remotely install the remote client service on the workstation. You can then use rclient \\pcname to connect to a command line console on the target machine.

This will then allow you to run diagnostic commands on the remote machine as if you were logged onto it locally. From there you can run your nltest and nslookup commands.

I strongly suspect that your static IP settings are causing the problem, especially WINS.
0
MenshenAuthor Commented:
davidsummers, I'll be looking into it in less than an hour, but I'm not sure WINS is the problem, because the 2003 machine that was done after de upgrade, will use DNS to find domain controllers.

We could consider that the NT4 Servers would still use WINS, and that the XP workstations at the remote sites would also use it they never logged on to the AD, but that specific 2003 machine would use DNS I think.

0
MenshenAuthor Commented:
Additional important Info, I've been given incorrect info by the IT team from the customer, the remote machines, aren't even aware of the upgrade, I can see at the remote XP machines, that their host names are still without the complete extension such as:

pc.localdomain.com

they are still only PC, and the event viewer confirms netlogon errors immediatly after the upgrade to 2003.

So machines on the same subnet are working perfectly on the AD, remote machines are still looking for the NT4 domain. I believe NT4 domain clients from remote offices use WINS to find a DC, and they are still using the WINS address of the old PDC, which is now a the PDC emulator, and WINS. So the IP address to the WINS server is the same, but this is now a 2003 wins ant not NT4
0
MenshenAuthor Commented:
I can confirm that remote machines are able to contact the new DNS and the new WINS server and use it for resolving names.
The domain name is correctly present in the WINS database. Still the the remote machines tell they cannot find the domain.

I did from a remote machine a ping to both of the DC servers:

ping dc01
ping dc02.localdomain.com

I got positive responses to both, I checked my cache with nbtstat -c which shows me now an entry for dc01, I believe this confirms to me that the remote machines can contact and use WINS and DNS, but still they are somehow unable to find the domain...

0
MenshenAuthor Commented:
I was informed that both that ports 88 and 445 are open on the routers, and that no changes were made recently, so tey always allowed remote machines to contact the NT4 servers athe the headquarters to log on.

I have no sites or subnets defined on AD, since I believe this is only needed if you have DCs at the remote offices, and since they don't exist they are not needed
0
MenshenAuthor Commented:
PINPOINTED!!!! It was the god damn router!

I installed a 2003 router and everything worked perfectly!

Now I need to find the correct info to my customer regarding ports and protocols that must be open on the routers to allow 2003 logon traffic. (even though e kept telling me everything was open...)

He has a Cisco7200vxr centrally and cisco 2600 at the remote offices.

Anyone know what needs to be open exactly?
0
Walter PadrónCommented:
Windows 2000 connectivity through firewalls ... or damn routers ;) http://support.microsoft.com/?kbid=280132

If you need help configuring the router let me know.

Good luck
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
MIMIS_ISCommented:
Here you Go:

http://support.microsoft.com/default.aspx?scid=kb;en-us;179442
http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/deploy/confeat/adrepfir.mspx

Computer Login and Authentication

A computer logon to a domain controller uses the following:

• Microsoft-DS traffic (445/tcp, 445/udp)

• Kerberos authentication protocol (88/tcp, 88/udp)

• LDAP ping (389/udp)

• DNS (53/tcp, 53/udp)

D>
0
MenshenAuthor Commented:
Thanks fo the help guys, the points go to wpadron for getting me the info first.

P.S. the problem was in fact with the MTU size of the packets on the router... NT4 accepted authentication even after the router fragmented the packets, 2003 R2 was more sensitive to the change.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Server OS

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.