A couple of days back our Server crashed and we could not resurrect Active Directory. So we reconstructed Active Directory information from scratch. The usernames have been retained as they used to be before crash.

We have Windows-7 client machines that get authenticated by this Active Directory. As a user, I am unable to log in when I connect to the network as this user (remember we reconstructed Active Directory with exact same user names). However, if I disconnect from network and login, I am able to log into my computer and work usually. This happens because, clearly the Active Directory credentials are cached on the user machine.

What I want to be able to know is:

  • What is a quickest way to be able to 'rejoin' the Domain?
  • Is it possible to clear this user-machine cache and join the Domain fresh?
  • 2
    Please consider setting up a backup system and/or additional domain controller so you can recover next time. – Zoredache Aug 28 '12 at 19:12

It happens not because the previous AD credentials are cached but because the new AD objects are not the same as the old objects, even though you created them with the same names. What you need to do is:

  1. Unjoin the computers from the old domain (by putting them in workgroup mode) and join them to the new domain.

  2. Log onto the new domain from the newly joined computer using the username (which is the same user name but a different user account).

This is going to create a new user profile for the user on the respective computer. The old user profile can then be copied to the new user profile.

  • 1
    Actually, the reason he can connect with domain credentials when disconnected from the domain is because of credential caching. (By default, the credential cache GPO is set to remember credentials for the 5 previous logins.) – HopelessN00b Aug 28 '12 at 19:19
  • 1
    I should have been more specific. I meant that the reason he's experiencing this behavior is due to the fact that the computers aren't joined to the new domain, so he's unable to log onto the new domain but is able to log onto the computer with the cached credentials from the previous domain. – joeqwerty Aug 28 '12 at 19:24
  • You're both correct. The machines will need to be joined to the new domain and matching user names just isn't enough. Each of those accounts will now have a different SID, so to Active Directory will be different accounts. – John Gardeniers Aug 28 '12 at 20:25

You are going to have to Login as the local administrator account on the systems, leave the domain, reboot, and rejoin. You will also need to migrate all your old profiles since they will not have the same security identifier as your new domain.


What is a quickest way to be able to 'rejoin' the Domain?

  • You can't "rejoin" the domain. The domain that you had no longer exists.

Is it possible to clear this user-machine cache and join the Domain fresh?

  • Yes, and that's what you need to do. You'll want to remove the workstations from the domain by joining them to a workgroup (the default name, WORKGROUP works fine), and join them to your new domain. You'll need local administrator credentials on all the machines you remove and join, as well as domian admin credentials on the new domain to do this successfully.

A couple of days back our Server crashed and we could not resurrect Active Directory. So we reconstructed Active Directory information from scratch.

Well, I hope you're doing it correctly this time around. Always have at least 2 Domain Controllers, and make sure they're backed up, and can be restored from backup if something goes wrong.


I second Zoredache's thoughts as to you will need to remove the PCs from the domain, then re-add them. This is because each workstation object gets a password which is stored and updated by AD. When your domain was recreated, it does not have the computer objects or their associated passwords for the old computer objects. The way to re-establish a trust to the domain, is to remove the computers from the old domain, and then join them to the new domain. You should pre-create the computer objects in your new AD in the proper OUs before re-adding the computers to the domain.

You can also use a registry change to associate the old profiles to the new user accounts.

First have the users log into the workstations to create new profiles. These profiles will be associated with the new user accounts and their respective SIDs (security Identifiers). You can then log in with and admin account and go to the following registry path:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

In the "ProfileList" there will be a number of profiles represented by the SIDs. Click each and look for the one that has a regKey called ProfileImagePath with the location of the old domain profile. Copy the value of the "ProfileImagePath" regKey. Then find the the one that has the new profile path. Change the ProfileImagePath value on the new profile path, to that of the old profile.

So basically you are associating the new profile with the path on the local machine of the old profile.

Reboot and have the user log in.

And for your own good please either setup a second DC or start backing up AD.

  • This is very wrong with respect to AD. The new domain doesn't just lack the passwords for the old computer accounts, it lacks the old computer accounts as well, and has different GUIDs for even the objects that are/were named the same between domains. Please do something about those inaccuracies so I can remove my downvote (and as not to miseducate the OP on AD any more than he already has been). – HopelessN00b Aug 28 '12 at 19:31
  • forgot that sentence, I can see how it could be misunderstood, updating now. – HostBits Aug 28 '12 at 19:44
  • Hey guys thanks a lot...This seemed like a quick approach to me and so I tried to change the SID of my old profile with the new profile that was created...but it throws an error "Error writing SID: Cannot Edit SID. Error writing the values new contents" – Vikram Aug 28 '12 at 19:55
  • 1
    You don't edit the SID, you edit the profileImagePath regkey. – HostBits Aug 28 '12 at 20:13
  • @Cheekaleak thanks...yeah I required administrator privileges which resolved the error. I also edited profileImagePath and was able to change after my privileges were upgraded. I replaced the new profile (available in new AD) profileImagePath variable with the old profile value and rebooted my machine, it creates an temporary account (C:/USERS/Temp) and gives me a warning message that: This is a temporary profile and I cannot access my files. I looked up the registry to find the new profileImagePath variable was still pointing to the old variable as expected. – Vikram Aug 28 '12 at 20:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.