New ADDS server prompts users for new passwords, but says it is incorrect, users can only log in with old password

Question

My organization used to have a Windows 2000 Server Ed. Domain Controller with DNS role also installed. It serviced 5 other servers and about 15 workstations. A few months ago, the motherboard went out and as it was a fairly old server anyway, my supervisor proposed we install a newer version of Windows Server (finally!) on an Intel NUC5i3MYHE we had just purchased, with the intent of installing some light server roles on it (fileserver, DNS, internal webserver, etc.).

The install of Server 2012 R2 on the box went smoothly, as did adding AD DS and DNS roles, and promotion to domain controller (since the existing domain was now offline due to the old server failure, I set the new DC up as the same domain name, and selected the option "New Forest" during dcpromo.exe).

The first time I put the new DC on the LAN, we had problems with people not being able to log into their computers. I realized my mistake (I have a pretty hectic avg. workday), not setting up the User Accounts in AD, and so promptly took it offline, at which time my end-users were able to log back into their workstations using their old accounts (cached on their local computers as "Offline Files"). For the record, I have not set up forward and reverse lookup zones in DNS yet. As I understand, I need AD DS working first and it is apparently not working (100%, anyway).

A couple days later, I got everyone set up with their same usernames they had had before the original DC crashed, with some requiring new passwords to meet complexity requirements. Here's where the snag is.

The EU's who already had passwords that met the complexity requirements had no problems logging in using their classic passwords. But for those whose password was required to change, they get a message when logging in w/ their old account, something to the effect of "Please lock this computer and sign in using the current domain credentials," which they try, but their machines (XP SP3 and W7, Pro Eds) will not let them in w/ the newly-created passwords, using their classic usernames.

I really do not want to set up a whole new round of usernames and passwords for each user, but I fear that the ones whose passwords did not change aren't logging into the new DC at all, but rather their old "Offline Files," and the users whose passwords did change, are able to access Desktop/My Docs, but only by entering their classic password and accessing the locally cached offline files as well.

FWIW, I noticed in my event log on the new server, Error ID 4013, which I found some info on here: https://technet.microsoft.com/en-us/library/cc735842(v=ws.10).aspx

...but when I follow the link for AD DS Troubleshooting found there, it takes me to a generic "Windows Server 2003/2003 R2 Retired Content" page, which is peculiar because it was a 2012 R2 machine that generated Error ID 4013 and yes, it was the correct one on the link (matched verbiage from my server).

I have tried logging in and out several times on several workstations, w/ various credentials and no luck, I can only get on the domain w/ the old passwords. If anyone can point me in the right direction, I'd be very grateful, I really don't deal w/ AD DS that much as my role in the company has shifted over the years from Network Admin to more of a Web Dev kind of role. I have Event Logs I can give you all, if that will help, the other warnings were RE: ADWS (Web Services) which I'm not sure is helpful, so I didn't include it, but let me know! Thanks in advance for your suggestions!

Answer 1

You created this problem for yourself by not following the most important two rules of Active Directory:

1. Never have just one Domain Controller. Two is the absolute minimum.
2. Backup your domain controllers regularly using an Active Directory aware backup utility.

If you don't have a backup of the old domain controller, do you still have the hard drive? Plug it in to a different computer and boot it up. Get it working again. Then erase your new domain controller and start over with it, but this time add it as an additional domain controller to your domain.

If you can't do that, then you will will need to join all of your EU's (whatever that is) computers to the new domain you created.

And don't even get me started on your choice of computer for your domain controller. An Intel NUC? Are you trying to set yourself up for failure?

Answer 2

You haven't re-created your old domain, you have created a domain that has similar names to the old domain.

As you suspect, your people continue to log in with credentials cached to the old domain. When they do, if you look in the Event Logs on their machines, and the DC, you will see problems.

You need have each PC "quit" the old domain, and "join" the new domain.

Make sure you have a local administrator password on each PC before tyring this.

Once the PCs are joined to the domain, and the users log in to the "new" domain, they will get a new user profile. It will look line this:

C:\Users\username

c:\users\username.domainname <- this is your new user profile

This may make people (and you) very unhappy. Use ForensIT to fix their profile. The free version works fine when run individually at each workstation.

If they had offline cached copies of files from shares, you have some cleanup to do there.

Change your thinking of "I'm repairing a domain" to "I'm migrating everything to a new domain, and salvaging what I can".