(In reply to David Fillingham from comment #0)

I do not think this is a winbind problem.

I used a Debian 12 VM and altered it to use sssd-kcm and got to the point that David did, I could log in, but there wasn't a ccache and running kinit created it.
I tried various things, but I couldn't get a ccache at logon, whilst using 'FILE' instead of 'KCM' works.

I then did something I haven't done in years, I set up a Debian 13 VM and installed sssd (including sssd-kcm) instead of Samba and joined it to the domain with realmd.

Intially when I logged into the VM, I did get a ccache, but it was in /tmp as 'krb5cc_1215001104_6Q1vuJ' i.e. it was a file. After a bit of internet searching, I found that this was coming from 'env' where KRB5CCNAME was being set, further searching lead me to how to turn this of in sssd.conf:

[pam]
pam_response_filter = ENV:KRB5CCNAME

Now when I logon to the domain joined computer running sssd, I get this:

rowland@debsssd:~$ klist
klist: Credentials cache 'KCM:1215001104' not found

Running kinit does create the ccache:

rowland@debsssd:~$ kinit 
Password for rowland@SAMDOM.EXAMPLE.COM: 
rowland@debsssd:~$ klist
Ticket cache: KCM:1215001104
Default principal: rowland@SAMDOM.EXAMPLE.COM

Valid starting     Expires            Service principal
12/02/26 11:45:15  12/02/26 21:45:15  krbtgt/SAMDOM.EXAMPLE.COM@SAMDOM.EXAMPLE.COM
	renew until 13/02/26 11:45:08

This is exactly the same as using winbind with sssd-kcm.

My latest thinking is that whatever runs 'kinit' at logon either doesn't know about the kcm or doesn't have permission to write to the cchache.

I'll preface this by saying I'm not a C developer, so I could be way off base here.
I've been following the instructions to build Samba from source as best I can, running ./configure with the same options as used in the arch package, for reference, that's:

./configure --enable-fhs \
    --prefix=/usr \
    --sysconfdir=/etc \
    --sbindir=/usr/bin \
    --libdir=/usr/lib \
    --libexecdir=/usr/lib/samba \
    --localstatedir=/var \
    --with-configdir=/etc/samba \
    --with-lockdir=/var/cache/samba \
    --with-sockets-dir=/run/samba \
    --with-piddir=/run \
    --with-ads \
    --with-ldap \
    --with-winbind \
    --with-acl-support \
    --with-systemd \
    --systemd-install-services \
    --with-pam \
    --with-pammodulesdir=/usr/lib/security \
    --private-libraries='!ldb' \
    --bundled-libraries='!tdb,!talloc,!pytalloc-util,!tevent,!popt,!pyldb-util' \
    --with-shared-modules="idmap_ad,idmap_rid,idmap_adex,idmap_hash,idmap_tdb2,pdb_tdbsam,pdb_ldap,pdb_ads,pdb_smbpasswd,pdb_wbc_sam,pdb_samba4,auth_unix,auth_wbc,auth_server,auth_netlogond,auth_script,auth_samba4,vfs_io_uring" \
    --disable-rpath-install \
    --with-profiling-data


From there, I started littering the code with DBG_DEBUG calls, to track down what was happening.
My extra logs showed that krb5_cc_initialize was failing:

in krb5_cc_initialize
calling (*id->ops->init)
(*id->ops->init) return value was: 13
(*id->ops->init) return value to errmsg was: Could not make temp ccache FILE:KCM:66639-5oMCpo

I thought "that looks weird, why is the FILE: prefix here?"

So going back up the stack, and found cc_get_prefix_ops, put in a bunch of logging there to see:

calling cc_get_prefix_ops
in cc_get_prefix_ops prefix=KCM:66639
residual is true
in ops loop, i=0
context->cc_ops[i]->prefix=API, prefix_len=3
strncmp did not match context->cc_ops[i]->prefix and prefix
in ops loop, i=1
context->cc_ops[i]->prefix=FILE, prefix_len=4
strncmp did not match context->cc_ops[i]->prefix and prefix
in ops loop, i=2
context->cc_ops[i]->prefix=DIR, prefix_len=3
strncmp did not match context->cc_ops[i]->prefix and prefix
in ops loop, i=3
context->cc_ops[i]->prefix=MEMORY, prefix_len=6
strncmp did not match context->cc_ops[i]->prefix and prefix
leaving cc_get_prefix_ops, returning null
cc_get_prefix_ops returned null, using default ops of &krb5_fcc_ops

Key message at the end "cc_get_prefix_ops returned null, using default ops of &krb5_fcc_ops"

I found in third_party/heimdal/lib/krb5/context.c that krb5_cc_register(context, &krb5_kcm_ops, TRUE); was gated behind a define of HAVE_KCM.
I also found in third_party/heimdal/lib/krb5/kcm.c a bunch of code that was gated behind a define of HAVE_KCM

I looked for "HAVE_KCM" in the codebase and found a reference in third_party/heimdal/configure.ac, mentioning --enable-kcm option
I tried running ./configure and adding the --enable-kcm option, but received an error that it was an unknown option.

I hacked it in by adding #define HAVE_KCM 1 into the source files, recompiled, then tried a login.
Checked the extra debug logs:

ontext->cc_ops[i]->prefix=KCM, prefix_len=3
strncmp matched context->cc_ops[i]->prefix and prefix
leaving cc_get_prefix_ops, returning context->cc_ops[i]
cc_get_prefix_ops returned something not null
calling allocate_ccache
in allocate_ccache
ops->prefix is 'KCM'
filepath value is: 0
residual is '66639', calling _krb5_expand_path_tokens
_krb5_expand_path_tokens return value is: 0
exp_residual is '66639'
ret is 0, calling _krb5_cc_allocate
_krb5_cc_allocate returned: 0
calling (*id)->ops->resolve2
(*id)->ops->resolve2 returned: 0

This looks good, time to check klist...:

[david@archvm ~]$ klist
Ticket cache: KCM:66639
Default principal: david@AD.FILLINGHAM.AU

Valid starting     Expires            Service principal
15/02/26 21:45:43  16/02/26 07:45:43  krbtgt/AD.FILLINGHAM.AU@AD.FILLINGHAM.AU
        renew until 22/02/26 21:45:43
15/02/26 21:45:43  16/02/26 07:45:43  ARCHVM$@AD.FILLINGHAM.AU
        renew until 22/02/26 21:45:43


Woohoo, it's working.

I don't have the skills or experience with the build tooling here to help write a patch to allow this functionality to be enabled, but I'm hoping this helps someone who's more familiar.

Ok, even with the above changes, something still fails if you login again when there's already an existing ccache in the KCM.

Logs from winbindd:

Feb 15 22:08:50 archvm winbindd[81113]: [2026/02/15 22:08:50.748867,  0, pid=81113, effective(0, 0), real(0, 0), traceid=91] ../../source3/libads/kerberos.c:992(ads_kdestroy)
Feb 15 22:08:50 archvm winbindd[81113]:   ads_kdestroy: krb5_cc_destroy(KCM:66639) failed: Unknown error -1
Feb 15 22:08:50 archvm winbindd[81113]: [2026/02/15 22:08:50.748922,  0, pid=81113, effective(0, 0), real(0, 0), class=winbind, traceid=91] ../../source3/winbindd/winbindd_cred_cache.c:764(remove_ccache)
Feb 15 22:08:50 archvm winbindd[81113]:   remove_ccache: failed to destroy user krb5 ccache KCM:66639 with: Unknown error -1

Extra DBG_DEBUG logs added throughout the code:

[2026/02/15 22:08:54.770265, 10, pid=81113, effective(66639, 0), real(66639, 0), traceid=105] ../../source3/libads/kerberos.c:192(kerberos_kinit_generic_once)
  kerberos_kinit_generic_once: calling krb5_get_init_creds_opt_alloc
[2026/02/15 22:08:54.770276, 10, pid=81113, effective(66639, 0), real(66639, 0), traceid=105] ../../source3/libads/kerberos.c:197(kerberos_kinit_generic_once)
  kerberos_kinit_generic_once: krb5_get_init_creds_opt_alloc was successful
[2026/02/15 22:08:54.770282, 10, pid=81113, effective(66639, 0), real(66639, 0), traceid=105] ../../source3/libads/kerberos.c:216(kerberos_kinit_generic_once)
  kerberos_kinit_generic_once: request_pac is true
[2026/02/15 22:08:54.770286, 10, pid=81113, effective(66639, 0), real(66639, 0), traceid=105] ../../source3/libads/kerberos.c:217(kerberos_kinit_generic_once)
  kerberos_kinit_generic_once: calling krb5_get_init_creds_opt_set_pac_request
[2026/02/15 22:08:54.770291, 10, pid=81113, effective(66639, 0), real(66639, 0), traceid=105] ../../source3/libads/kerberos.c:222(kerberos_kinit_generic_once)
  kerberos_kinit_generic_once: krb5_get_init_creds_opt_set_pac_request was successful
[2026/02/15 22:08:54.848060, 10, pid=81113, effective(66639, 0), real(66639, 0), traceid=105] ../../source3/libads/kerberos.c:248(kerberos_kinit_generic_once)
  kerberos_kinit_generic_once: david@FILLINGHAM@AD.FILLINGHAM.AU mapped to david@AD.FILLINGHAM.AU
[2026/02/15 22:08:54.848078, 10, pid=81113, effective(66639, 0), real(66639, 0), traceid=105] ../../source3/libads/kerberos.c:251(kerberos_kinit_generic_once)
  kerberos_kinit_generic_once: canon_realm is 'AD.FILLINGHAM.AU'
[2026/02/15 22:08:54.848085, 10, pid=81113, effective(66639, 0), real(66639, 0), traceid=105] ../../source3/libads/kerberos.c:259(kerberos_kinit_generic_once)
  kerberos_kinit_generic_once: calling krb5_cc_initialize
[2026/02/15 22:08:54.848154, 10, pid=81113, effective(66639, 0), real(66639, 0), traceid=105] ../../source3/libads/kerberos.c:261(kerberos_kinit_generic_once)
  kerberos_kinit_generic_once: krb5_cc_initialize return value was: -1, going to out label
[2026/02/15 22:08:54.848177, 10, pid=81113, effective(66639, 0), real(66639, 0), traceid=105] ../../source3/libads/authdata.c:196(kerberos_return_pac)
  kerberos_return_pac: kerberos_kinit_password_ext return value was: -1
[2026/02/15 22:08:54.848183,  1, pid=81113, effective(66639, 0), real(66639, 0), traceid=105] ../../source3/libads/authdata.c:199(kerberos_return_pac)
  kinit failed for 'david@FILLINGHAM@AD.FILLINGHAM.AU' with: Unknown error -1 (-1)
[2026/02/15 22:08:54.848194, 10, pid=81113, effective(0, 0), real(0, 0), class=winbind, traceid=105] ../../source3/winbindd/winbindd_pam.c:887(winbindd_raw_kerberos_login)
  winbindd_raw_kerberos_login: after calling kerberos_return_pac, result was not NT_STATUS_IS_OK
[2026/02/15 22:08:54.848202,  3, pid=81113, effective(0, 0), real(0, 0), class=winbind, traceid=105] ../../source3/winbindd/winbindd_pam.c:975(winbindd_raw_kerberos_login)
  winbindd_raw_kerberos_login: could not remove ccache for user FILLINGHAM\david


sssd-kcm logs do not show that it was contacted at these timestamps