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.
