Fixed user mapping broken in Samba 2:4.7.6+dfsg~ubuntu-0ubuntu2.26

[Norbert B.]

Samba upgrade from 2:4.7.6+dfsg~ubuntu-0ubuntu2 to 2:4.7.6+dfsg~ubuntu-0ubuntu2.26 breaks fixed user mapping

Environment:
Operating System: Ubuntu 18.04.6 LTS
Kernel: Linux 5.4.0-1058-oracle (Oracle OCI kernel)

apt list -a samba
samba/bionic-updates,bionic-security,now 2:4.7.6+dfsg~ubuntu-0ubuntu2.26 amd64 [installed]
samba/bionic 2:4.7.6+dfsg~ubuntu-0ubuntu2 amd64

/etc/samba/smb.conf (relevant parts):
[global]
   workgroup = DOMAIN
   security = ADS
   realm = DOMAIN.TLD
   idmap config * : backend = tdb
   idmap config * : range = 3000-99999
   idmap config DOMAIN : backend = rid
   idmap config DOMAIN : range = 100000-199999
   username map = /etc/samba/user.map
   winbind refresh tickets = Yes
   vfs objects = acl_xattr
   map acl inherit = Yes
   dedicated keytab file = /etc/krb5.keytab
   kerberos method = secrets and keytab

/etc/samba/user.map:
!root = DOMAIN\Administrator

Expected behaviour (running without problems in 2:4.7.6+dfsg~ubuntu-0ubuntu2)
User DOMAIN\Administrator has access as root to all Samba shares.

Behaviour after (unattended) upgrade to 2:4.7.6+dfsg~ubuntu-0ubuntu2.26:

Changes:
/var/log/unattended-upgrades/unattended-upgrades.log
2021-12-08 06:59:55,179 INFO Packages that will be upgraded: busybox-initramfs busybox-static libnss-winbind libwbclient0 python-samba samba samba-common samba-common-bin samba-dsdb-modules samba-libs samba-vfs-modules winbind

Problem:
User DOMAIN\Administrator (mapped as user root on samba server) has no more access to any Samba shares.

Detailed problem description:

Attempt to access Samba shares from Windows (Server 2016, current patch level).
Errors differ if Client for NFS is installed in Windows or not.
When Client for NFS ist installed, Windows tries to connect with NFS first, so remove it for testing or results will be false (ERROR_INVALID_TOKEN).

Trying to acces Samba with SMB results in immediate error:

[Window Title]
Network Error
[Main Instruction]
Windows cannot access \\sambaserver
[Content]
Check the spelling of the name. Otherwise, there might be a problem with your network. To try to identify and resolve network problems, click Diagnose.
[^] Hide details [Diagnose] [Cancel]
[Expanded Information]
Error code: 0x80070035
The network path was not found.

I could not find any corresponding log file entry on Samba server in any log.

IMPORTANT: Attempt to connect as regular AD domain user from SAME server (Map network drive using different credentials) works without any problem.

After rolling back all packages to 2:4.7.6+dfsg~ubuntu-0ubuntu2 everything works without problems again:

apt install libnss-winbind=2:4.7.6+dfsg~ubuntu-0ubuntu2 libsmbclient=2:4.7.6+dfsg~ubuntu-0ubuntu2 libwbclient0=2:4.7.6+dfsg~ubuntu-0ubuntu2 python-samba=2:4.7.6+dfsg~ubuntu-0ubuntu2 samba=2:4.7.6+dfsg~ubuntu-0ubuntu2 samba-common=2:4.7.6+dfsg~ubuntu-0ubuntu2 samba-common-bin=2:4.7.6+dfsg~ubuntu-0ubuntu2 samba-dsdb-modules=2:4.7.6+dfsg~ubuntu-0ubuntu2 samba-libs=2:4.7.6+dfsg~ubuntu-0ubuntu2 samba-vfs-modules=2:4.7.6+dfsg~ubuntu-0ubuntu2 smbclient=2:4.7.6+dfsg~ubuntu-0ubuntu2 winbind=2:4.7.6+dfsg~ubuntu-0ubuntu2

# I hope that prevents from further unattended upgrade till the bug is fixed:
apt-mark hold libnss-winbind libsmbclient libwbclient0 python-samba samba samba-common samba-common-bin samba-dsdb-modules samba-libs samba-vfs-modules smbclient winbind

[Marc Deslauriers (mdeslaur)]

I wonder if the new "min domain uid" parameter is related to this issue. See:

https://www.samba.org/samba/security/CVE-2020-25717.html

[Norbert B. (nbpq)]

It was my suspicion too.

Additional information:

In our environmant we have two domain controllers: DC1 and DC2
PAC patch for Windows as described in https://support.microsoft.com/en-us/topic/kb5008380-authentication-updates-cve-2021-42287-9dafac11-e0d0-4cb8-959a-143bd0201041 is currently installed only on DC2, but only in log level (not enforced).

Currently the samba server authenticates against DC1 without this patch.

[Norbert B. (nbpq)]

I tried the workaround

Setting "gensec:require_pac=true" in the smb.conf makes the
DOMAIN\user lookup succeed, due to a cache prime in winbind, provided
nss_winbind is in use and no error paths are hit.

Brought no effect on described problem. Access is not possible.

[Norbert B. (nbpq)]

Workaround:
min domain uid = 0
fixes the problem.

Theoretic the bug could be closed with this solution.
The remaining question is: What happens to other users, who are affected by this with unattended update.