[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 _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
