Client authentication error "Failed to convert SID ... to a PID"

[Daniel Schwarzloh]

After an unattended upgrade to samba 2:4.7.6+dfsg~ubuntu-0ubuntu2.26 on our fileserver, clients are not able to establish a connection to samba-shares. The fileserver serves as a domain member server with an ldap on a different machine (see output of testparm below).

Given the correct login credentials, the client responds with:
tree connect failed: NT_STATUS_ACCESS_DENIED
and the client specific samba-logfile on the fileserver will show:
 [2021/12/09 15:04:29.783978, 0] ../source3/auth/auth_util.c:1259(check_account)
    check_account: Failed to convert SID S-1-2-34-5678910-11121314-15161718-192021 to a UID (dom_user[MYDOMAIN\myusername])

A wrong password in a client throws:
session setup failed: NT_STATUS_LOGON_FAILURE

The config was working fine until the unattended upgrade from samba 2:4.7.6+dfsg~ubuntu-0ubuntu2.23 to 2:4.7.6+dfsg~ubuntu-0ubuntu2.26

I have tried to reproduce the behaviour on an Ubuntu 20.04.3 LTS with samba 4.13.14 and ran into the same error.

This is the testparm output of the fileserver:
# Global parameters
[global]
 client min protocol = default
 dns proxy = No
 log file = /var/log/samba/log.%m
 map to guest = Bad User
 max log size = 1000
 pam password change = Yes
 panic action = /usr/share/samba/panic-action %d
 passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
 passwd program = /usr/bin/passwd %u
 password server = 12.345.678.9
 security = DOMAIN
 server min protocol = SMB2
 server role = member server
 server string = MYDOMAIN Fileserver
 syslog = 0
 unix extensions = No
 unix password sync = Yes
 usershare allow guests = Yes
 workgroup = WG_TECH
 idmap config * : backend = tdb
 veto files = /someVetoFile/moreVetoFiles/
 wide links = Yes

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Roberto (roberto-colnaghi)]

Same here, my configuration is more or less similar to the OP's. After the update, the domain users authenticate successfully on their Windows client machines against the Samba DC, so both LDAP and authentication seem to work (I also use the same LDAP records for authentication of other software, so that definitely works). Once authenticated, when they try to access a Samba server (which is a member of the domain), they are asked for their credentials (which obviously don't work, otherwise they wouldn't be asked, 'cause they're domain credentials).

[Rigo Schultz (schultz-h)]

Also same here. NT4 Domain Member Server, without Winbind. Users and groups are resolved via NSS. After downgrading Samba and related packages to 2:4.7.6+dfsg~ubuntu-0ubuntu2 everything works again.

[2021/12/10 14:36:15.923981, 0] ../source3/auth/auth_util.c:1259(check_account)
  check_account: Failed to convert SID S-1-5-21-1954734479-671598338-2648087304-6696 to a UID (dom_user[MYDOMAIN\myusername])

[Roberto (roberto-colnaghi)]

Oh yes, I forgot to mention: NT4 Domain Member Server users and groups are resolved vis NSS/LDAP, no winbind, as Rigo Schultz' setup. And I confirm, downgrading Samba solves the issue, I'm actually keeping the new version for the DC, and everything seems to be running fine.

[Lorenzo Capanna (capanna-n)]

I think I've found the problem:
Quoting from the last patch:

From: Ralph Boehme <email address hidden>
Date: Fri, 8 Oct 2021 12:33:16 +0200
Subject: [PATCH 138/284] CVE-2020-25717: s3:auth: remove fallbacks in
 smb_getpwnam()

So far we tried getpwnam("DOMAIN\account") first and
always did a fallback to getpwnam("account") completely
ignoring the domain part, this just causes problems
as we mix "DOMAIN1\account", "DOMAIN2\account",
and "account"!

As we require a running winbindd for domain member setups
we should no longer do a fallback to just "account" for
users served by winbindd!

For users of the local SAM don't use this code path,
as check_sam_security() doesn't call check_account().

The only case where smb_getpwnam("account") happens is
when map_username() via ("username map [script]") mapped
"DOMAIN\account" to something without '\', but that is
explicitly desired by the admin.

-- end quote ---

So I've configured the smb.conf with:
username map script = /export/sbin/remove_domain.pl

to strip the domain from the username

This is a very basic perl script ( DONT USE THIS )

#!/usr/bin/perl -w

$username=$ARGV[0];
chomp $username;

if ($username =~ /^LABTA\\([a-zA-Z0-9\-]+)$/ ){
    $username = $1;
    print "$username\n";
}

With this configuration the 4.7.6+dfsg~ubuntu-0ubuntu2.26 starts to work.

[Christian Ehrhardt  (paelzer)]

Hi,
yes the security fixes in https://launchpad.net/ubuntu/+source/samba/2:4.7.6+dfsg~ubuntu-0ubuntu2.26 might have affected that. Thanks Lorenzo for already identifying a candidate and a config based workaround.

Assigning to security-team to have a look (as usual) at update regressions.

[Marc Deslauriers (mdeslaur)]

Unfortunately the whole point of the security update was to change how name lookups work. There is more information on the changes in the upstream advisory here:

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

[Marc Deslauriers (mdeslaur)]

I have uploaded packages that include an additional regression fix into the security team PPA here:

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

[Marc Deslauriers (mdeslaur)]

The following updates may help with this issue in certain environments:

https://ubuntu.com/security/notices/USN-5174-2
https://ubuntu.com/security/notices/USN-5142-3

[Roberto (roberto-colnaghi)]

Thank you. I've tried to install the new version of the package for our release (18.04), samba - 2:4.7.6+dfsg~ubuntu-0ubuntu2.27, as suggested by Marc Deslauriers. Unfortunately I see the same behavior, so I had to roll back again.

[Jared Heath (jheath-snc)]

I have this problem in all our environments.

I see this in the above quote from the patch...."As we require a running winbindd for domain member setups"

Since when? We don't use winbindd and never have....this worked until this week.

[Roberto (roberto-colnaghi)]

We too have never used winbind, same as Jared Heath. Maybe that's the reason why the update still doesn't solve the problem in our environment.