Ghost images lose domain access after a period of time

We have several machines that we use to test drivers that are under development. To ensure that the systems do not have old versions of the driver files hanging around between builds, we use Ghost 2003 to create a "clean" image of the system before we do any testing. We do *not* move the images from one computer to another; they are simply used to roll the system back to a "clean" state, with a unique set of images for each physical computer.

To allow for testing multiple operating systems on a single system, we set the systems up with two primary partitions. One is a partition used to hold Ghost and various utilities. The other is a partition for the OS we want to test. We use Boot Magic to choose between the two partitions (which hides one and unhides/sets active the other). Then, when we want to change operating systems, we go to the Ghost partition and restore the correct image (2K/XP/98/Me) to the test partition.

Everything works great for several weeks. We can restore any image to the test partition, log in to the domain, and do the testing. Then, after a few weeks, we try to login under XP or 2K and get the following:

"Windows cannot connect to the domain, either because the domain controller is down or otherwise available, or because your computer account was not found. Please try again later. If this message continues to appear, contact your system administrator for assistance."

At this point, to continue testing, we need to do the following:

1) Login as a local admin.
2) Remove the computer from the domain.
3) Remove the computer account from the DC using Active Directory Users and Computers.
4) Add the computer back into the domain.
5) Make a new Ghost image.

If I skip step 3, when I go to add the computer back into the domain, I get "access denied." If I do not make a new Ghost image, the next time I restore the old image, it's back to being "broken."

At first, I thought there may have been an accidental duplication of computer names in the domain. However, we switched to a new naming system which prevents this from happening. We have added "-[OS]" to the end of the machine name, so the XP image has a machine name of "[computername]-XP."

It seems to me that, somehow, the domain SID on the DC or the client is somehow changing, but I'm not sure what could be triggering this. Is there something I'm missing somewhere, or will this be something we just have to live with?

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Your problem is related to one of the security layers built into MS NT operating systems. It is the Secure Channel Trust (SCT) that is broken and that will not permit to log on to the domain. The SCT generates a password that the DC and client use to exchange secure communications and that a human never sees. Behind the scenes, the SCT password and the SID are used to verify that a system is a valid domain participant. The DC has a registry setting that determines how often the SCT password is reset. The default is usually every 30 days.

When you restore a Ghost image that has not been participating in the domain for a while, it's SCT will be outdated because it will have missed the new password that the DC generated. You can change the default refresh cycle so that the SCT does not distribute a new password as often but that will not solve the problem completely. It will only cause the outdates images to be valid for a longer period. Increasing the SCT setting is also going to be discouraged by MS and your network security person as it is designed for security. If you still want to change it go to regedit>[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\maximumpasswordage] and change the decimal value to the number of days that you would like it to be. If you do not see the value name of maximumpasswordage then you have to add it.

Other options include: creating a new Ghost image every 15 days if the SCT setting is 30, continue the way you have by rejoining the domain when necessary, and re-allowing a system on the domain using ADSIedit (I won't get into this here).

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
I forgot to add one other workaround. In the same registry directory there is a setting to disable the password change altogether. This would need to be done on the DC and I wouldn't do it if you are really concerned about security. The one your going to want to change specifically is "DisablePasswordChange"=dword:0000000
Your are going to want to change it from a value of 0 to 1.
thoffmanAuthor Commented:
Thanks for the answer. I was afraid it was something like that, but at least now I know I can stop running around in circles trying to figure out what keeps breaking. I suppose the same problem would happen if you were to dual-boot XP and 2K and didn't use 2K for over a month.

The DisablePasswordChange would work if it could be done on a per-computer basis, but it's obviously not something we'd want to do for all computers. We'll just have to live with it for now. I'll take a closer look at ADSIEdit, which does look somewhat promising. If I run into problems with it, I'll post a new question. :)

thoffmanAuthor Commented:
Well, it's been awhile, but I wanted to make sure everything is working. Your solution of adding "DisablePasswordChange" to the workstation's registry seems to have solved the problem. After looking at;EN-US;154501, it makes sense, too.

From what I understand, what was happening was this.

1) 30 or more days after joining the domain, the Ghost image would be restored.
2) The workstation would see that 30 days has passed and negotiate a new password with the DC.
3) At this point, everything would be great. The workstation is using the new password.
4) The Ghost image would be restored again.
5) The workstation attempts to connect to the DC using the old password, which would be refused.

Thanks again for your help.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows XP

From novice to tech pro — start learning today.