AD-joined Samba Server stops working after upgrade to 4.13.14+dfsg-0ubuntu0.20.04.1

[Andreas]

Ubuntu Release: Ubuntu 20.04.3 LTS
Package: samba 4.13.14+dfsg-0ubuntu0.20.04.1

Expected behavior:
I'm running a 20.04.03 LTS server joined into an AD-Domain via sssd.
Logging in via ssh works like fine.
The server also exports the user homes via samba, so the users can access
their homes e.g. via \\myserver\myusername from their Windows10 desktops
"just like that". The authentication via kerberos works flawlessly,
they do not have to provide a password.
That was the case for the system as long as it was running samba version 4.11.6.

What happens instead?
After a regular nightly system security update, the samba server
stack went from:

libsmbclient 2:4.11.6+dfsg-0ubuntu1.10 samba install ok installed
libwbclient0 2:4.11.6+dfsg-0ubuntu1.10 samba install ok installed
python3-samba 2:4.11.6+dfsg-0ubuntu1.10 samba install ok installed
samba 2:4.11.6+dfsg-0ubuntu1.10 hold ok installed
samba-common 2:4.11.6+dfsg-0ubuntu1.10 samba install ok installed
samba-common-bin 2:4.11.6+dfsg-0ubuntu1.10 samba install ok installed
samba-dsdb-modules 2:4.11.6+dfsg-0ubuntu1.10 samba install ok installed
samba-libs 2:4.11.6+dfsg-0ubuntu1.10 samba install ok installed
samba-vfs-modules 2:4.11.6+dfsg-0ubuntu1.10 samba install ok installed

to:

libsmbclient 2:4.13.14+dfsg-0ubuntu0.20.04.1 samba install ok installed
libwbclient0 2:4.13.14+dfsg-0ubuntu0.20.04.1 samba install ok installed
python3-samba 2:4.13.14+dfsg-0ubuntu0.20.04.1 samba install ok installed
samba 2:4.13.14+dfsg-0ubuntu0.20.04.1 install ok installed
samba-common 2:4.13.14+dfsg-0ubuntu0.20.04.1 samba install ok installed
samba-common-bin 2:4.13.14+dfsg-0ubuntu0.20.04.1 samba install ok installed
samba-dsdb-modules 2:4.13.14+dfsg-0ubuntu0.20.04.1 samba install ok installed
samba-libs 2:4.13.14+dfsg-0ubuntu0.20.04.1 samba install ok installed
samba-vfs-modules 2:4.13.14+dfsg-0ubuntu0.20.04.1 samba install ok installed

(aktually the following packages got updated:
libicu66 libipa-hbac0 libldb2 libsmbclient libsss-idmap0 libwbclient0 python3-ldb python3-samba python3-sss samba samba-common samba-common-bin samba-dsdb-modules samba-libs samba-vfs-modules sssd sssd-ad sssd-ad-common sssd-common sssd-ipa sssd-krb5 sssd-krb5-common sssd-ldap sssd-proxy sssd-tools)

After the update, the export of the user homes is not working anymore.
The Windows10 users are not able to reach it via "\\myserver\myusername".
The share is unavailable.

I can reproduce that behavior, by restoring an older snapshot
of that virtual server. It works fine at first (immediately after the
restore), but then -after an initiated package update- it stops working.

Here is my smb.conf:

-------------------------------------------------------
[global]
interfaces = lo ens160
bind interfaces only = yes
 realm = MYDOMA.IN
        kerberos method = secrets and keytab
   server string = %h server (Samba, Ubuntu)
   log file = /var/log/samba/log.%m
   max log size = 1000
   logging = file
   panic action = /usr/share/samba/panic-action %d
 log level = 3
   server role = standalone server
   obey pam restrictions = yes
   unix password sync = yes
   passwd program = /usr/bin/passwd %u
   passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
   pam password change = yes
   map to guest = bad user
   usershare allow guests = yes
[Homes]
    comment = User Homes
    path = /home/mydoma.in/%U
    browsable = yes
    valid users = %U
    force group = "Domain users"
    follow symlinks = yes
    wide links = no
    writable = yes
    read only = no
    force create mode = 0660
    create mask = 0777
    directory mask = 0777
    force directory mode = 0770
    access based share enum = yes
    hide unreadable = yes
----------------------------------------------------------

When trying to connect from a Windows10 client, the updated samba server (4.13.14) logs for that particular IP address show:

[2021/11/25 11:12:52.256505, 1] ../../source3/librpc/crypto/gse_krb5.c:179(fill_mem_keytab_from_secrets)
  fill_mem_keytab_from_secrets: secrets_fetch_or_upgrade_domain_info(WORKGROUP) - NT_STATUS_CANT_ACCESS_DOMAIN_INFO
[2021/11/25 11:12:52.256532, 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!
[2021/11/25 11:12:52.258626, 1] ../../source3/librpc/crypto/gse_krb5.c:179(fill_mem_keytab_from_secrets)
  fill_mem_keytab_from_secrets: secrets_fetch_or_upgrade_domain_info(WORKGROUP) - NT_STATUS_CANT_ACCESS_DOMAIN_INFO
[2021/11/25 11:12:52.258647, 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!
[2021/11/25 11:12:52.259947, 1] ../../source3/auth/auth_generic.c:209(auth3_generate_session_info_pac)
  auth3_generate_session_info_pac: Unexpected PAC for [myuser@MYDOMAIN] in standalone mode - NT_STATUS_BAD_TOKEN_TYPE
[2021/11/25 11:12:52.259983, 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_BAD_TOKEN_TYPE] || at ../../source3/smbd/smb2_sesssetup.c:146
[2021/11/25 11:12:52.260415, 3] ../../source3/smbd/server_exit.c:220(exit_server_common)
  Server exit (NT_STATUS_CONNECTION_RESET)

[Stefan Metzmacher (metze)]

Samba Team announced that domain member setups must use winbindd in 4.8.0:
https://www.samba.org/samba/history/samba-4.8.0.html in 2018.

In order to accept AD Kerberos authentication you need to configure the server as
domain member with 'security = ads' and without 'server role = standalone server'.

In your case you most likely want to configure idmap_nss (see man idmap_nss)
and run winbindd, but without nss_winbind.

Note the above implies the patches from
https://bugzilla.samba.org/show_bug.cgi?id=14901
are included.

Unrelated here but the patch from
https://bugzilla.samba.org/show_bug.cgi?id=14899
should also be applied.

[Andreas (adonut)]

While debugging this issue on our side, I stumbled upon this announcement of the Samba team as well
and it made me wonder why it had "just worked" until version 4.11.16.
So I concluded (obviously wrongly) that Ubuntu had patched their version in order
to keep this functionality alive and was willing to provide it in their 20.04 LTS branch.

Anyway thanks for the heads up.

Andreas

[Stefan Metzmacher (metze)]

It worked just by accident, the reason it worked was actually the security problem
that was fixed by the patches for https://www.samba.org/samba/security/CVE-2020-25717.html,
sadly they also broke valid setups with idmap_nss, which is fixed by
https://bugzilla.samba.org/show_bug.cgi?id=14901 and another problem was fixed by
https://bugzilla.samba.org/show_bug.cgi?id=14899

[Andreas (adonut)]

I see.

Thank you very much
Andreas

[Marc Deslauriers (mdeslaur)]

The packages released with USN-5142-1 did contain the fix for Samba bug #14899, but not for Samba bug #14901. I've uploaded updated packages that do fix bug #14901 in the security team's PPA here for testing:

https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages

If you do try them out, please let us know in this bug if that helped in your environment. Thanks!

[Utkarsh Gupta (utkarsh)]

Hello,

I believe this isn't a regular bug and doesn't need anything from the Server team here. As the Security team (Marc) said, this has apparently been fixed in the PPA and will be rolled out soon (if not already?).

Either way, with the hope things are under control, I am marking this as "Incomplete" in order to give some room for the reporter to verify and get back if things don't work out.

Let me know if I have mistaken or anything. Thank you! \o/