1

We are using Ubuntu 20.04 LTS on some servers, including a Samba Active Directory DC and a Samba File Server using winbind authentication.

On Nov 12th, an unattended upgrade (related to USN-5142-1) upgraded our Samba 4.11.6 to 4.13.14 on these servers and that sent us into lots of troubles.

1/ vfs_full_audit options changed ( https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1950803 ) Some audit options were not valid anymore and audit started to log everything .. our /var exploded in no time. This got fixed by changing vfs_audit options in smb.conf

2/ AD users with Unix Attribute uidnumber < 1000 were not able to access Samba file shares anymore. Huge issue as most of our users were out of work for almost a day.. probably related to the "min domain uid" global parameter wich is set to 1000 by default. In the rush we fixed the issue by changing uidnumber of all of our users to values above 1000. Weirdly enough, AD users were still able to SSH on the server using winbind authentication and unix uid < 1000.

3/ Issues with CIFS mounts and Printers SMB configurations before the upgrade, CIFS mounts and printers used their username to authenticate on the Samba File Server. Since the upgrade, it seems mandatory to indicate the domain name (add option domain=MYDOMAIN for mount.cifs and set username to MYDOMAIN\user for printers) This domain prefix used to be implicit thanks to the "winbind use default domain = yes" option.

If anybody knows how to fix this we'd be really interested !

4/ AD built-in "Administrator" account can no longer access the Samba file server. This account is mapped to "root" on the File Server. The error message is related to some invalid data token, just like users that were denied in 2/. This account does not have Unix Attributes but it always worked that way. i'm not sure wether I should add it. I don't like changing built-in accounts.

At this time we're still investigating and your help would be very welcome !

All in all I have to say this was a pretty traumatic experience from unattended upgrades, we're now doing our best to get back on track with our setup.

Thanks for reading.

References https://ubuntu.com/security/notices/USN-5142-1

Improve this question
0

1 Answer 1

Reset to default
0

Adding my experience to this one, particularly for smb printing. Post samba update to 4.13.14 /var/log/cups/error_log reports the following when trying to print:

[Client 1234567] User "foo" does not exist

The workaround at this point is to getent passwd | grep "foo" to generat a passwd entry and paste into /etc/passwd using vipw. This is not ideal on a mass scale as one could imagine.

I'm convinced this is a configuration issue if I only know what to configure. All our CUPS, samba, winbind etc configs are set as correctly as I know how but this is all pre 4.13.14. Looking at the change history 4.13.14 "fixed" a lot of AD/kerberos issues and I suspect some of those were unintentionally relied upon for this stuff to work.

Improve this answer
1
  • finally got around to spending some time on this. in by custom /usr/lib/cups/backend/smb I needed to replace calls to smbspool with the following export AUTH_INFO_REQUIRED="negotiate" export AUTH_UID="$(id -u ${strUserName})" /usr/lib/x86_64-linux-gnu/samba/smbspool_krb5_wrapper ...etc from what I've read, in simpler printing setups you should be able to just symlink /usr/lib/x86_64-linux-gnu/samba/smbspool_krb5_wrapper to /usr/lib/cups/backend/smb
    – bartron
    Sep 2, 2022 at 11:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .