Remediate Trust Relationships after upgrading to Windows Server 2025

As companies strive to stay ahead in the ever-evolving technological landscape, some have upgraded their domain controllers to Windows Server 2025. While this upgrade brings numerous benefits, it has also introduced a significant problem that affects companies that have updated all their domain controllers to this latest version. Interestingly, this issue does not impact companies that have retained at least one older domain controller.

The Problem: Trust Relationship Issues

The primary problem that companies are encountering after upgrading all their domain controllers to Windows Server 2025 is related to trust relationships. This issue manifests as a failure in the trust relationship between domain controllers and workstations, leading to authentication problems and disruptions in accessing network resources. The problem is particularly perplexing because it does not affect companies that have at least one older domain controller in their environment. It also only affect workstations with 23H2 and back. 24H2 seems to work without a problem.

In the clients, you will get some events with Event ID: 4771 from Microsoft-Windows-Security-Auditing with the message: Kerberos pre-authentication failed.

Root Cause

When a computer is connected to a domain, it has a machine account that represents that computer in the domain. This account is used to authenticate the computer allowing it to access network resources and do tasks. Each machine account, also known as a domain member, has its own unique password. The computer then needs to change that password every 30 days (by default).

The root cause of this issue lies in the way Windows Server 2025 handles certain security protocols and trust relationships. When all domain controllers are upgraded to Windows Server 2025, the new security protocols or configurations will block client devices from changing their passwords, causing the trust relationship to fail. But I have not been able to find out exactly why it fails, and have not been able to find a valid solution.

Large businesses impact

The impact of this issue on businesses can be severe:

• Authentication Failures: Users may be unable to log in to their workstations, leading to significant downtime and productivity loss.
• Access Denied: Critical applications and services that rely on domain authentication may become inaccessible.
• Increased Operational Overhead: IT teams may need to manually repair the trust on workstations.

Temporary stop the disease from spreading

By using GPO you can deploy 2 settings to stop this problem from spreading. It will basicly disable all machine account password changes in the domain. Remember, this is a temporary fix that you should revert as soon as you have a hotfix or other solution to deploy.

To disable password changes in client, set this key to: 0

Domain member: Maximum machine account password age

To disable and blocking a domain controller from accepting password change requests for machine accounts, set this key to: Enable

Domain controller: Refuse machine account password changes

The manual fix

But even if you have stopped password changes on devices, many clients has already lost the trust relationship and cannot connect. One manual way of solving the problem could be to update all devices to Windows 11 24H2. But in some organizations that could be a massive work that can take months to finish. So to manually repair the affected devices might be a quicker way. And yes, it works if you do it manually.

1. Disconnect Network
   (Remove network cable and/or turn off wifi at login prompt)
2. Now that the device is offline, the user can login with cashed credentials
3. Connect-Network
   (Insert Cable or turn on WiFi)
4. Open Powershell as Admin
5. Run the folowing command to repair the trust with the domain:
   $cred = Get-credentials
   Test-computersecurechannel -repair -credentials $cred
6. if successful, Reboot computer

Automated Quick fix

While the manual fix works, it can be quite hard to find them and fix them one by one. especially if the clients are spread all over the world. So I came up with an idea. Intune can still reach the machines even if trust relation ship with domain fails. So why not deploy a remediation that can detect if the device is affected, and automatically fix it.

So I came up with this simple remediation code (published on github):

Detect-TrustRelationship.ps1

 <#PSScriptInfo
.SYNOPSIS
    Script for Intune Remediation to detect if Trust relationship with domain is good
    
.DESCRIPTION
    This script will detect if Trust relationship with domain is good

.NOTES
    .AUTHOR         Mr Tbone Granheden @MrTbone_se 
    .COMPANYNAME    Coligo AB @coligoAB
    .COPYRIGHT      Feel free to use this, but would be grateful if my name is mentioned in notes

.RELESENOTES
    1.0 Initial version
#>

#region ------------------------------------------------[Set script requirements]------------------------------------------------
#Requires -Version 4.0
#endregion

#region -------------------------------------------------[Modifiable Parameters]-------------------------------------------------
$domainFQDN = "tbone.se" #Set the domain FQDN to check trust relationship with

#region --------------------------------------------------[Script Execution]-----------------------------------------------------
#Get domain controller if domain controller is available
try{
    $context = New-Object System.DirectoryServices.ActiveDirectory.DirectoryContext("Domain", $domainFQDN)
    $domain = [System.DirectoryServices.ActiveDirectory.Domain]::GetDomain($context)
    $PDCServer = $domain.PdcRoleOwner
    $PDCServerName = $PDCServer.Name
}
catch {
    write-host "No Domain network available, exiting script"
    exit 0
}
#test if domain controller is available
if (Test-NetConnection -ComputerName $PDCServerName -Port 389 -InformationLevel Quiet) {
    if (!(Test-ComputerSecureChannel)) {
        write-host "Broken Trust relationship with domain"
        exit 1
    }
    else{
        write-host "Good Trust relationship with domain"
        exit 0
    }
}
else {
    write-host "Failed to Connect to Domaincontroller, $PDCServerName is not available"
    exit 0
}
#endregion

Remediate-TrustRelationship.ps1:

<#PSScriptInfo
.SYNOPSIS
    Script for Intune Remediation to detect if Trust relationship with domain is good
    And fix it by repair the trust relationship with the domain
    
.DESCRIPTION
    This script will detect if Trust relationship with domain is good
    And fix it by repair the trust relationship with the domain

.NOTES
    .AUTHOR         Mr Tbone Granheden @MrTbone_se 
    .COMPANYNAME    Coligo AB @coligoAB
    .COPYRIGHT      Feel free to use this, but would be grateful if my name is mentioned in notes

.RELESENOTES
    1.0 Initial version
#>

#region ------------------------------------------------[Set script requirements]------------------------------------------------
#Requires -Version 4.0
#endregion

#region -------------------------------------------------[Modifiable Parameters]-------------------------------------------------
$domainFQDN = "tbone.se"        #Set the domain FQDN to check trust relationship with
$username = "tbone\joinaccount" #Set the domain username to repair trust relationship with
#Note: This account must have permission to join computers to the domain
$password = "TboneTbone911!"    #Set the domain password to repair trust relationship with
#Note: This password will be stored in plain text, use with caution! I strongly recommend to use a secure password vault or similar to store the password securely.
$securepassword = $password | ConvertTo-SecureString -AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential($username, $securepassword)

#region --------------------------------------------------[Script Execution]-----------------------------------------------------
#Get domain controller if domain controller is available
try{
    $context = New-Object System.DirectoryServices.ActiveDirectory.DirectoryContext("Domain", $domainFQDN)
    $domain = [System.DirectoryServices.ActiveDirectory.Domain]::GetDomain($context)
    $PDCServer = $domain.PdcRoleOwner
    $PDCServerName = $PDCServer.Name
}
catch {
    write-host "No Domain network available, exiting script with error $_"
    exit 0
}
#test if domain controller is available
if (Test-NetConnection -ComputerName $PDCServerName -Port 389 -InformationLevel Quiet) {
    if (!(Test-ComputerSecureChannel)) {
        write-host "Broken Trust relationship with domain"
        try{Test-ComputerSecureChannel -Repair -Credential $credential -Verbose
            write-host "Repaired Trust relationship with domain"
            exit 0
        }
        catch {
            write-host "Failed to repair Trust relationship with domain"
            exit 1
        }
    }
    else{
        write-host "Good Trust relationship with domain"
        exit 0
    }
}
else {
    write-host "Failed to Connect to Domaincontroller, $PDCServerName is not available"
    exit 0
}
#endregion

But keep in mind, the password in the script should be better protected. try using an encryption key or other protective solution instead of clear text. and keep the account used with leas privilege.

Lest hope we get or find a solution to this problem. But it has given me more arguments on keeping the client fleet up to date!

About The Author