[PATCH 0/2] MIT KDC: allow Windows expired password change with short realm

[Achilleas Stergioulis]

Hi all,

Just following up on this series. I’ve rebased it onto current master,
and the focused kpasswd test suite passes all 29 tests.

The latest GitLab pipeline is red, but the MIT Kerberos tests passed
before the jobs failed during lcov coverage collection. The other test
failure is an unrelated SMB-over-QUIC timeout.

Any feedback on the approach would be appreciated, particularly
whether KRB5_KDB_PWCHANGE_SERVICE on the validated server entry is the
right authoritative signal here.

Thanks,
Achilleas

On Mon, 14 Sep 2026 22:43:04 -0700, Achilleas Stergioulis
<achilleasnake at gmail.com> wrote:
> Hi all,
>
> I’ve been investigating Samba Bug 14630:
>
> https://bugzilla.samba.org/show_bug.cgi?id=14630
> https://gitlab.com/samba-team/samba/-/merge_requests/4677
>
> We hit this on a Fedora Samba AD DC using the MIT KDC backend. When a user’s password has expired, Windows requests kadmin/changepw using the NetBIOS domain as the realm. Samba returns KDC_ERR_KEY_EXPIRED, so Windows never gets as far as contacting the password-change service.
>
> The KDB lookup has already recognized the local password-change service and set KRB5_KDB_PWCHANGE_SERVICE. My patch uses that validated flag in the AS policy check instead of checking the realm from the original request again.
>
> Ordinary TGT requests from expired accounts are still rejected. Preauthentication, incorrect-password handling, disabled and locked accounts, and password-policy checks are unchanged.
>
> I also added regression tests for both pwdLastSet=0 and natural password expiry with the Windows-style short-realm request. The focused samba.tests.krb5.kpasswd_tests suite passes 29/29 with MIT Kerberos and 29/29 with embedded Heimdal. We have also tested the patched Fedora build with the original Windows workflow, and the password change now works.
>
> The remaining GitLab CI failures appear unrelated: LCOV/geninfo failures after the tests complete, plus existing flaky filesystem and WINS tests.
>
> I’d appreciate a review from someone familiar with the MIT KDC/KDB path. In particular, does using KRB5_KDB_PWCHANGE_SERVICE here look like the right approach?
>
> Thanks,
> Achilleas