Windows Server 2025 DCs causing trust relationship problems on client devices

[gabrielgbs97]

In our environment, the Kerberos Password Change flow is impacted (test domain WS 2025 DCs, 2025 forest level, etc.), and it is not functioning as expected. Both Linux and Windows clients are affected. In Linux hosts (MIT KERBEROS V) a message error appears 'Message Stream modified'. On windows domain members users cannot change account via ctrl+alt+supr. Some Windows workstations lost trust with domain, but this issue is not widespread.

 

People are experiencing the same issue, for example:https://community.netapp.com/t5/Network-and-Storage-Protocols/windows-server-2025-join-domain-failed/m-p/456972

 

I thoroughly tested this issue on Linux hosts, and the actual password change is performed. I think that AS reply is malformed by the server (or misinterpreted by the kerb client). Because of the detection of a 'failure' in the password change flow, client does not update krb5.keytab, the old remains but the machine password is effectively changed in ADDS. This results in failure of trust between ADDCs and host. LDAP(S) password change works like a charm.

 

For Linux hosts, you may test this behavior as follows:

- Activate KRB5 TRACE: export KRB5_TRACE=/dev/stderr

- Bare join computer account (obtain working host.keytab): adcli join -U @ --verbose --use-ldaps --host-keytab host.keytab --show-password

- Test your keytab, get a TGT: kinit -kt host.keytab \[email protected]

klist # Should appear an entry

- Destroy TGT: kdestroy -A

- Backup keytab cp host.keytab host.keytab.bak

- Try to join with defaults options, implies kpasswd protocol: adcli join -U @ --verbose --use-ldaps --host-keytab host.keytab

- It will appear a failure message, but actual machine password is changed.

- Because adcli detected a failure, it won't save a 'new' host.keytab.

- You won't be able to get TGT/TGS with previous host.keytab.bak: kinit -kt host.keytab \[email protected]

- On DCs, you will be able to track (2) password change on machine.

- realm joined machines (sssd) change its password via kpasswd, as this flow invalidates current keytab, you will start to see dropping Linux Hosts from domain. They will no longer be able to pre-authenticate as their current keytab has become outdated.

 

Similar scenario can be derived for Windows machine password change flow (still, they have fallback protocols if not restricted by GPO, that may be why it's working on our end), and user password (Ctrl+Alt+Supr) change fails without attempting to fallback (may be our GPOs).

 

We did some GPO cleaning as stated by some forum members, but with no luck so far. We still have not identified which registry/GPO item is affecting this. Perhaps this is a bug on Microsoft end given a set situations and will be fixed in an upcoming CU. I just don't hope that will be on December, because of minimal operations during the Western holidays and the upcoming new year. If I were the OP, I would try:

 

- Put a large reset password cycle for Windows/Linux I.e 60-120 days, hopefully Microsoft will have addressed this. Remember that machine passwords may not expire with default ADDS settings.

- Enable alternative (legacy/deprecated) password change protocols temporary.

Edited December 3, 2024 by gabrielgbs97
intro hell

[johndball]

Wanted to share a one week update: I had one more device drop off since these changes were made.

 

I immediately grabbed the event logs and this timestamped error was thrown twice immediately preceding the user's attempt to login and the domain trust error showing up: "The client has failed to validate the domain controller certificate for [domaincontroller01]. The following error was returned from the certificate validation process: A certificate chain could not be built to a trusted root authority." DomainController01 is an AD-integrated certificate server so I'm wondering if there is additional authentication happening in the communication stream that is failing.

 

From what I read in gabrielgbs97 's post, I suspect there is.

 

 

Can anybody provide insight into ADCS for the root CA? Does Server 2025 change the way certificates are validated and should I roll the root CA server since the upgrade? It was last issued prior to the migration to 2025.

Edited December 5, 2024 by johndball

[psydii]

The following doesn't describe the scenario faced in this thread, however it does indicate that there have been recent kerberos/certificate handling changes that (if I were to guess) may be being enforced in Server 2025 that are otherwise compatibility phase:

 

https://support.microsoft.com/en-us/topic/kb5037754-how-to-manage-pac-validation-changes-related-to-cve-2024-26248-and-cve-2024-29056-6e661d4f-799a-4217-b948-be0a1943fef1

 

And this page seems to recommend reviewing CA/DC certificate configuration on domains that were commissioned pre-Server 2016: https://dirteam.com/sander/2022/09/14/todo-upgrade-the-certificates-for-your-windows-server-2016-based-domain-controllers-and-up-to-enable-windows-hello-for-business-hybrid-scenarios/ perhaps the older templates etc are in play?

 

Do we know if a green-field 2025 Domain exhibits these issues?

[kevin_lane]

I found this

 

Sound a bit like your issue but again proceed with caution

 

https://kb.eventtracker.com/evtpass/evtPages/EventId_9_Microsoft-Windows-Security-Kerberos_63366.asp

[johndball]

I found this

Sound a bit like your issue but again proceed with caution

https://kb.eventtracker.com/evtpass/evtPages/EventId_9_Microsoft-Windows-Security-Kerberos_63366.asp

 

Backed up the 2025 DCs with expired certs, although each DC had a valid (expires next year) cert in the personal store, but backed them up nonetheless and removed the old ones. Two more machines dropped out of the domain. It's not a terrible issue as everything here is QA or "mirrors production"... just some annoyed folks.

 

Event logs on the two that just dropped out after making the change above was this: "This computer was not able to set up a secure session with a domain controller in domain [domain] due to the following: We can't sign you in with this credential because your domain isn't available. Make sure your device is connected to your organization's network and try again. If you previously signed in on this device with another credential, you can sign in with that credential. This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator. ADDITIONAL INFO If this computer is a domain controller for the specified domain, it sets up the secure session to the primary domain controller emulator in the specified domain. Otherwise, this computer sets up the secure session to any domain controller in the specified domain."

 

Same fix as last time too: airplane mode the WIFI, log in as local admin, turn on WIFI, disconnect from domain, wait 30 seconds, reconnect to domain, reboot. Everything is fine again.

Cleaning up the old rules and settings helped slow down the tide of dropping devices, but hasn't solved it. Going to sit in the background and watch this thread because I'm out of ideas as well now.

Edited December 5, 2024 by johndball

[Daradon]

Hello,

ich have the same Problem with DCs 2025. The Clients loosing domain trust after 30days when the MachinePassword is resetting. I made a GPO now to change this algorithmus to 120days. I hope it is working. Will we see a fix in January Patch Day?

I didnt installed Dezember update because im scared of new Problems. It fixed nothing right?

[Daradon]

Nobody here anymore?^^

[3s-gtech]

There’s just so few using 2025 on DCs yet, we’re probably not much help. Years of experience have made many of us cautious at jumping into new OSs, especially on core boxes.

[MartinDT]

We have exactly the same issue, updated DC's to 2025 and then the issues started.

I've disabled machine password changes, which looks to have worked for now.

 

There's a few similar threads on reddit about the same, all say the same they updated to 2025, but then they just stop talking.

[kevin_lane]

Do we know if there is any communication / technet article from MS around this issue ?

[MartinDT]

Not that I've found

[miljw002]

Hi All,

 

I’ve just signed up as I’ve been reading this thread and wanted to contribute. This is the only discussion on this issue I’ve found so far.

 

I’ve got a home lab and it appears impacted by this. Started out life as Server 2016, and has gone through upgrades to 2019, 2022, and now 2025.

 

It’s got RedHat 9, macOS, ESXi domain members and all are presenting different errors about computer account password changes.

 

On the Linux side, if I try and join a member using SSSD it failed with the message stream issue. If I join using the “samba-client” option it joins successfully.

 

On the ESXi side, they are all complaining every 30 minutes they can’t change their machine account passwords. I’ve checked various settings, but not tried to remove and readd or similar yet.

 

The Event Log on the DC’s have a KDC/Kerberos error about once a day about a lookup failure, but the error doesn’t include any account/computer details.

 

3 days after I’d upgraded the DCs I noticed replication issues, and these appeared to be related to DNS lookup failures. I run IPv6 at home and server 2025 seems to have another strange issue. With the firewall on, clients fail to access the DNS server on IPv6. Works on IPv4. I’ve checked the built in rules, and tried making a custom allow for DNS over IPv6. Only thing that allowed DNS on IPv6 to start working was to disable the firewall completely.

 

I’m still at the investigation stage, as I’m finding various strange issues with server 2025. Part of why I upgraded the homelab was to see what this is like before experiencing this in PROD

[Daradon]

Hey @miljw002

I also see the KDC lookup error in log of the DCs. It is a Part of the MachinePassword Change Bug i think so. I made the Time for ComputerPassword changes for a longer period now then 30 Days. Seems to deal with it.

Im really hope for the January Patch Day. I tryed like everythink. I think we cant fix it permantly at the Moment.

[ErDT]

I have had the same issue and found so far the simplest method is to push the below script out to all machines via Senso, you would need to use an account you are happy with (this may have to be the account used to build the machine as it would be owner of the machine object, or a general admin may work, not tested that aspect) and replace the values. This will reset the securechannel from the machine to the DC. I'm not yet sure this will be a forever fix as still investigating. but you can push out to your machines and for us has rectified them at least for now.

 

Microsoft guidance on this process is here https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/active-directory-has-newer-password-value-than-client-device

 

$username = "domain\yourusername"

 

$password = "yourpassword" | ConvertTo-SecureString -AsPlainText -Force

 

$credential = [PSCredential]::new($username, $password)

 

Test-ComputerSecureChannel -Repair -Credential $credential

 

So issue showing itself again following another 30 days, the script i posted before will fix the connection to AD of the device but all it does is reset the computer objects lstpwdset clock to 30 days again because for whatever reason the method in the script works to reset the computer objects password where its primary method doesn't. There is some bug in the way the computer (W11 23H2) is attempting to change the computer account password and what the 2025 DC's do with that information, it seems so far the machine sends the request to reset the password, either updates its local password but the 2025 DC's don't accept the change so its out of sync or the password just doesn't change and so the password on the machine and DC are out of date so its no longer trusted. Still trying to decipher a full fix as there are security hardenings on server 2025 that relate to it but not found the setting yet that rectifies it.

 

This appears to happen when upgrading a server from 2022 to 2025 or when building a brand new 2025 server and making it a DC.

Also this only happens on sites with 2025, we have 3 upgraded. The other 30+ on 2022 are behaving fine so theres either a bug with the OS or a security change that goes into effect but just doesn't seem to work within our environment.

.

Edited December 22, 2024 by ErDT

[gszech]

So issue showing itself again following another 30 days, the script i posted before will fix the connection to AD of the device but all it does is reset the computer objects lstpwdset clock to 30 days again because for whatever reason the method in the script works to reset the computer objects password where its primary method doesn't. There is some bug in the way the computer (W11 23H2) is attempting to change the computer account password and what the 2025 DC's do with that information, it seems so far the machine sends the request to reset the password, either updates its local password but the 2025 DC's don't accept the change so its out of sync or the password just doesn't change and so the password on the machine and DC are out of date so its no longer trusted. Still trying to decipher a full fix as there are security hardenings on server 2025 that relate to it but not found the setting yet that rectifies it.

 

This appears to happen when upgrading a server from 2022 to 2025 or when building a brand new 2025 server and making it a DC.

Also this only happens on sites with 2025, we have 3 upgraded. The other 30+ on 2022 are behaving fine so theres either a bug with the OS or a security change that goes into effect but just doesn't seem to work within our environment.

.

 

 

We recently upgraded two small school's domain controllers to Windows Server 2025. While one school is functioning normally, the other is experiencing persistent trust relationship errors. Both schools utilize the same Windows 11 image and configuration.

To resolve the issue, we temporarily rejoined the affected PCs to the domain, which provided a temporary fix for approximately one month. However, the trust relationship errors have resurfaced.

Most likely this is not a Windows Server 2025 bug. This is evident as one school with the same server 2025 version is operating without problems, and both domain controllers were upgraded identically.

 

My guess would be a GPO config or some change done years ago that affects one server, but not another.

 

We're transitioning the affected school to a 100% Chromebook environment, but I wanted to share my findings to help solve this problem.

[synaesthesia]

Why? I mean, just why? Do people not learn lessons from these mistakes?

[aac]

We upgraded one of our 2 DC's back in November as per my previous post I have not noticed any issues as of yet.

[MartinDT]

Do you have a GPO that disables machine password changes?

Or a long value set in Maximum machine account password age?

[Bird97]

We've two DCs on 2019 and One on 2022 and have noticed over the past couple weeks we've had a few devices do the same thing

 

Hi All

We have upgraded our 2 DCs to Windows Server 2025. We have noticed that about 20 client devices so far have been dropping off the domain and coming up with trust relationship errors when trying to login. Seems to happen when a user is already logged in as well and the user notices problems since the Radius wifi drops off which needs to be able to see AD/DCs. Did some googling and found some possible solutions but none of have worked. We have ran dcdiag on both dcs and checked replication statuses and all seems good. We dont really want to revert back to 2022 since theres 3 days worth of AD changes made. Quick fix for now is having to rejoin them to the domain but with a 1000+ devices its not ideal. Has anyone else experienced this as of yet?

 

#Nonegativevibesguys, i see you:shocked:

[ErDT]

So my colleague setup a clean infrastructure, process was as below and shows this is a legitimate issue with something on one of the operating systems.

 

1. Install Server 2019, upgrade to server 2022, upgrade to server 2025 (this follows the setup for most of our DC's though we have seen same behaviour at 1 of our sites that was freshly built to 2025 due to a hardware failure)
    
   
2. Install 2 workstations with windows 11 23H2
    
   
3. Set machine account password max age for the machines to 1 day.
    
   
4. NO GPO's added or amended, only the default domain controller and domain policy are in place + the 1 setting to amend machine password max age.
    
    
   

First workstation has just trust relationshipped itself into oblivion. We expect the second one to do so shortly as it passes the 1 day mark.

 

[kevin_lane]

If you setup a 2025 DC and no upgrades from previous do you get the same issue?

[ErDT]

In a different thread i have on microsoft forums one of microsoft people is testing that, so will see what they come back with. The only difference i could see with that would be the domain and forest functional level would be at 2025 where my colleague tested to mimic ours and left it at 2016 because we cannot lift it to 2025 as of yet. Other than obviously the possibility a relic setting is being kept throughout the upgrade process that breaks a function in server 2025.

 

If you setup a 2025 DC and no upgrades from previous do you get the same issue?

Edited January 10, 2025 by ErDT

[ErDT]

Hi

 

My colleague has tested further and now done a second stand alone domain setup as per the below.

 

1. Setup fresh server 2025 Domain controller (forest/domain functional level at 2025)
   
2. Install 2 workstations on windows 11 23h2
   
3. Set machine account password max age to 1 day
   
4. no GPO's added other than to set max machine account password age to 1 day.
   

Both workstations have now trust relationshiped themselves into oblivion, so upgrade or fresh the issue is still there on 2025.

 

------------------------------------------------------------------------------------------------------------------------------------------------------------

 

I have also separately on my 2 test machines within our production environment (where the issue was first found) done the below.

Both machines have machine account password max age set to 1 day.

 

Test Machine 1

• Upgrade from 23H2 to 24H2 - This was done on the 09/01/2025
  
• Rebooted daily to ensure the machine account password change process runs (believe it should anyways but just in case).
  
• Local Machine account password on the workstation has stayed on 09/01/2025 on the workstation and stayed 09/01/2025 in AD
  
• Trust relationship has yet to break 4 days on from this change but the local and AD passwords are not updating.
  

Test Machine 2

• Kept device on 23H2
  
• Rebooted daily to ensure the machine account password change process runs (believe it should anyways but just in case).
  
• Local machine account password on workstation updated yesterday to be 12/01/2025 on the workstations but stayed at 09/01/2025 in AD
  
• Trust relationship broke as we are seeing within our environment more generally.
  

Code used to find local machine account password date on device to compare to AD is below (may need to be run as system)

Get-date –date ([DateTime]::FromFileTime([system.BitConverter]::ToInt64((Get-ItemProperty -path "HKLM:\SECURITY\Policy\Secrets\`$MACHINE.ACC\CupdTime").'(default)',0))) -Format 'dd-MM-yyyy'

 

My best guess at the moment is 23H2/Server 2025 is broken and so makes a change to the local machine account password when its not being done in AD where 24H2 is aware that the machine account password hasn't updated in AD and so keeps the local password.

What's more concerning is that on 24H2 while the machine isn't trust relationshipping itself into oblivion (yet) it also isn't correctly updating the passwords, they are just sitting at the old values. But i need a few more days to ensure the above continues to behave as described.

I have also asked my colleague to move a machine in each of his test instances up to 24H2 and leave one at 23H2 to further test the above from a totally empty environment.

Edited January 13, 2025 by ErDT

[Daradon]

I can say that the Version of Windows 11 is not interesting. Im also in a school and we have win11 22h2,23h2,24h2 clients. Everybody has the Mistake. I think it is not possibile to fix at the moment. Only with gpo for machinepassword. Maybe server patch from tomorrow will fix it?

We will see

[SeesternAtoll48]

So in our two Domains only Windows 11 23H2 is affected, Windows 10 is fine as well as 11 24h2 and the 24h2 Machines do change their password. So in our case the Version is interesting.