[Samba] smbd interoperability with sssd on Kerberos no winbind

[Household Cang]

Hello there

Seeking to serve file shares from AD-joined Debian using sssd and Kerberos as authentication. No Winbind.

Having a lot of problems and confusions...

Current smb.conf, no winbind
[global]
   workgroup = company.net
   realm = company.net
   security = user
   kerberos method = dedicated keytab
   dedicated keytab file = /etc/krb5.keytab
   
   disable netbios = yes
   dns proxy = yes
   ntlm auth = no
   lanman auth = no
   log level = 5

With security = user, I am getting in log.smbd
[2024/07/12 15:02:01.584434,  5] ../../libcli/security/security_token.c:47(security_token_debug)
  Security token: (NULL)
[2024/07/12 15:02:01.584437,  5] ../../source3/auth/token_util.c:873(debug_unix_user_token)
  UNIX token of user 0
  Primary group is 0 and contains 0 supplementary groups
[2024/07/12 15:02:01.584453,  4] ../../source3/passdb/pdb_tdb.c:560(tdbsam_open)
  tdbsam_open: successfully opened /var/lib/samba/private/passdb.tdb
# COMMENT: passdb.tdb is probably a local user list. Security = user, would probably trigger a lookup in a local file, is there any way to backend this db file to sssd, or manually construct a passdb.tdb file to contain a handful of AD users?
[2024/07/12 15:02:01.584458,  5] ../../source3/passdb/pdb_tdb.c:660(tdbsam_getsampwrid)
  pdb_getsampwrid (TDB): error looking up RID 514 by key RID_00000202.
[2024/07/12 15:02:01.584464,  4] ../../source3/smbd/sec_ctx.c:443(pop_sec_ctx)
  pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 1
[2024/07/12 15:02:01.584467,  5] ../../source3/passdb/pdb_interface.c:1848(lookup_global_sam_rid)
  Can't find a unix id for an unmapped group
# COMMENT: I don't know why it still attempts to idmap in the absence of Winbind. Could it just resort to system user ids? And sssd should provide this user id, since id <ad_user> works.
[2024/07/12 15:02:01.584470,  5] ../../source3/passdb/pdb_interface.c:1555(pdb_default_sid_to_id)
  SID S-1-5-21-***-***-***-514 belongs to our domain, but there is no corresponding object in the database
# COMMENT: So it is reading someone's Windows SID, as I made a mount -o sec=krb5 from another AD-joined Linux machine to it. The SID combined with the RID seems to mean the Domain Admins. Then, obviously this group is not present in the passdb.tdb because the tdb does not reflect the entire AD.

I asked ChatGPT and Google Gemini a lot about this, and they all insist I should change security = user to security = ads, but, according to man smb.conf, security = ads can only be used when the net utilities were used to join the computer into the domain, which was not the case.

Changing to security = ads results in a different error, this time, in log.smbd
[2024/07/12 17:49:16.409171,  5] ../../source3/librpc/crypto/gse.c:301(gse_init_client)
  smb_gss_krb5_import_cred ccache[MEMORY:prtpub_cache] failed with [ Miscellaneous failure (see text): unknown mech-code 2 for mech 1 2 840 113554 1 2 2] -the caller may retry after a kinit.
# COMMENT: sssd could successfully sign user in with Kerberos, so not sure why this error. This seems to be using the /etc/krb5.keytab file.
[2024/07/12 17:49:16.409184,  4] ../../auth/gensec/gensec_start.c:851(gensec_start_mech)
  Failed to start GENSEC client mech gse_krb5: NT_STATUS_INTERNAL_ERROR
[2024/07/12 17:49:16.409192,  1] ../../auth/gensec/spnego.c:418(gensec_spnego_create_negTokenInit_step)
  gensec_spnego_create_negTokenInit_step: Failed to setup SPNEGO negTokenInit request
[2024/07/12 17:49:16.409197,  5] ../../auth/gensec/gensec.c:534(gensec_update_done)
  gensec_update_done: spnego[0x58220592ca10]: NT_STATUS_INVALID_PARAMETER
[2024/07/12 17:49:16.409205,  1] ../../source3/libads/sasl.c:639(ads_sasl_spnego_bind)
  ads_sasl_spnego_gensec_bind(KRB5) failed for ldap/<dc.company.net> with user[<machine name>$] realm=[COMPANY.NET]: Cannot read password
# COMMENT: not sure what kind of password is smbd reading here, the machine password in /var/lib/samba/private/secrets.tdb? Isn't it supposed to exclusively use the dedicated keytab file?

Any help greatly appreciated.
Lucas.