If you've deployed Deep Freeze on domain-joined machines and encountered "The trust relationship between this workstation and the primary domain failed," you're not alone. It's one of the most common questions we receive from IT admins managing Active Directory environments.
Here's the good news upfront: this issue is completely preventable with proper configuration, and modern versions of Deep Freeze handle it automatically in most cases. But understanding why it happens helps you configure things correctly from the start - and troubleshoot if you inherit an older deployment.
Let's break down exactly what causes domain trust issues with frozen machines, how Deep Freeze handles this internally, and what you need to do to ensure your domain-joined PCs stay healthy.
What Actually Causes Domain Trust Loss
To understand the problem, you need to understand how Active Directory computer authentication works.
When a computer joins an Active Directory domain, two things happen: a computer account is created in AD, and a shared secret (password) is established between that computer and the domain. This password is stored both in Active Directory and locally on the machine in a protected registry location.
Every time the computer starts up and connects to the network, it authenticates to AD using this password - before any user logs in. If the passwords match, the secure channel is established and everything works normally.
Here's the critical bit: by default, Windows automatically changes this computer account password every 30 days. The machine initiates the change, updates both the local copy and the AD copy, and life continues.
On a frozen machine, this process breaks.
When a frozen computer initiates a password change, it successfully updates Active Directory. AD now expects the new password. But when the machine reboots, Deep Freeze wipes all changes - including the new password stored locally. The machine reverts to its baseline, which contains the old password.
Now you have a mismatch: AD has the new password, the local machine has the old password, and they can't authenticate. Domain login fails. You see the dreaded trust relationship error.
This doesn't happen immediately. AD retains both the current password and the previous password (to handle brief synchronisation gaps), so machines typically survive at least one password change cycle. But if a frozen machine with an outdated baseline attempts to authenticate after AD has cycled through two password changes, trust breaks.
How Deep Freeze Handles This (Since Version 7.6)
We recognised this issue years ago, and Deep Freeze has included automatic handling since version 7.6 (released in 2013). Here's how it works:
Password change suppression whilst frozen. When a machine is in a frozen state, Deep Freeze suppresses computer account password changes. The machine doesn't initiate a password change request to AD, so no mismatch can occur. The current password in the frozen baseline remains valid.
Password synchronisation when thawed. When the machine enters a thawed state (during maintenance windows), Deep Freeze allows normal password change behaviour. If a password change is due, it happens whilst thawed, gets written to both AD and the local machine, and when you refreeze, the new password is captured in the updated baseline.
This automatic handling means that as long as you're running a reasonably current version of Deep Freeze and scheduling regular maintenance windows, domain trust issues shouldn't occur. The system manages itself.
Important caveat: this only works if you have regular thaw periods. If a machine stays frozen continuously for months without ever thawing, the suppressed password never gets a chance to update, and eventually the mismatch between what AD expects and what the baseline contains may cause issues when the machine finally does need to re-establish trust.
How to Prevent Trust Issues Entirely
Prevention is straightforward. Here are your options, roughly in order of preference:
Option 1: Schedule regular maintenance windows (recommended). This is the simplest and best approach. If you're thawing machines at least monthly for Windows updates - which you should be doing anyway - computer account passwords will synchronise during those thaw periods. Deep Freeze handles the rest automatically.
Most organisations schedule weekly or fortnightly maintenance. That's more than sufficient. The 30-day password change cycle has plenty of opportunity to complete successfully.
Option 2: Disable machine account password changes via Group Policy. If you have machines that rarely or never thaw - kiosks, for example - you can disable automatic password changes entirely. Set the following Group Policy:
Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options → Domain member: Disable machine account password changes → Enabled
With this policy, the computer never attempts to change its password, so no mismatch can occur. The original password from domain join remains valid indefinitely.
Security consideration: Some security frameworks recommend regular password rotation. Disabling machine password changes technically weakens this. For shared-access machines in low-security environments (school labs, library computers), this is usually acceptable. For machines handling sensitive data, regular maintenance windows are preferable.
Option 3: Extend the password change interval. Rather than disabling password changes entirely, you can extend the interval. By default it's 30 days; you can set it to 90, 180, or 365 days via Group Policy:
Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options → Domain member: Maximum machine account password age → [days]
This gives you more buffer room if maintenance windows are infrequent, whilst still maintaining password rotation.
Option 4: Include the policy in your frozen baseline. You can also set the password change disable via registry before freezing. Add this to your baseline image:
HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DisablePasswordChange = 1
This achieves the same result as the Group Policy approach but is baked into the image rather than applied dynamically.
Best Practices for Long-Term Stability
Beyond the specific password issue, here are broader recommendations for running Deep Freeze smoothly in Active Directory environments:
Ensure you're on a current version of Deep Freeze. The automatic password handling we described has been in the product since version 7.6, and subsequent versions have refined the behaviour. If you're running something ancient, upgrade. Current versions handle domain integration much more gracefully.
Schedule maintenance windows consistently. Weekly or fortnightly maintenance for Windows updates naturally provides the thaw periods needed for password synchronisation. Don't let machines go months without thawing.
Update your baseline after maintenance. When machines thaw and update, they should refreeze with the new state - including any password changes. If you're manually managing baselines, ensure the post-maintenance state becomes the new baseline.
Monitor for machines that miss maintenance. Deep Freeze Cloud provides reporting on maintenance task completion. Machines that are powered off during scheduled maintenance miss their thaw window. Identify these and ensure they catch up.
Document your domain configuration. Record whether you're using the default password rotation, disabled passwords, or extended intervals. The next administrator will thank you.
Test with a pilot group. Before mass deployment, run a small pilot for 60-90 days - enough time to go through multiple password change cycles. Verify trust relationships remain healthy before rolling out broadly.
Fixing Trust Issues When They Occur
If you've already encountered a trust relationship failure, here's how to resolve it:
Step 1: Thaw the affected machine. You'll need to log in with a local administrator account (not a domain account, since domain authentication is broken). Thaw the machine so changes will persist.
Step 2: Reset the computer account password. You have several options:
PowerShell (recommended): Open an elevated PowerShell prompt and run:
Reset-ComputerMachinePassword -Server YourDomainController -Credential Domain\Admin
Or use:
Test-ComputerSecureChannel -Repair -Credential Domain\Admin
Either command resets the computer password and synchronises it with AD. If successful, domain authentication should work immediately.
Active Directory Users and Computers: Alternatively, from a domain controller or management workstation, open ADUC, locate the computer object, right-click, and select "Reset Account." Then rejoin the machine from the client side.
Step 3: Refreeze with the corrected state. Once trust is restored, refreeze the machine. The new, correct password is now part of the frozen baseline.
Step 4: Prevent recurrence. Implement one of the prevention strategies described above - regular maintenance windows, disabled password changes, or extended intervals - so this doesn't happen again.
Frequently Asked Questions
How often does this actually happen?
With current versions of Deep Freeze and regular maintenance windows, it's rare. We primarily see it in two scenarios: legacy deployments running very old Deep Freeze versions without automatic password handling, or machines that haven't thawed for extended periods (months). Properly configured modern deployments don't experience this issue.
Is this a Deep Freeze bug?
No, it's a natural consequence of how reboot-to-restore technology interacts with Active Directory's password rotation mechanism. Any system that reverts state on reboot would face the same challenge. Deep Freeze addresses this by suppressing password changes whilst frozen and allowing them during thaw periods - which works seamlessly when maintenance is scheduled regularly.
Can trust issues be fully prevented?
Yes. Either schedule regular maintenance windows (recommended) or disable computer account password changes via Group Policy. Either approach eliminates the possibility of password mismatch. Thousands of organisations run Deep Freeze on domain-joined machines without trust issues because they've configured one of these approaches.
Does this affect Azure AD-joined machines?
Azure AD (now Entra ID) uses different authentication mechanisms than traditional Active Directory. The specific computer account password rotation behaviour discussed here applies to on-premises AD domain joins. Azure AD-joined and hybrid-joined machines have their own considerations. Contact us if you're deploying in Azure AD environments and we can provide specific guidance.
What if I don't know the local administrator password?
This is a common complication. If trust is broken and you don't have local admin credentials, you can try logging in with cached domain credentials whilst disconnected from the network. Alternatively, you'll need to use password recovery tools or reimage. This is a good argument for ensuring local admin credentials are documented and accessible - or using LAPS (Local Administrator Password Solution) to manage them.
Should I disable password changes on all frozen machines?
It's the simplest approach, but not always necessary. If you're already scheduling regular maintenance (weekly or fortnightly), passwords synchronise naturally during thaw periods and disabling isn't required. Disabling makes most sense for machines that rarely thaw - dedicated kiosks, for example - or in environments where simplicity trumps strict password rotation requirements.
The Bottom Line: A Solved Problem
Domain trust issues with Deep Freeze are well-understood and entirely preventable. Modern versions of Deep Freeze handle the complexity automatically - as long as you schedule regular maintenance windows, password synchronisation happens seamlessly in the background.
For machines that rarely thaw, disabling computer account password changes via Group Policy eliminates the issue entirely.
If you've inherited a deployment with trust problems, the fix is straightforward: thaw, reset the password, refreeze, and implement proper prevention going forward.
Thousands of organisations run Deep Freeze on domain-joined machines across schools, enterprises, and government agencies without trust issues. With proper configuration, you will too.
Need Help with Your Domain Deployment?
Our support team has extensive experience with Active Directory environments. Reach out if you need deployment guidance.
