Getting a trust type of messages in a mixed 2022 and 2025 environment. "Remediation" hasn't fixed my issues.

Question

By now, we all know about the Server 2025 bug that was causing trust relationship messages. I have implemented the remediation techniques of setting the domain controller to refuse machine password changes as well as setting domain members to 0 maximum machine password age. This remediation hasn't seemed to work. I get this on all domains setup like this: "The computer <computername> tried to connect to the server <\servername> using the trust relationship established by the <domainname> domain." However, the computer lost the correct security identifier (SID) when the domain was reconfigured. Reestablish the trust relationship." The user only sees an inability to sign onto the domain. They don't really get a trust relationship message at the desktop. It is quite random in nature, and I think stems from the same 2025 bug that went out in one of the spring updates. DCDiag is clean. I can demote the 2025 server at a site, and the issue goes away. Downgrading to 2022 isn't a real option for these domains.

Basically, users randomly cannot sign on to the domain on their Windows 11 Pro computers. When they can't, a tech can rejoin the computer to resolve the issue. Has anyone experienced this stuff, and found a resolution?

Answer 1

Dear BrandoAUTigers,

The behavior you've described—intermittent failures to sign in, loss of machine SID association, and the need to rejoin devices—aligns with a known issue introduced in a Spring 2025 update for Server 2025. While setting domain controllers to refuse machine password changes and configuring domain members with a maximum password age of zero are valid mitigation steps, recent reports suggest these alone may not fully resolve the problem.

Here are additional recommendations based on current findings:

1. Retain at Least One Legacy DC Environments that maintain a Windows Server 2022 domain controller alongside Server 2025 have reported improved stability. While downgrading may not be feasible, introducing a legacy DC temporarily could help isolate the issue.
2. Use Scheduled Secure Channel Repair Automate Test-ComputerSecureChannel -Repair or Reset-ComputerMachinePassword via scheduled tasks or login scripts to proactively restore trust before failures occur.
3. Monitor Event ID 4771 and Kerberos Logs These logs can help identify pre-authentication failures and pinpoint machines losing their secure channel unexpectedly.
4. Review Machine Account Replication Ensure machine accounts are replicating correctly across all domain controllers and that no stale metadata exists in AD.

Microsoft is actively investigating this issue, and we recommend subscribing to updates on the Microsoft Q&A thread for the latest guidance.

Let me know how it goes, and if this answer helps, feel free to hit “Accept Answer” so others can benefit too 😊 T&B, Domic.