Ubuntu 20.04 LTS - Actualizarea nesupravegheată Samba ne-a rupt configurația

Utilizăm Ubuntu 20.04 LTS pe unele servere, inclusiv un Samba Active Directory DC și un Samba File Server care utilizează autentificarea winbind.

Pe 12 noiembrie, o actualizare nesupravegheată (legată de USN-5142-1) ne-a actualizat Samba 4.11.6 la 4.13.14 pe aceste servere și asta ne-a trimis în multe probleme.

1/ opțiunile vfs_full_audit schimbate ( https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1950803 ) Unele opțiuni de audit nu mai erau valabile și auditul a început să înregistreze totul.. /varul nostru a explodat în cel mai scurt timp. Acest lucru a fost rezolvat prin schimbarea opțiunilor vfs_audit în smb.conf

2/ Utilizatorii AD cu un număr uid de atribut Unix < 1000 nu au mai putut accesa partajările de fișiere Samba. Problemă uriașă, deoarece majoritatea utilizatorilor noștri au rămas fără serviciu aproape o zi.. probabil legată de parametrul global „min domain uid”, care este setat implicit la 1000. În grabă, am remediat problema schimbând numărul uid al tuturor utilizatorilor noștri la valori peste 1000. În mod ciudat, utilizatorii AD au putut încă să facă SSH pe server folosind autentificarea winbind și unix uid <1000.

3/ Probleme cu monturile CIFS și configurațiile SMB ale imprimantelor înainte de actualizare, monturile și imprimantele CIFS și-au folosit numele de utilizator pentru a se autentifica pe serverul de fișiere Samba. De la upgrade, pare obligatoriu să se indice numele domeniului (adăugați opțiunea domain=MYDOMAIN pentru mount.cifs și setați numele de utilizator la MYDOMAIN\user pentru imprimante) Acest prefix de domeniu era implicit implicit datorită opțiunii „winbind use default domain = yes”.

Dacă știe cineva cum să rezolvăm asta, am fi cu adevărat interesați!

4/ Contul „Administrator” încorporat AD nu mai poate accesa serverul de fișiere Samba.Acest cont este mapat la „rădăcină” pe serverul de fișiere. Mesajul de eroare este legat de un simbol de date nevalid, la fel ca utilizatorii care au fost refuzați în 2/. Acest cont nu are atribute Unix, dar a funcționat întotdeauna așa. nu sunt sigur dacă ar trebui să-l adaug. Nu-mi place să schimb conturile încorporate.

În acest moment, încă investigăm și ajutorul tău ar fi foarte binevenit!

Una peste alta, trebuie să spun că aceasta a fost o experiență destul de traumatizantă de la upgrade-uri nesupravegheate, acum facem tot posibilul pentru a reveni pe drumul cel bun cu configurarea noastră.

Multumesc pentru lectura.

Referințe https://ubuntu.com/security/notices/USN-5142-1

Adăugând experiența mea la aceasta, în special pentru imprimarea smb. Postați actualizarea samba la 4.13.14 /var/log/cups/error_log raportează următoarele când încercați să imprimați:

[Client 1234567] Utilizatorul „foo” nu există

Soluția în acest moment este să getent passwd | grep "foo" pentru a genera o intrare passwd și a lipi în /etc/passwd folosind vipw. Acest lucru nu este ideal la scară de masă, așa cum s-ar putea imagina.

Sunt convins că aceasta este o problemă de configurare dacă știu doar ce să configurez. Toate configurațiile noastre CUPS, samba, winbind etc sunt setate la fel de corect pe cât știu, dar toate acestea sunt înainte de 4.13.14. Privind istoricul modificărilor 4.13.14, a „remediat” o mulțime de probleme AD/kerberos și bănuiesc că unele dintre acestea s-au bazat în mod neintenționat pentru ca aceste lucruri să funcționeze.