[Pkg-samba-maint] Bug#1001053: also being affected

[Daniel Lakeland]

My wife has a dual mirrored glusterfs file server that is used for 
central storage of biology research data. They'd been running old 
versions of Debian, until one of them had a hard drive failure. After 
replacing hardware and installing the latest Debian release, upgrading 
the other machine, and synchronizing the gluster fileserver, now no-one 
can access the server because they are experiencing something similar to 
this bug.

She's running a vanilla old school OpenLDAP/Mit Krb5 system as described.

Here are logs with level 3 from an attempted connection:

[2022/04/12 16:01:14.492911,  1] 
../../source3/librpc/crypto/gse_krb5.c:179(fill_mem_keytab_from_secrets)
   fill_mem_keytab_from_secrets: 
secrets_fetch_or_upgrade_domain_info(MARIANILAB.NET) - 
NT_STATUS_CANT_ACCESS_DOMAIN_INFO
[2022/04/12 16:01:14.493014,  3] 
../../source3/librpc/crypto/gse_krb5.c:570(gse_krb5_get_server_keytab)
   ../../source3/librpc/crypto/gse_krb5.c:570: Warning! Unable to set 
mem keytab from secrets!
[2022/04/12 16:01:14.494598,  3] 
../../source3/smbd/negprot.c:776(reply_negprot)
   Selected protocol SMB 2.???
[2022/04/12 16:01:14.496032,  3] 
../../source3/smbd/smb2_negprot.c:293(smbd_smb2_request_process_negprot)
   Selected protocol SMB3_02
[2022/04/12 16:01:14.496813,  1] 
../../source3/librpc/crypto/gse_krb5.c:179(fill_mem_keytab_from_secrets)
   fill_mem_keytab_from_secrets: 
secrets_fetch_or_upgrade_domain_info(MARIANILAB.NET) - 
NT_STATUS_CANT_ACCESS_DOMAIN_INFO
[2022/04/12 16:01:14.496887,  3] 
../../source3/librpc/crypto/gse_krb5.c:570(gse_krb5_get_server_keytab)
   ../../source3/librpc/crypto/gse_krb5.c:570: Warning! Unable to set 
mem keytab from secrets!
[2022/04/12 16:01:14.646176,  1] 
../../source3/librpc/crypto/gse_krb5.c:179(fill_mem_keytab_from_secrets)
   fill_mem_keytab_from_secrets: 
secrets_fetch_or_upgrade_domain_info(MARIANILAB.NET) - 
NT_STATUS_CANT_ACCESS_DOMAIN_INFO
[2022/04/12 16:01:14.646273,  3] 
../../source3/librpc/crypto/gse_krb5.c:570(gse_krb5_get_server_keytab)
   ../../source3/librpc/crypto/gse_krb5.c:570: Warning! Unable to set 
mem keytab from secrets!
[2022/04/12 16:01:14.648899,  2] 
../../auth/kerberos/gssapi_pac.c:168(gssapi_obtain_pac_blob)
   obtaining PAC via GSSAPI gss_inquire_sec_context_by_oid (Heimdal OID) 
failed:  Miscellaneous failure (see text): Ticket have not authorization 
data of type 128
[2022/04/12 16:01:14.648992,  3] 
../../auth/gensec/gensec_util.c:73(gensec_generate_session_info_pac)
   gensec_generate_session_info_pac: Unable to find PAC for 
fmariani at MARIANILAB.NET, resorting to local user lookup
[2022/04/12 16:01:14.649062,  3] 
../../source3/auth/user_krb5.c:50(get_user_from_kerberos_info)
   Kerberos ticket principal name is [fmariani at MARIANILAB.NET]
[2022/04/12 16:01:14.658003,  3] 
../../source3/auth/user_krb5.c:123(get_user_from_kerberos_info)
   get_user_from_kerberos_info: Username MARIANILAB.NET\fmariani is 
invalid on this system
[2022/04/12 16:01:14.658102,  3] 
../../source3/auth/auth_generic.c:222(auth3_generate_session_info_pac)
   auth3_generate_session_info_pac: Failed to map kerberos principal to 
system user (NT_STATUS_LOGON_FAILURE)
[2022/04/12 16:01:14.658254,  3] 
../../source3/smbd/smb2_server.c:3861(smbd_smb2_request_error_ex)
   smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] 
status[NT_STATUS_ACCESS_DENIED] || at 
../../source3/smbd/smb2_sesssetup.c:146


I'm not sure if this is the same bug, or a related bug.


The version installed is as follows:

root at manticore:/var/log/samba# apt policy samba
samba:
   Installed: 2:4.13.14+dfsg-1+b2
   Candidate: 2:4.13.14+dfsg-1+b2
   Version table:
  *** 2:4.13.14+dfsg-1+b2 500
         500 http://deb.debian.org/debian testing/main amd64 Packages
         100 /var/lib/dpkg/status
      2:4.13.13+dfsg-1~deb11u3 500
         500 http://deb.debian.org/debian stable/main amd64 Packages


It also happened under the 4.13.13+dfsg-1~deb11u3 version, I upgraded to 
the testing version in hopes it might have been fixed, but isn't.

Is this the same bug, or a different bug that needs a different fix?