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
fmari...@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 [fmari...@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@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?
