Crashed Controller, Recreated, Logon Problems

[Matthew Frederick]

A (2k Server) domain controller crashed and had to be rebuilt from
scratch (the backups had been damaged as well). I did so, and manually
added a ton of users. All names (the machine, the domain, etc.) are
exactly as before.

Unfortunately for some reason when users are logging in they're not
exactly logged in correctly. While the DC was down most of them had
logged in locally with stored credentials (provided DHCP and DNS
temporarily through the router, since removed and both are again
successfully provided by the server), but now there's weirdness.

I didn't have all of their old passwords, of course, so I created new
ones. If they try to log on they can't reach the domain (and can't
logon), whether they used their old password or the new one. If I
change their password in the directory to what their old password was,
they're able to logon again. This tells me that the directory is being
queried when they logon.

However, they're not really logged on fully. You can't reach their
machine through the network ("there are currently no logon servers to
service the logon request"), for example.

If I go to each workstation and force it to leave the domain (join the
WORKGROUP workgroup) and then rejoin the domain, it works fine after a
restart, but effectively I've created a new account on the local
machine (previous account was Oliver, say, and the new one is
Oliver.MYDOMAIN), which means authorizing the account with the local
admin login, copying all of their files over, and of course still
losing some settings.

Is there any way to make their logons be "real" without recreating them
on every workstation?

(Sorry such a newb question, I'm really just a programmer and don't do
this kind of stuff normally, but it's a charity I'm helping out.)

Thanks.

 

[Danny Sanders]

Unless you had another DC online when you rebuilt the server to hold the
domain/user info, you created a new domain.

Naming it the same means nothing to your clients. The original domain had
it's own SAM that is replicated to each DC in the domain. Even if you create
another domain with the same name the SAM is different.

Think about it like this, Someone breaks in you Office with a server. He
installs it with the same name as your old server, takes your server down,
puts his in place, the fact that the SAM is different keeps him from owning
your domain and all the PCs on it.

If I go to each workstation and force it to leave the domain (join the
WORKGROUP workgroup) and then rejoin the domain, it works fine after a
restart, but effectively I've created a new account on the local
machine (previous account was Oliver, say, and the new one is
Oliver.MYDOMAIN), which means authorizing the account with the local
admin login, copying all of their files over, and of course still
losing some settings.

Since you created a new domain you have to remove your clients from the old
domain and add them to the new domain.

To prevent this in the future you should have a second DC in place to hold
the user/domain info while the downed server gets rebuilt.

hth
DDS

 

[Matthew Frederick]

Unless you had another DC online when you rebuilt the server to hold the
domain/user info, you created a new domain.

To prevent this in the future you should have a second DC in place to hold
the user/domain info while the downed server gets rebuilt.

Thanks, Danny, that's just what I needed to know. I suspected it wasn't
really the same domain, hence the problems, but you cleared it right
up. Thanks again.

 

[Jorge de Almeida Pinto [MVP - DS]]

by recreating the domain you created ANOTHER NEW domain with a new security
ID. ALL computers will need to be rejoined to the new domain....resources
will need to be re-ACLed because those will contain sIDs from the old
domain...

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Windows Server - Directory Services

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx