DC From Remote Site Can't Authenticate to DC at Main Site

C

calvinj

[H]ard|Gawd
Joined
Mar 2, 2009
Messages
1,738
Anybody ran into this before?

Remote DC:
This computer could not authenticate with \\dc1.domain.local, a Windows domain controller for domain DOMAIN, and therefore this computer might deny logon requests. This inability to authenticate might be caused by another computer on the same network using the same name or the password for this computer account is not recognized. If this message appears again, contact your system administrator.
Click to expand...

Local DC:
The session setup from the computer Site-DC1 failed to authenticate. The name(s) of the account(s) referenced in the security database is Site-DC1$. The following error occurred:
Access is denied.
Click to expand...

I've seen this with computers that can't talk to the DC. You just disjoin then and rejoin them to the domain all is happy. But beings this is a DC, not sure what else to do with it. I've tried to disjoin it, but it will not release a DNS role to save it's life and thus will not demote. I've contemplated a force removal of the DC and then getting it back, but not sure what affect it will have at that site. This server performs DHCP and WSUS along with it's AD roles (AD, AD DNS), but we do have another dc out there that is also performing AD roles.

The server its up to date with AD, DNS and other information, but I'd have to venture a guess that it's getting those from the 2nd DC out there
 
What Windows Server version, and what are the forest and domain functional levels?

Any time differences between your remote DC and local DC? Where is the NTP?
 
you using DHCP if so change the DNS server ip address to the Ip address of the other DC and try again.
 
Remote DC - Server 08 R2
Main DC - Server 08

Domain and Forest are set at 08. Not sure what you are asking by NTP.
But the Main DC is in the CST time zone and the Remote DC is PST.
 
Assuming this is through a VPN tunnel?
How long have they been...joined at the hips? Can you look back through time and see if replication was good or not? If they haven't properly replicated in a long time...you'll end up with a DNS island that has become stale. Were they properly defined in AD sites 'n services as two different networks? (this is important..can impact replication..makes a big difference)

What exactly is the remote DC using for DNS?
 
YeOldeStonecat said:
Assuming this is through a VPN tunnel?
How long have they been...joined at the hips? Can you look back through time and see if replication was good or not? If they haven't properly replicated in a long time...you'll end up with a DNS island that has become stale. Were they properly defined in AD sites 'n services as two different networks? (this is important..can impact replication..makes a big difference)

What exactly is the remote DC using for DNS?
Click to expand...

This was originally setup over a site to site vpn and lately have been over a Point to Point MPLS connection.

They have been joined to the hips for the last year and seemed to be working fine. I'm sifting back through the event logs now and seeing if I can figure out when and where it happened. Site's and Services are setup properly and I can see that the 2 dcs in the remote site are part of that site in AD and so on. The only thing I changed recently is to turn up the replication on AD from 4-5 times in a 24 hour period to more like 8 times in a 24 hour period.

Any way of forcing this DC to pick back up again?
 
Sifted through the event logs and this started happening early Oct. Looked through the Calendar and such and nothing really happened in early Oct. Our MPLS didn't get installed until late Oct.
 
There's repadmin /replicate
http://technet.microsoft.com/en-us/library/cc742152(WS.10).aspx

..but before rushing into things...I'd want to dig into nooks 'n crannies quite a bit more.

Any changes to the tunnel..or how the site to site is setup? Can you verify full communications between the two DC's otherwise?

What even viewer entries do you get if you go into AD sites' n services...servers, ntds, right click 'n replicate in both directions...doing this on both servers?

And just confirming on what DNS settings each DC is using? I've seen that get changed due to <whatever>...and break things.
 
Well I've already sifted through DNS and noticed some things I did wrong (IE: Not having zone transfers turned on for the remote DCs), Those changes were made recently however.

Both DC's can ping each other back and forth, not sure if that really counts or not.

The MPLS really is point to point. Nothing special. I would describe it as one line ass piece of fiber connecting us from our HQ to the remote location.

EDIT:

Just issued the repadmin /replicate command on both DCs to attempt to sync each other & it reported no errors.
 
Last edited:
I meant in TCP/IP settings...what is each using for DNS?
Getting replies from pings to each other doesn't really help all that much...as local DNS records of static objects will still be...accurate.
I think the you'll find where to look a bit more as you sift through the tedious amounts of event logs....but it's a necessary evil.
 
Oh for DNS.

Main site DC:
1st DNS: Itself
2nd DNS: the other DC is this site

Remote DC:
1st DNS: Itself
2nd DNS: the other DC is this site
 
How about in AD sites 'n services...on each DC...when you right click in ntds and replication in both directions on each? And then run over to event viewer after doing that to see if any reds?
 
This is what is strange to me.. AD seems to be ok. I don't see any errors when i force replicate between the 2 dc's that are giving the errors in the OP
 
If you add a "test" user on one DC...does it appear in ADUC on the other DC within a reasonable time?
 
I've run into a similar issue before, but I'm not totally sure it's the same fix so be careful before doing this.

Basically the tombstone lifetime had passed and the remote DC was no issuing its own credentials. THis meant that they could not talk anymore cause they couldn't agree on usernames and passwords.

To fix I had to turn off kerberos key issuing on the remote DC and then restart the machine and then force a replication. This got them replicating again.

A way to test to see if this is the case is to create a user on the main DC and see if it replaces across after a forced replication. If not, the DCs are not talking and not replicating and you may need to reset replication.
 
If you go into DNS MMC on each DC..drill down into the forward lookup zone, there is a Host (A) record for each DC pointing to the correct IP address? (going to assume yes..since it appears to find it, just won't authenticate)
 
Glad to see I'm not the only one banging my head on the desk with this.. Created a new user on the main dc1 at the main site. I forced replication between the main dc and the remote dc1 and the test users shows up. For shits and giggles I deleted the new test user in on the remote dc and forced a replication between the remote dc and the main dc and the user disappears as expected.
 
You must log in or register to reply here.
Back
Top