Bug 15694 - Windows 11 cannot connect to x86-32 Samba AD on samba-4.19/samba-4.20 due to endtime beyond 2038 and 32-bit signed time_t
Summary: Windows 11 cannot connect to x86-32 Samba AD on samba-4.19/samba-4.20 due to ...
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: 4.19.7
Hardware: x86 All
: P5 regression (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-08-09 22:47 UTC by Krzysztof Olędzki
Modified: 2024-09-06 00:40 UTC (History)
6 users (show)

See Also:


Attachments
Revert the part of PR-1095 that got rejected upstream (2.10 KB, patch)
2024-08-12 17:28 UTC, Krzysztof Olędzki
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Krzysztof Olędzki 2024-08-09 22:47:43 UTC
Samba-4.18 is soon going to be EOS, so I started upgrading my systems to 4.19.

After upgrading samba-4.18.11 to samba-4.19.7 I noticed that I can no longer log in to Windows 11 (23H2) systems if they talk to the Samba AD that is running on a x86-32 bit system, Gentoo to be more specific. Samba is built from the portage tree [1]. If I force the workstation to connect to a different (almost identically configured) AD running samba-4.19 or samba-4.20 but on x86-64, everything works. Also, for some reason Windows 10 workstations do not seem to be impacted.

I tried running samba with -d3 and got the log below, some highlights: 
 - "Need to use PA-ENC-TIMESTAMP/PA-PK-AS-REQ"
 - "Requested effective lifetime is negative or too short"
 - NT_STATUS_TIME_DIFFERENCE_AT_DC

Time is synchronized, everything starts working again as soon as I downgrade Samba to 4.18. I also tested 4.20 - same issue.

My "random educated guess" would be that this could be yet another issue that is only present on a 32 bit system (like misaligned stricture, variable length problem, etc), as we have seen a number of them, but can be wrong. I would appropriate some guidelines how to debug it further.
 

[1] https://gitweb.gentoo.org/repo/gentoo.git/tree/net-fs/samba/samba-4.19.7.ebuild

Configure flags:
--prefix=/usr --docdir=/usr/share/doc/samba-4.19.7 --htmldir=/usr/share/doc/samba-4.19.7/html --libdir=/usr/lib --mandir=/usr/share/man --enable-fhs --sysconfdir=/etc --localstatedir=/var --with-modulesdir=/usr/lib/samba --with-piddir=/run/samba --bundled-libraries=cmocka,heimbase,heimntlm,hdb,kdc,krb5,wind,gssapi,hcrypto,hx509,roken,asn1,com_err,NONE --builtin-libraries=NONE --disable-rpath --disable-rpath-install --nopyc --nopyo --without-winexe --with-acl-support --with-ads --disable-cephfs --without-cluster-support --disable-cups --without-dmapi --without-fam --disable-glusterfs --without-gpgme --with-json --disable-iprint --without-pam --with-quotas --with-regedit --disable-spotlight --with-syslog --without-systemd --systemd-install-services --with-systemddir=/lib/systemd/system --without-libunwind --with-winbind --disable-avahi --without-lttng --with-ldap --without-profiling-data --jobs 1 --with-shared-modules=!vfs_snapper,idmap_ad


Full log:
Kerberos: Probing for AS-REQ
Kerberos: Not a FAST request
Kerberos: AS-REQ red$@ad1.<redacted> from ipv4:192.168.0.12:49864 for krbtgt/ad1.<redacted>@ad1.<redacted>
Kerberos: heim_audit_setkv_number(): setting kv pair #auth_event=11
Kerberos: Client sent patypes: 128
Kerberos: heim_audit_vaddkv(): kv pair[0] client-pa=128
Kerberos: Looking for PK-INIT(ietf) pa-data -- red$@ad1.<redacted>
Kerberos: Looking for PK-INIT(win2k) pa-data -- red$@ad1.<redacted>
Kerberos: Looking for ENC-TS pa-data -- red$@ad1.<redacted>
Kerberos: Need to use PA-ENC-TIMESTAMP/PA-PK-AS-REQ
Kerberos: as-req: sending error: -1765328359 to client
Kerberos: Making non-FAST KRB-ERROR
Kerberos: heim_audit_vaddkv(): kv pair[0] elapsed=0.006574
Kerberos: heim_audit_vaddkv(): kv pair[0] e-text=Need\sto\suse\sPA-ENC-TIMESTAMP/PA-PK-AS-REQ
Kerberos: AS-REQ ERR_PREAUTH_REQUIRED ipv4:192.168.0.12:49864 red$@ad1.<redacted> krbtgt/ad1.<redacted>@ad1.<redacted> client-pa=128 e-text=Need\sto\suse\sPA-ENC-TIMESTAMP/PA-PK-AS-REQ elapsed=0.006574
stream_terminate_connection: Terminating connection - 'kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED'
Kerberos: Probing for AS-REQ
Kerberos: Not a FAST request
Kerberos: AS-REQ red$@ad1.<redacted> from ipv4:192.168.0.12:49865 for krbtgt/ad1.<redacted>@ad1.<redacted>
Kerberos: heim_audit_setkv_number(): setting kv pair #auth_event=11
Kerberos: Client sent patypes: ENC-TS, 128
Kerberos: heim_audit_vaddkv(): kv pair[0] client-pa=ENC-TS,128
Kerberos: Looking for PK-INIT(ietf) pa-data -- red$@ad1.<redacted>
Kerberos: Looking for PK-INIT(win2k) pa-data -- red$@ad1.<redacted>
Kerberos: Looking for ENC-TS pa-data -- red$@ad1.<redacted>
Kerberos: heim_audit_vaddkv(): kv pair[0] pa=ENC-TS
Kerberos: ENC-TS Pre-authentication succeeded -- red$@ad1.<redacted> using aes256-cts-hmac-sha1-96
Kerberos: heim_audit_setkv_number(): setting kv pair pa-etype=18
Kerberos: heim_audit_setkv_number(): setting kv pair #auth_event=6
Kerberos: heim_audit_setkv_number(): setting kv pair pa-succeeded-kvno=3
Kerberos: ENC-TS pre-authentication succeeded -- red$@ad1.<redacted>
Kerberos: heim_audit_setkv_number(): setting kv pair #auth_event=1
Kerberos: heim_audit_vaddkv(): kv pair[0] reqaddrs=TYPE_20:52454420202020202020202020202020
Kerberos: Requested effective lifetime is negative or too short
descriptor_prepare_commit: changes: num_registrations=0
descriptor_prepare_commit: changes: num_registered=0
descriptor_prepare_commit: changes: num_toplevel=0
descriptor_prepare_commit: changes: num_processed=0
descriptor_prepare_commit: objects: num_processed=0
descriptor_prepare_commit: objects: num_skipped=0
Auth: [Kerberos KDC,ENC-TS Pre-authentication] user [(null)]\[red$@ad1.<redacted>] at [Sat, 10 Aug 2024 00:14:45.446019 CEST] with [aes256-cts-hmac-sha1-96] status [NT_STATUS_TIME_DIFFERENCE_AT_DC] workstation [(null)] remote host [ipv4:192.168.0.12:49865] mapped to [WESOLA]\[RED$]. local host [NULL]
{"timestamp": "2024-08-10T00:14:45.446094+0200", "type": "Authentication", "Authentication": {"version": {"major": 1, "minor": 3}, "eventId": 4625, "logonId": "dfd3c836ed4b8dfd", "logonType": 3, "status": "NT_STATUS_TIME_DIFFERENCE_AT_DC", "localAddress": null, "remoteAddress": "ipv4:192.168.0.12:49865", "serviceDescription": "Kerberos KDC", "authDescription": "ENC-TS Pre-authentication", "clientDomain": null, "clientAccount": "red$@ad1.<redacted>", "workstation": null, "becameAccount": "RED$", "becameDomain": "WESOLA", "becameSid": "S-1-5-21-2116312273-956341640-2154069252-9631", "mappedAccount": "RED$", "mappedDomain": "WESOLA", "netlogonComputer": null, "netlogonTrustAccount": null, "netlogonNegotiateFlags": "0x00000000", "netlogonSecureChannelType": 0, "netlogonTrustAccountSid": null, "passwordType": "aes256-cts-hmac-sha1-96", "clientPolicyAccessCheck": null, "serverPolicyAccessCheck": null, "duration": 220651}}
Kerberos: as-req: sending error: -1765328373 to client
Kerberos: heim_audit_vaddkv(): kv pair[0] elapsed=0.220835
Kerberos: heim_audit_vaddkv(): kv pair[0] e-text=Requested\seffective\slifetime\sis\snegative\sor\stoo\sshort
Kerberos: AS-REQ ERR_NEVER_VALID ipv4:192.168.0.12:49865 red$@ad1.<redacted> krbtgt/ad1.<redacted>@ad1.<redacted> pa=ENC-TS pa-etype=18 client-pa=ENC-TS,128 e-text=Requested\seffective\slifetime\sis\snegative\sor\stoo\sshort pa-succeeded-kvno=3 reqaddrs=TYPE_20:52454420202020202020202020202020 elapsed=0.220835
stream_terminate_connection: Terminating connection - 'kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED'
Comment 1 Krzysztof Olędzki 2024-08-09 23:44:11 UTC
With some code tweaks for more logging:

Requested effective lifetime is negative or too short: start=1723245533, r->et.endtime=-170480411

Note that both start and et.endtime are time_t {aka long int}.

start=1723245533 looks sane:

# date -d @1723245533
Sat Aug 10 01:18:53 CEST 2024

But et.endtime=-170480411? Oh, uh, what do we have here? What is -170480411 doing there? Could it be...?

echo "2^32-170480411"|bc
4124486885

# date -d@4124486885
Mon Sep 13 04:48:05 CEST 2100

A-ha!
Comment 2 Krzysztof Olędzki 2024-08-10 00:09:24 UTC
So... diffing samba-4.18 vs 4.19 shows that this was recently added:

--------------------
@@ -2578,6 +2982,13 @@
        t = min(t, rk_time_add(start, realm->max_life));
 #endif
        r->et.endtime = t;
+
+       if (start > r->et.endtime) {
+           _kdc_set_e_text(r, "Requested effective lifetime is negative or too short");
+           ret = KRB5KDC_ERR_NEVER_VALID;
+           goto out;
+       }
+
        if(f.renewable_ok && r->et.endtime < *b->till){
            f.renewable = 1;
            if(b->rtime == NULL){
--------------------

Earlier in this function, we also have:

        time_t start;
        time_t t;

... but I suspect there are more places where we do time manipulation.

And I suspect we are getting 2100-09-13 from the client?
Comment 3 Krzysztof Olędzki 2024-08-10 00:25:36 UTC
Here is when this code got added:

https://git.samba.org/?p=samba.git;a=commitdiff;h=eeebd488f2a31482f2c47a1618513c937041c3ac - "
third_party/heimdal: Import lorikeet-heimdal-202305160500"
Comment 4 Douglas Bagnall 2024-08-10 04:48:17 UTC
good investigation, Krzysztof.

That looks to be this upstream commit:

https://github.com/heimdal/heimdal/commit/597b59dfb74f0c2e96954e16a9d77e94ca1afa92

https://gitlab.com/samba-team/devel/lorikeet-heimdal/-/commit/597b59dfb74f0c2e96954e16a9d77e94ca1afa92


> And I suspect we are getting 2100-09-13 from the client?

It could be a larger number of epochs out, but it doesn't look to be 9999 or 1601 or any other special date I recognise.

$ date -d@$((-170480411 + 59 * (1 << 32)))
Tue 16 Aug 9994 06:07:33 NZST


In any case, if it is 2100, I don't know what the solution could be if we are sticking to time_t.
Comment 5 Andrew Bartlett 2024-08-10 11:07:48 UTC
Yes, 2100-09-13 is I'm pretty sure from the client, the new Windows client started sending dates in 2100 as 'forever' after folks got grumpy about their previous choice of 9999. 

Except for just ignoring the endtime clamping to 2038 and hoping for the best, I don't see a good solution for Samba AD on 32 bit, and we could just refuse to build the AD DC on 32-bit without a 64-bit time_t, or require MIT Kerberos for that. 

(MIT has chosen to 'make' time_t unsigned for their operations, trying to extend the life here).
Comment 6 Krzysztof Olędzki 2024-08-10 12:24:51 UTC
Yeah, all options do not look very appealing, especially for the users.

While caused by the client (Windows 11) and triggered by what seems like an important Heimdal fix, from the end-user perspective this is still an interoperability regression - Samba AD with Heimdal supported Windows 11 until samba-4.18, but starting with 4.19 it no longer does.

Switching to a different Kerberos implementation seem also like a big PITA. Not only it may uncover a new set of bugs, but may not be be easy. For example in Gentoo "system-mitkrb5" is not supported for "addc" in the current ebuilds.

Would it make sense to reach out to Heimdal developers and ask them would be their recommendation / ideas / plan?

BTW: what is the long term plan for Samba vs Kerberos library? To this day I find it confusing we have all these options, including built-in vs external.

BTW - thanks for the 9999 hint - I now found https://github.com/heimdal/heimdal/issues/1011#issuecomment-1256577488 and https://bugzilla.samba.org/show_bug.cgi?id=15197 and we do mention there "2100".
Comment 7 Krzysztof Olędzki 2024-08-10 12:31:23 UTC
More specific: https://github.com/heimdal/heimdal/issues/1011#issuecomment-1317502322 kinda anticipated the problem and here we are...
Comment 8 Rowland Penny 2024-08-11 08:02:29 UTC
(In reply to Krzysztof Olędzki from comment #7)
I could be totally talking rubbish here, but from my understanding Windows 11 will never be 32bit, so why should the Samba DC accept anything 32bit from a Windows 11 machine ?
Comment 9 Andrew Bartlett 2024-08-11 08:50:07 UTC
(In reply to Rowland Penny from comment #8)
Windows time was always 64-bit, called NTTIME in Samba, and while there will be 2038 issues on that platform if the unix time APIs in C are used, windows apps don't typically do that. 

Anyway, in terms of actual fixes, presumably someone can look into some kind of clamping of the date, it is just meant to mean 'forever' and for 32-bit time_t systems, that is 2038.  The trick is not breaking other aspects of the cryptography, but thankfully Heimdal started saving the original bytes, rather than regenerating them in an important case.
Comment 10 Jennifer Sutton 2024-08-12 00:13:15 UTC
Note: this was https://github.com/heimdal/heimdal/pull/1095 (only one of the commits was accepted into Heimdal, commit 597b59dfb74f0c2e96954e16a9d77e94ca1afa92).
Comment 11 Krzysztof Olędzki 2024-08-12 14:30:14 UTC
So just for fun I tried samba 4.20 with commit 597b59dfb74f0c2e96954e16a9d77e94ca1afa92 reverted.

First some context to explain 1964-08-06:

# date -d@-170480411
Thu Aug  6 13:19:49 PDT 1964

Overall, as expected, the end result is not great:

Kerberos: heim_audit_setkv_number(): setting kv pair auth=1723471807
Kerberos: heim_audit_setkv_number(): setting kv pair end=-170480411
Kerberos: heim_audit_setkv_number(): setting kv pair renew=-170480411
Kerberos: AS-REQ authtime: 2024-08-12T16:10:07 starttime: unset endtime: 1964-08-06T22:19:49 renew till: 1964-08-06T22:19:49
Kerberos: heim_audit_vaddkv(): kv pair[0] etypes=18,17,23,24,-135,3
Kerberos: Client supported enctypes: aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, arcfour-hmac-md5, 24, -135, 3, using aes256-cts-hmac-sha1-96/arcfour-hmac-md5
Kerberos: heim_audit_vaddkv(): kv pair[0] etype=18/23
Kerberos: Requested flags: renewable-ok, canonicalize, renewable, forwardable
Kerberos: heim_audit_vaddkv(): kv pair[0] flags=renewable-ok,canonicalize,renewable,forwardable
===============================================================
INTERNAL ERROR: Signal 6: Aborted in samba (kdc(2)) (task[kdc] pre-forked worker(2)) pid 16970 (4.20.2)
If you are running a recent Samba version, and if you think this problem is not yet fixed in the latest versions, please consider reporting this bug, see https://wiki.samba.org/index.php/Bug_Reporting
===============================================================
PANIC (pid 16970): Signal 6: Aborted in 4.20.2
BACKTRACE: 45 stack frames:
 #0 /usr/lib/samba/libgenrand-private-samba.so(log_stack_trace+0x30) [0xf7b66640]
 #1 /usr/lib/samba/libgenrand-private-samba.so(smb_panic_log+0x91) [0xf7b667b1]
 #2 /usr/lib/samba/libgenrand-private-samba.so(smb_panic+0x1a) [0xf7b6695a]
 #3 /usr/lib/samba/libgenrand-private-samba.so(+0x1a00) [0xf7b66a00]
 #4 linux-gate.so.1(__kernel_sigreturn+0) [0xf7f87590]
 #5 linux-gate.so.1(__kernel_vsyscall+0x9) [0xf7f87579]
 #6 /usr/lib/libc.so.6(+0x898e7) [0xf79398e7]
 #7 /usr/lib/libc.so.6(gsignal+0x21) [0xf78e7311]
 #8 /usr/lib/libc.so.6(abort+0xee) [0xf78cf2bb]
 #9 /usr/lib/samba/libasn1-private-samba.so(+0x327b5) [0xf61ca7b5]
 #10 /usr/lib/samba/libasn1-private-samba.so(der_length_generalized_time+0x2e) [0xf61e29ce]
 #11 /usr/lib/samba/libasn1-private-samba.so(_asn1_length+0x49a) [0xf61e5baa]
 #12 /usr/lib/samba/libasn1-private-samba.so(_asn1_length+0x1a6) [0xf61e58b6]
 #13 /usr/lib/samba/libasn1-private-samba.so(_asn1_length+0x70a) [0xf61e5e1a]
 #14 /usr/lib/samba/libasn1-private-samba.so(_asn1_length+0x1a6) [0xf61e58b6]
 #15 /usr/lib/samba/libasn1-private-samba.so(_asn1_length+0x1a6) [0xf61e58b6]
 #16 /usr/lib/samba/libasn1-private-samba.so(_asn1_length+0x1a6) [0xf61e58b6]
 #17 /usr/lib/samba/libasn1-private-samba.so(length_EncTicketPart+0x1e) [0xf61d85de]
 #18 /usr/lib/samba/libkdc-private-samba.so(+0xdba6) [0xf34e9ba6]
 #19 /usr/lib/samba/libkdc-private-samba.so(+0x10915) [0xf34ec915]
 #20 /usr/lib/samba/libkdc-private-samba.so(+0x1b239) [0xf34f7239]
 #21 /usr/lib/samba/libkdc-private-samba.so(+0x1ba34) [0xf34f7a34]
 #22 /usr/lib/samba/service/kdc.so(+0x5de7) [0xf3514de7]
 #23 /usr/lib/samba/service/kdc.so(+0x6f92) [0xf3515f92]
 #24 /usr/lib/libtevent.so.0(+0x8e1b) [0xf7b28e1b]
 #25 /usr/lib/samba/libcli-ldap-private-samba.so(+0x724e) [0xf3f5024e]
 #26 /usr/lib/libtevent.so.0(+0x8e1b) [0xf7b28e1b]
 #27 /usr/lib/samba/libsamba-sockets-private-samba.so(+0xb58b) [0xf789758b]
 #28 /usr/lib/libtevent.so.0(+0x8e1b) [0xf7b28e1b]
 #29 /usr/lib/samba/libsamba-sockets-private-samba.so(+0xf270) [0xf789b270]
 #30 /usr/lib/libtevent.so.0(tevent_common_invoke_fd_handler+0x89) [0xf7b27a99]
 #31 /usr/lib/libtevent.so.0(+0xf8df) [0xf7b2f8df]
 #32 /usr/lib/libtevent.so.0(+0xce62) [0xf7b2ce62]
 #33 /usr/lib/libtevent.so.0(_tevent_loop_once+0x84) [0xf7b26b14]
 #34 /usr/lib/libtevent.so.0(tevent_common_loop_wait+0x2a) [0xf7b26e0a]
 #35 /usr/lib/libtevent.so.0(+0xcdf2) [0xf7b2cdf2]
 #36 /usr/lib/samba/process_model/prefork.so(+0x3261) [0xf3f91261]
 #37 /usr/lib/samba/process_model/prefork.so(+0x3977) [0xf3f91977]
 #38 /usr/lib/samba/libservice-private-samba.so(task_server_startup+0x72) [0xf7f033a2]
 #39 /usr/lib/samba/libservice-private-samba.so(server_service_startup+0xca) [0xf7f0177a]
 #40 samba: task[kdc] pre-forked worker(2)(+0x4ff2) [0x565f4ff2]
 #41 samba: task[kdc] pre-forked worker(2)(main+0x5c) [0x565f384c]
 #42 /usr/lib/libc.so.6(+0x20b85) [0xf78d0b85]
 #43 /usr/lib/libc.so.6(__libc_start_main+0x88) [0xf78d0c48]
 #44 samba: task[kdc] pre-forked worker(2)(_start+0x27) [0x565f38a7]

Same for samba-4.19.7:
Kerberos: heim_audit_setkv_number(): setting kv pair auth=1723472926
Kerberos: heim_audit_setkv_number(): setting kv pair end=-170480411
Kerberos: heim_audit_setkv_number(): setting kv pair renew=-170480411
Kerberos: AS-REQ authtime: 2024-08-12T16:28:46 starttime: unset endtime: 1964-08-06T22:19:49 renew till: 1964-08-06T22:19:49
Kerberos: heim_audit_vaddkv(): kv pair[0] etypes=18,17,23,24,-135,3
Kerberos: Client supported enctypes: aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, arcfour-hmac-md5, 24, -135, 3, using aes256-cts-hmac-sha1-96/arcfour-hmac-md5
Kerberos: heim_audit_vaddkv(): kv pair[0] etype=18/23
Kerberos: Requested flags: renewable-ok, canonicalize, renewable, forwardable
Kerberos: heim_audit_vaddkv(): kv pair[0] flags=renewable-ok,canonicalize,renewable,forwardable
===============================================================
INTERNAL ERROR: Signal 6: Aborted in samba (kdc(0)) (task[kdc] pre-forked worker(0)) pid 32441 (4.19.7)
If you are running a recent Samba version, and if you think this problem is not yet fixed in the latest versions, please consider reporting this bug, see https://wiki.samba.org/index.php/Bug_Reporting
===============================================================
PANIC (pid 32441): Signal 6: Aborted in 4.19.7
BACKTRACE: 53 stack frames:
 #0 /usr/lib/samba/libgenrand-samba4.so(log_stack_trace+0x30) [0xf7aeb640]
 #1 /usr/lib/samba/libgenrand-samba4.so(smb_panic_log+0x91) [0xf7aeb7b1]
 #2 /usr/lib/samba/libgenrand-samba4.so(smb_panic+0x1a) [0xf7aeb95a]
 #3 /usr/lib/samba/libgenrand-samba4.so(+0x1a00) [0xf7aeba00]
 #4 linux-gate.so.1(__kernel_sigreturn+0) [0xf7f01590]
 #5 linux-gate.so.1(__kernel_vsyscall+0x9) [0xf7f01579]
 #6 /usr/lib/libc.so.6(+0x898e7) [0xf78be8e7]
 #7 /usr/lib/libc.so.6(gsignal+0x21) [0xf786c311]
 #8 /usr/lib/libc.so.6(abort+0xee) [0xf78542bb]
 #9 /usr/lib/samba/libasn1-samba4.so(+0x327b5) [0xf62307b5]
 #10 /usr/lib/samba/libasn1-samba4.so(der_length_generalized_time+0x2e) [0xf62489ce]
 #11 /usr/lib/samba/libasn1-samba4.so(_asn1_length+0x49a) [0xf624bbaa]
 #12 /usr/lib/samba/libasn1-samba4.so(_asn1_length+0x1a6) [0xf624b8b6]
 #13 /usr/lib/samba/libasn1-samba4.so(_asn1_length+0x70a) [0xf624be1a]
 #14 /usr/lib/samba/libasn1-samba4.so(_asn1_length+0x1a6) [0xf624b8b6]
 #15 /usr/lib/samba/libasn1-samba4.so(_asn1_length+0x1a6) [0xf624b8b6]
 #16 /usr/lib/samba/libasn1-samba4.so(_asn1_length+0x1a6) [0xf624b8b6]
 #17 /usr/lib/samba/libasn1-samba4.so(length_EncTicketPart+0x1e) [0xf623e5de]
 #18 /usr/lib/samba/libkdc-samba4.so(+0xdb96) [0xf3c5ab96]
 #19 /usr/lib/samba/libkdc-samba4.so(+0x10905) [0xf3c5d905]
 #20 /usr/lib/samba/libkdc-samba4.so(+0x1b2a9) [0xf3c682a9]
 #21 /usr/lib/samba/libkdc-samba4.so(+0x1baa4) [0xf3c68aa4]
 #22 /usr/lib/samba/service/kdc.so(+0x5d57) [0xf3c85d57]
 #23 /usr/lib/samba/service/kdc.so(+0x6ea2) [0xf3c86ea2]
 #24 /usr/lib/libtevent.so.0(+0x8e1b) [0xf7aade1b]
 #25 /usr/lib/samba/libcli-ldap-samba4.so(+0x724b) [0xf3fba24b]
 #26 /usr/lib/libtevent.so.0(+0x8e1b) [0xf7aade1b]
 #27 /usr/lib/samba/libsamba-sockets-samba4.so(+0xb59b) [0xf781b59b]
 #28 /usr/lib/libtevent.so.0(+0x8e1b) [0xf7aade1b]
 #29 /usr/lib/samba/libsamba-sockets-samba4.so(+0xee79) [0xf781ee79]
 #30 /usr/lib/libtevent.so.0(tevent_common_invoke_fd_handler+0x89) [0xf7aaca99]
 #31 /usr/lib/libtevent.so.0(+0xf8df) [0xf7ab48df]
 #32 /usr/lib/libtevent.so.0(+0xce62) [0xf7ab1e62]
 #33 /usr/lib/libtevent.so.0(_tevent_loop_once+0x84) [0xf7aabb14]
 #34 /usr/lib/libtevent.so.0(tevent_common_loop_wait+0x2a) [0xf7aabe0a]
 #35 /usr/lib/libtevent.so.0(+0xcdf2) [0xf7ab1df2]
 #36 /usr/lib/samba/process_model/prefork.so(+0x3261) [0xf3ffb261]
 #37 /usr/lib/samba/process_model/prefork.so(+0x3ea3) [0xf3ffbea3]
 #38 /usr/lib/libtevent.so.0(tevent_common_invoke_timer_handler+0xe9) [0xf7ab29e9]
 #39 /usr/lib/libtevent.so.0(tevent_common_loop_timer_delay+0xb8) [0xf7ab2c08]
 #40 /usr/lib/libtevent.so.0(+0xf691) [0xf7ab4691]
 #41 /usr/lib/libtevent.so.0(+0xce62) [0xf7ab1e62]
 #42 /usr/lib/libtevent.so.0(_tevent_loop_once+0x84) [0xf7aabb14]
 #43 /usr/lib/libtevent.so.0(tevent_common_loop_wait+0x2a) [0xf7aabe0a]
 #44 /usr/lib/libtevent.so.0(+0xcdf2) [0xf7ab1df2]
 #45 /usr/lib/samba/process_model/prefork.so(+0x39a4) [0xf3ffb9a4]
 #46 /usr/lib/samba/libservice-samba4.so(task_server_startup+0x72) [0xf7e7d472]
 #47 /usr/lib/samba/libservice-samba4.so(server_service_startup+0xca) [0xf7e7b83a]
 #48 samba: task[kdc] pre-forked worker(0)(+0x4ff2) [0x56596ff2]
 #49 samba: task[kdc] pre-forked worker(0)(main+0x5c) [0x5659584c]
 #50 /usr/lib/libc.so.6(+0x20b85) [0xf7855b85]
 #51 /usr/lib/libc.so.6(__libc_start_main+0x88) [0xf7855c48]
 #52 samba: task[kdc] pre-forked worker(0)(_start+0x27) [0x565958a7]
prefork_child_pipe_handler: Parent 32391, Child 32441 terminated with signal 6
Comment 12 Krzysztof Olędzki 2024-08-12 15:04:40 UTC
Oh, I just realized that the version of Heimdal that we have in samba-4.19+ includes the whole PR - i.e. all 3 commits, not only the one that was accepted upstream.

Reverting the whole PR [1] prevents the crash and allows Windows 11 to work:

Kerberos: heim_audit_setkv_number(): setting kv pair auth=1723474758
Kerberos: heim_audit_setkv_number(): setting kv pair end=1723510758
Kerberos: heim_audit_setkv_number(): setting kv pair renew=1724079558
Kerberos: AS-REQ authtime: 2024-08-12T16:59:18 starttime: unset endtime: 2024-08-13T02:59:18 renew till: 2024-08-19T16:59:18

[1] https://patch-diff.githubusercontent.com/raw/heimdal/heimdal/pull/1095.patch
Comment 13 Krzysztof Olędzki 2024-08-12 17:28:52 UTC
Created attachment 18406 [details]
Revert the part of PR-1095 that got rejected upstream
Comment 14 Krzysztof Olędzki 2024-08-12 17:29:51 UTC
For completeness, I reverted only a part of the PR that was rejected upstream and it is also sufficient to make samba-4.20 and Windows 11 happy.
Comment 15 Jennifer Sutton 2024-08-14 04:07:07 UTC
(In reply to Krzysztof Olędzki from comment #13)
Note that this approach to fixing the issue causes one of our tests to fail (samba.tests.krb5.authn_policy_tests.AuthnPolicyTests.test_authn_policy_tgt_lifetime_min).