Thank you, Tom. Meanwhile, I have received a confirmation from Steve Syfuhs that it is indeed a regression in Windows Server 2025:
https://hachyderm.io/@SteveSyfuhs/113652185587416636 ------------ yeah it's a bug on our end. Spec is right. We're fixing the bug. Our crypto agility overhaul to include sha256/384 introduced it. Amazingly we even have a test for this exact thing...that mocked out the relevant response check. Oops. ------------ On Суб, 14 сне 2024, Tom Jebo wrote: > [dochelp to bcc] > [support mail to cc] > > Hi Alexander, > > Thanks for your request regarding the KPASSWD protocol response > regression. One of the Open Specifications team members will respond > to assist you. In the meantime, we've created case 2412140040001521 to > track this request. Please leave the case number in the subject when > communicating with our team about this request. > > Best regards, > Tom Jebo > Microsoft Open Specifications Support > > -----Original Message----- > From: Alexander Bokovoy <[email protected]> > Sent: Saturday, December 14, 2024 1:07 AM > To: Interoperability Documentation Help <[email protected]> > Cc: [email protected] > Subject: [EXTERNAL] Windows Server 2025 regression with KPASSWD protocol > response > > Hello Dochelp! > > It was brought to our attention that Windows Server 2025-based Active > Directory domain controllers appear to regress in handling KPASSWD protocol. > Namely, a password change request is being processed and a password of an > Active Directory account has been changed but the response produced by the > domain controller is Kerberos error with code 0, explicitly not allowed by > the RFC3244 describing Microsoft KPASSWD protocol. > > There is an issue reported upstream to adcli utility which performs Linux > system domain join. As a part of the join process, we set a new credential to > the machine account. The machine account credential is updated in AD but the > response contains this KPASSWD error response with result code 0 > > 103 3.624528 192.168.122.48 192.168.122.109 KPASSWD 1742 > Request > (attached file) > > 106 3.709703 192.168.122.109 192.168.122.48 KPASSWD 165 > Kerberos > krb-error > pvno: 5 > msg-type: krb-error (30) > stime: Dec 13, 2024 02:55:10.000000000 EET > susec: 213134 > error-code: eRR-NONE (0) > realm: FOREST.MY > sname > name-type: kRB5-NT-SRV-INST (2) > sname-string: 2 items > SNameString: kadmin > SNameString: changepw > e-data: 0000 > > This issue was also reported by Windows Insiders in June 2024: > https://techcommunity.microsoft.com/discussions/windowsserverinsiders/problems-to-join-debianubuntu-machines-to-a-domain/4158051 > > The message they reported is the same. The issue 'Message stream modified' is > due to MIT Kerberos processing the returned Kerberos error with result code 0 > and rejecting it according to the RFC 3244. > > Since Kerberos errors aren't protected from mid-stream modifications, RFC > 3244 explicitly states in the section 2, describing the protocol, > that: > > ---------------------------------------------- > The user-data component of the KRB-PRIV message, or e-data component > of the KRB-ERROR message, consists of the following data. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | result code | result string / > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > result code (16 bits) (result codes 0-4 are from the original change > password protocol): > > The result code must have one of the following values > (big-endian integer): > > KRB5_KPASSWD_SUCCESS 0 request succeeds (This value > is not allowed in a KRB-ERROR > message) > ---------------------------------------------- > > I can provide a network trace and a keytab that shows the whole communication > during the domain join operation, including this kpasswd exchange. However, > I've been told the same situation happens with a normal user account password > change against Windows Server 2025 AD DC as well. > > If this is an implementation regression, would you please consult with the > engineering team on Windows Server side. However, if this is a protocol > change, can we see the changes documented? > > -- > / Alexander Bokovoy -- / Alexander Bokovoy _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
