[cifs-protocol] [EXTERNAL] Windows Server 2025 regression with KPASSWD protocol response - TrackingID#2412140040001521

[Alexander Bokovoy]

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 <ab at samba.org>
> Sent: Saturday, December 14, 2024 1:07 AM
> To: Interoperability Documentation Help <dochelp at microsoft.com>
> Cc: cifs-protocol at lists.samba.org
> 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