What happens if PDC emulator in 2003 is not there?

If the DC which has the PDC emulator role is powered off, what will happen to the domain?  Will people log in ok?  Will policies apply ok?  The domain has all windows 2003 server DCs.



I notice that when the PDC was unavailable on our network briefly, one of the other DCs gave this error

This computer was not able to set up a secure session with a domain controller in domain BLG due to the following: 
There are currently no logon servers available to service the logon request.  
This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator.  

ADDITIONAL INFO 
If this computer is a domain controller for the specified domain, it sets up the secure session to the primary domain controller emulator in the specified domain. Otherwise, this computer sets up the secure session to any domain controller in the specified domain.


Why does the DC need to see the PDC emulator so badly?


PDC emulator becomes irrelevant once you’re in Native mode and have no pre-2000 boxes around? Not at all. The PDC emulator still serves in two extremely important functions. you probably know that replicating AD
changes can take time—sometimes a significant amount of time. So suppose the following happens:
I’m working in St. Louis and need my password changed. So I call the company help desk, which
is, unknown to me, in Ottawa. The help-desk person changes my password, and it seems that all will
be well.
But consider: What DC did the help-desk person change my password on? Well, she probably
did it on a DC that was physically close to her, a DC in Ottawa. So an Ottawa DC knows my new
password. But how long will it be before my local St. Louis DCs know my new password? Well, it
could be hours. So does that mean that I’ll have to just twiddle my thumbs for a few hours waiting
for my new password to find its way to Missouri? Well, if we were talking about any other attribute
besides a password, then the answer would be yes—but passwords are special.
When an admin changes a password on some DC somewhere, that DC immediately contacts the
system acting as the PDC emulator FSMO for that domain. So the PDC FSMO almost always knows
the most up-to-date passwords. When I try to log in to the domain, it is a local DC that tries to
log me in. As I tell that DC my new password, the local DC is inclined at first to decline my logon,
as the password that I offer doesn’t match what the DC has. But before declining my logon, the
DC connects to the PDC emulator FSMO for its domain and double-checks—and if the password
that I gave my local DC matches the new one that the PDC has, then I’m logged in. This “highpriority
replication” also occurs for one other user attribute—account unlocks. Thus, when a user
forgets his password and retries to log on with the wrong password over and over, then not only does he need a new password, he probably also locked himself out of his account. So when the administrator
resets the user’s password, the admin probably also has to unlock the account. Immediately
replicating the new password without replicating the account unlock wouldn’t be very helpful

the AD needs all of its domain controllers to
pretty much agree about the current time and date. They don’t have to be exactly the same, but they
need to be close—Kerberos fails if a domain controller and the system trying to use that DC to
authenticate it disagree about what time it is by more than five minutes. Under NT 4 and earlier,
establishing time synchronization across a domain was difficult to accomplish. But Windows 2000, XP,
and 2003 include a service called the Windows Time service that keeps all of your Windows 2000,
XP, and 2003 workstations and servers in good time sync.
Machines in an AD stay in sync this way. The PDC emulator FSMO of the forest root—the first
created domain’s first domain controller, recall—is the Master Time Server Dude. All other servers
automatically create a hierarchy, sort of like a “telephone tree,” to distribute time synchronization
information. Everyone below that top dog automatically gets time synced from someone above it in
the hierarchy. Specifically,
◆ Member servers and workstations synchronize to the DC that logged them in.
◆ DCs in a domain all look to the DC in their domain that holds the PDC emulator operations
master role.
If there is more than one domain in the forest, then there will be more than one PDC emulator,
as each domain has a PDC emulator. The PDC emulators must agree on the time, so they
choose one of their number to be “the source”—the PDC emulator for the first domain in the
forest, the forest root. So, again, it’s the PDC emulator FSMO for the forest root domain that
is the ultimate time authority.
But who syncs that top dog, the forest root domain’s PDC FSMO?
First of all, odd as this sounds, you needn’t sync the FSMO. All that matters in AD is that all of the
servers think it’s the same time. Sure, it’d be nice if it was the actual time, but that’s not necessary. If
your whole enterprise was ten minutes early, that would constitute no problem for AD, as long as all
of the servers are ten minutes early..


So you are saying for a user to logon to the domain the PDC needs to be contacted ?


yep, i hope i the long post above from "mastering windows 2003 - Sybex" justifies this.


Hi, I'm evaluating the pros and cons of different AD architectures and I'm a
little concerned about what happens to users that are logging into a domain
where the PDC emulator is down.
e.g. What happens to incorrect password attempts - does it behave as normal
i.e. enforce the current password policy and lock the account?
Can they change passwords?
Can accounts be unlocked?
Any other security implications?


Nope, it doesn't behave normal. The normal process is that if the remote DC says
the password is bad, a PDC chain occurs and it verifies the password at the PDC
to see if it was recently changed and the local DC simply hasn't seen the change
yet.


This it will do, but it could be incorrect.


Depends on the client, if a straight legacy client, no. If a newer client yes.


PDC chaining is broken and out of band password change forwarding is broken. The
last occurs when a password is changed anywhere, it is immediately sent via an
RPC blast to the PDC so if the user hits any DCs that don't have the current
password the user will work instead of being locked out.

Best practices puts the RID Master on the PDC, if the machine is unavailable too
long the other DCs could run low or out of RIDS and disallow creation of
security principals.

Basically, you still protect the PDC, you don't want it going down for long
periods of time. Do not come up with an architecture that it is generally
unavailable either.
Can you be more specific about the change in behaviour that occurs on
incorrect passwords from the users perspective. i.e. does the "incorrect
password" message not get displayed if the PDC emulator is not available?


It gets displayed but it may be wrong. Let's say you have 4 DCs. The PDC is DC1,
DC2-4 are just good ol DCs. You change your password on DC3, it can't get to DC1
to tell it about the change. You immediately log off and try to log on with the
new password not allowing for normal replication, you try to authenticate
against DC4, it says the password is wrong and tries to ask DC1 if the password
was changed. It can't reach the PDC so you are refused log on even though you
used the correct password.