• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 173
  • Last Modified:

authentication failed after turning off one of DC's

Hello,
My situation:
We have DC in Central Office and 5 DC's in branches. Two days ago we had maintenance works in Central Office and we disabled DC in HQ. After that authentication in branches was failed.
The question is: why?
What i did wrong with installation DC's in branches?

OS WIndows Server 2008 R2
0
Andrey_Gorohov
Asked:
Andrey_Gorohov
  • 5
  • 3
  • 3
  • +1
1 Solution
 
Darius GhassemCommented:
Do you have AD Sites setup? Is the other DCs pointing to themselves for DNS? Are the remove DCs Global Catalogs?
0
 
James HaywoodCommented:
The DC you removed was probably the only Global Catalog in the domain. Enable Branch Office DCs as Global Catalogs

Active Directory Sites and Services
Sites
Select Relevant DC
Right Click NTDS settings
General Tab, check 'Global Catalog'
0
 
Andrey_GorohovAuthor Commented:
yes, we have AD Sites. about DNS i have to check...
they are all has GC role... that's why it's strange for me...
Actualy, i don't think they have to be GC for normal authentication. Authentication should work without GC role on DC.

btw
DC was not removed, it was disabled for some time. And till it was disabled authentication does not worked in branches.
0
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

 
pwindellCommented:
Get the DC back up.
They aren't like other member servers,...you cannot leave them down.   Replication has to be maintained.    If you cross the tombstone period you'll make a mess out of everything.

Shutting down a DC almost always has side-effects.   DCs are not equal and they are not "fault-tolerant".  Apart from the Sites -vs- WAN links situation the main reason for multiple DCs is so that losing one does not lose the AD Database,...it is not so that you can loose one and "transparently" and smootly keep on going,...because that won't happen.   DCs are not "clusters" and they are not "arrays", nor do they act like they are one.
0
 
Andrey_GorohovAuthor Commented:
Replication is OK! DC was down about 10 hours, it is not so big time to destroy replication...
The problem is authentication stoped working at the same time when we turned off one DC in CO...
How to check, where client was authenticated (to get access to some share for example)?
0
 
pwindellCommented:
The command line echo %logonserver%  will show their logon server when you run that from their machine.
0
 
Andrey_GorohovAuthor Commented:
Hm... logonserver is DC in branch...
I din't know what else i have to check... :(
0
 
James HaywoodCommented:
What authentication issues are you having?

Problems logging on?
Exchange/Sharepoint Issues?
0
 
pwindellCommented:
There are interdependencies between DCs.  They need to all be running at all times.   If one is going to be removed for a long period of time it needs to be DCPromo'ed to a Member Server so all the Roles gracefully move to other DCs and the DC identifiers are removed from DNS.   It can be DCPromo'ed back in when it is brought back.

I have never seen a DC be powered down for more than a few minutes without some level of disruption somewhere.  Even if it has no Roles and is not a GC,...it can still be the last DNS that a Client queried, and a DNS Client will always query the same DNS is did last time,...if it can't reach that DNS, at minimum, there will be a lag before the Client Side Resolver "gives up" and tries a different listed DNS.  So there is always going to be negative effects of a DC being down,...it is just a question of how much negative effects you will see.
0
 
Andrey_GorohovAuthor Commented:
Yes. logging on problem. Share access problem... Exchange/Sharepoint did not check, but i thik will be the same....
0
 
James HaywoodCommented:
As pwindell says it sounds more like a DNS issue than a Kerberos issue. Can you confirm DNS settings on a couple of clients and see what is going on?

Can you also check if the DC that is offline has any of the FMSO roles?
0
 
Andrey_GorohovAuthor Commented:
Ok... i'll check DNS on clients... Look's like you are right and the problem in DNS...
Now all DC's is online and DC which was offline has no FSMO role.
0
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.

Join & Write a Comment

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 5
  • 3
  • 3
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now