Server 2025 Domain Controllers - Trust relationship issues on workstations after 30 days as "pwdLastSet" value unable to be updated

Anyone saw the new win 11 24h2 patch KB5050094?

It is fixing a domain join bug. Maybe it is changing something for our Problem?

Maybe someone can try it out

Are they the same ?

In my case it is 2016 domain but both DC and Workstation match 100% on encryption types. Thx though! Will pay attention to that when I upgrade.

Check the attribute "msDSSupprtedEncryptionTypes" in the AttributeList on the 2025 domain controller machine object in AD.

Check the attribute "msDSSupprtedEncryptionTypes" in the AttributeList on the failing workstation machine object in AD.

Are they the same ?

If the failing workstations attribute is RC4, AES128, AES 256 and the Domain Controller only has AES 128, AES 256,

remove RC4 on the workstation and reboot.

That removal can be done in many ways.

A suggestion is to make a test-OU and put the failing workstation in it, make a GPO with setting "Security Options" ->AES128_HMAC_SHA1, AES256_HMAC_SHA1 and "Future encryption types". Restart when it takes effect.

OR

Make a new GPO for the existing OU and only put the failing workstation in it.

Check the AttributeList on both ADMachine Objects to see if they ar the same.

I stumbled across this article because I was researching upgrading to Server 2025 DC's in preparation for our Win11 migration. This is going to sound off topic but, I swear I am having a very similar issue on Server 2016 DC's with Windows 10 22H2 wks. Started a couple months ago where all the sudden, a few random users try to log in and they are throwing bad password events even though, they are entering the correct password. Account locks and we have to unlock it but unless they are very fast, the account will lock again within seconds. DC's show hundreds of event 4771 Kerberos pre-authentication failed. Rebooting the user does not fix the issue. If their machine gets locked, they cannot log in again until we unlock the account. The next day, problem stops as fast as it started. This happens about every 30 days and to a different group of random users. I have tried just about everything I've read to resolve the issue and had no success. Was hoping the upgrades would just get us past it but sounds like out of the frying pan and into the fire situation.

That RPC methods setting is missing from my group policy console even though my entire domain is at the 2025 level. Not sure why I didn't get it. I will try and re-apply the Server 2025 ADMX files. (Edit: reapplying the 2025 Group Policy pack to my DC fixed this missing RPC Methods policy)

I did want to add this update I saw on the Server 2025 release notes:

• Legacy Security Account Manager (SAM) remote procedure call (RPC) password change behavior: Secure protocols such as Kerberos are the preferred way to change domain user passwords. On DCs, the latest SAM RPC password change method SamrUnicodeChangePasswordUser4 by using Advanced Encryption Standard (AES) is accepted by default when it's called remotely. The following legacy SAM RPC methods are blocked by default when they're called remotely:
  • SamrChangePasswordUser
  • SamrOemChangePasswordUser2
  • SamrUnicodeChangePasswordUser2
  For domain users that are members of the Protected Users group and for local accounts on domain member computers, all remote password changes through the legacy SAM RPC interface are blocked by default, including SamrUnicodeChangePasswordUser4. To control this behavior, use the following GPO setting: Computer Configuration > Administrative Templates > System > Security Account Manager > Configure SAM change password RPC methods policy