Your message dated Fri, 15 Apr 2022 16:14:23 +0300
with message-id <[email protected]>
and subject line Re: Configuration with non SMB (MIT-kerberos) broken after
4.13.13+dfsg-1~deb11u2 security patch
has caused the Debian Bug report #1001053,
regarding Configuration with non SMB (MIT-kerberos) broken after
4.13.13+dfsg-1~deb11u2 security patch
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1001053: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001053
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: samba
Version: 4.13.13+dfsg-1~deb11u2
Hello,
My organisation are running an custom bulit LDAP/MIT-kerberos realm
(the KDCs are not runnning MIT-kerberos through Samba, just standalone
installations). For years have configured this KDCs to be used for two
important Debian (now running Bullseye) based file-servers. We are
both serving NFSv4 and Windows SMB clients. I resently upgraded the
servers with the lastest debian-security update with samba
(2:4.13.13+dfsg-1~deb11u2), and suddently all windows-clients reported
access denied while connecting to the samba servers.
I assume our troubles are related to this security issue:
https://www.samba.org/samba/security/CVE-2020-25719.html
Which is reffered to in the debian package:
https://tracker.debian.org/news/1279235/accepted-samba-241313dfsg-1deb11u2-source-into-proposed-updates-stable-new-proposed-updates/
I asume the problems is caused by our KDCs not issuing PACs while
issuing tickets.
Any advice on how to handle this issue? Either disable PAC-check on
the servers, do some configuration that stil will allow connections,
or configure our KDCs to inclued PACs in their tickers.
I am able to uinstall the secuirty patch on the servers for now, so at
least our users can maintain their workflow, but I realize this is a
short time soulution.
The servers' smb.conf:
[global]
workgroup = EXAMPLE.COM
server string = NAS server (samba)
server role = standalone server
security = user
realm = EXAMPLE.COM
encrypt passwords = yes
kerberos method = dedicated keytab
dedicated keytab file = /etc/krb5.keytab
password server = example-kdc-server.example.com
dns proxy = no
log file = /var/log/samba/log.%m
max log size = 1000
syslog = 0
panic action = /usr/share/samba/panic-action %d
map to guest = bad user
Log-file from the server:
[2021/12/03 08:47:46.876654, 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
[2021/12/03 08:47:46.876663, 3]
../../auth/gensec/gensec_util.c:73(gensec_generate_session_info_pac)
gensec_generate_session_info_pac: Unable to find PAC for
[email protected], resorting to local user lookup
[2021/12/03 08:47:46.876670, 3]
../../source3/auth/user_krb5.c:50(get_user_from_kerberos_info)
Kerberos ticket principal name is [[email protected]]
[2021/12/03 08:47:46.876684, 5]
../../source3/lib/username.c:181(Get_Pwnam_alloc)
Finding user EXAMPLE.COM\example_user
[2021/12/03 08:47:46.876690, 5]
../../source3/lib/username.c:120(Get_Pwnam_internals)
Trying _Get_Pwnam(), username as lowercase is EXAMPLE.COM\example_user
[2021/12/03 08:47:46.896429, 5]
../../source3/lib/username.c:127(Get_Pwnam_internals)
Trying _Get_Pwnam(), username as given is EXAMPLE.COM\example_user
[2021/12/03 08:47:46.904156, 5]
../../source3/lib/username.c:140(Get_Pwnam_internals)
Trying _Get_Pwnam(), username as uppercase is EXAMPLE.COM\example_user
[2021/12/03 08:47:46.912256, 5]
../../source3/lib/username.c:152(Get_Pwnam_internals)
Checking combinations of 0 uppercase letters in EXAMPLE.COM\example_user
[2021/12/03 08:47:46.912297, 5]
../../source3/lib/username.c:158(Get_Pwnam_internals)
Get_Pwnam_internals didn't find user [EXAMPLE.COM\example_user]!
[2021/12/03 08:47:46.912312, 3]
../../source3/auth/user_krb5.c:123(get_user_from_kerberos_info)
get_user_from_kerberos_info: Username EXAMPLE.COM\example_user is
invalid on this system
[2021/12/03 08:47:46.912330, 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)
Output from smbclient (with samba samba=2:4.13.13+dfsg-1~deb11u2)
smbclient -d 5 -k -L //example-file-server
sitename_fetch: No stored sitename for realm '[email protected]'
name example-file-server#20 found.
Socket options:
SO_KEEPALIVE = 0
SO_REUSEADDR = 0
SO_BROADCAST = 0
TCP_NODELAY = 1
TCP_KEEPCNT = 9
TCP_KEEPIDLE = 7200
TCP_KEEPINTVL = 75
IPTOS_LOWDELAY = 0
IPTOS_THROUGHPUT = 0
SO_REUSEPORT = 0
SO_SNDBUF = 46080
SO_RCVBUF = 131072
SO_SNDLOWAT = 1
SO_RCVLOWAT = 1
SO_SNDTIMEO = 0
SO_RCVTIMEO = 0
TCP_QUICKACK = 1
TCP_DEFER_ACCEPT = 0
TCP_USER_TIMEOUT = 0
session request ok
negotiated dialect[SMB3_11] against server[example-file-server]
cli_session_setup_spnego_send: Connect to example-file-server as
[email protected] using SPNEGO
GENSEC backend 'gssapi_spnego' registered
GENSEC backend 'gssapi_krb5' registered
GENSEC backend 'gssapi_krb5_sasl' registered
GENSEC backend 'spnego' registered
GENSEC backend 'schannel' registered
GENSEC backend 'naclrpc_as_system' registered
GENSEC backend 'sasl-EXTERNAL' registered
GENSEC backend 'ntlmssp' registered
GENSEC backend 'ntlmssp_resume_ccache' registered
GENSEC backend 'http_basic' registered
GENSEC backend 'http_ntlm' registered
GENSEC backend 'http_negotiate' registered
GENSEC backend 'krb5' registered
GENSEC backend 'fake_gssapi_krb5' registered
Starting GENSEC mechanism spnego
Starting GENSEC submechanism gse_krb5
SPNEGO login failed: {Access Denied} A process has requested access to
an object but has not been granted those access rights.
session setup failed: NT_STATUS_ACCESS_DENIED
Output from smbclient (with samba samba=2:4.13.5+dfsg-2)
smbclient -d 5 -k -L //example-file-server
sitename_fetch: No stored sitename for realm 'EXAMPLE.COM'
name example-file-server#20 found.
Socket options:
SO_KEEPALIVE = 0
SO_REUSEADDR = 0
SO_BROADCAST = 0
TCP_NODELAY = 1
TCP_KEEPCNT = 9
TCP_KEEPIDLE = 7200
TCP_KEEPINTVL = 75
IPTOS_LOWDELAY = 0
IPTOS_THROUGHPUT = 0
SO_REUSEPORT = 0
SO_SNDBUF = 2626560
SO_RCVBUF = 131072
SO_SNDLOWAT = 1
SO_RCVLOWAT = 1
SO_SNDTIMEO = 0
SO_RCVTIMEO = 0
TCP_QUICKACK = 1
TCP_DEFER_ACCEPT = 0
TCP_USER_TIMEOUT = 0
session request ok
negotiated dialect[SMB3_11] against server[example-file-server]
cli_session_setup_spnego_send: Connect to example-file-server as
[email protected] using SPNEGO
GENSEC backend 'gssapi_spnego' registered
GENSEC backend 'gssapi_krb5' registered
GENSEC backend 'gssapi_krb5_sasl' registered
GENSEC backend 'spnego' registered
GENSEC backend 'schannel' registered
GENSEC backend 'naclrpc_as_system' registered
GENSEC backend 'sasl-EXTERNAL' registered
GENSEC backend 'ntlmssp' registered
GENSEC backend 'ntlmssp_resume_ccache' registered
GENSEC backend 'http_basic' registered
GENSEC backend 'http_ntlm' registered
GENSEC backend 'http_negotiate' registered
GENSEC backend 'krb5' registered
GENSEC backend 'fake_gssapi_krb5' registered
Starting GENSEC mechanism spnego
Starting GENSEC submechanism gse_krb5
session setup ok
signed SMB2 message
tconx ok
Sharename Type Comment
--------- ---- -------
Bind RPC Pipe: host example-file-server auth_type 0, auth_level 1
rpc_api_pipe: host example-file-server
rpc_read_send: data_to_read: 52
check_bind_response: accepted!
rpc_api_pipe: host example-file-server
rpc_read_send: data_to_read: 568
share1 Disk 1TB (Jbod/disc grinder)
usbpool Disk USBs
share2 Disk 16TB (Raid5 in 5x4TB disks)
health-logs Disk Disk health logs
IPC$ IPC IPC Service (NAS server (samba))
SMB1 disabled -- no workgroup available
--- End Message ---
--- Begin Message ---
Version: 2:4.16.0+dfsg-1
This is apparently fixed bu a 4.16 upload, and should be fixed
by the next stable(-security) update too.
Thanks,
/mjt
--- End Message ---
