Wydanie Samba 4.24.0.

Po sześciu miesiącach prac, zaprezentowano wydanie Samba 4.24.0, które kontynuuje rozwój gałęzi Samba 4 z pełną implementacją kontrolera domeny oraz usługi Active Directory, zgodną z implementacją Windows Server i zdolną do obsługi wszystkich wspieranych wersji klientów Microsoft Windows, w tym Windows 11. Samba 4 jest wielofunkcyjnym produktem serwerowym, oferującym także realizację serwera plików, usługi drukowania i serwera identyfikacji (winbind). Kod projektu napisany jest w języku C i jest rozpowszechniany na licencji GPLv3.

Kluczowe zmiany w Samba 4.24:

  • Dodano nowy moduł VFS vfs_aio_ratelimit do ograniczania intensywności (rate-limit) operacji asynchronicznego wejścia/wyjścia (AIO). Ograniczenia mogą być ustalane w bajtach na sekundę lub w operacjach na sekundę. Po przekroczeniu ustalonego limitu, moduł zaczyna wprowadzać sztuczne opóźnienia w operacjach asynchronicznych, aby utrzymać zadany górny próg.
  • Do modułu VFS vfs_ceph_new dodano wsparcie dla protokołu RPC Keybridge oraz trybu FSCrypt do szyfrowania danych i nazw plików w systemie plików CephFS. Możliwe jest włączenie szyfrowania na poziomie poszczególnych katalogów.
  • W module VFS vfs_streams_xattr, który umożliwia przechowywanie alternatywnych zbiorów danych NTFS (NTFS alternate data stream) w rozszerzonych atrybutach plików (xattr) w Linuxie, dodano ustawienie „streams_xattr:max xattrs per stream”, które determinuje dozwoloną liczbę xattr używanych do przechowywania danych. W Linuxie rozmiar xattr jest ograniczony do 65536 bajtów, ale system plików XFS umożliwia powiązanie z jednym plikiem więcej niż jednego xattr, co pozwala na użycie kilku xattr do przechowywania do 1 MB danych alternatywnych.
  • Wprowadzono wsparcie dla audytu informacji związanych z autoryzacją. Dodano klasy debugowania „dsdb_password_audit” oraz „dsdb_password_json_audit” do rejestrowania w logach zmian atrybutów Active Directory: altSecurityIdentities, dNSHostName, msDS-AdditionalDnsHostName, msDS-KeyCredentialLink oraz servicePrincipalName.
  • Dodano wsparcie dla zewnętrznych systemów zarządzania hasłami Microsoft Entra ID oraz Keycloak, które wykorzystują podczas zmiany hasła operację resetowania hasła (SSPR, password reset) bez przekazywania starego hasła do kontrolera. domeny. Aby przestrzegać polityk dotyczących czasu działania haseł, podczas resetowania hasła przesyłane są dodatkowe parametry („wskazówki dotyczące polityki haseł”), które pozwalają traktować operację jako zwykłą zmianę hasła. Teraz Samba uwzględnia te parametry podczas stosowania lokalnych polityk związanych z hasłami.
  • Dodano wsparcie dla mechanizmu uwierzytelniania Kerberos PKINIT KeyTrust, umożliwiającego kontrolerom domeny opartym na Samba i Heimdal KDC stosowanie metody „Windows Hello for Business Key-Trust logons” do realizacji mechanizmu uwierzytelniania PKINIT z samopodpisanymi kluczami. Aby dodać i wyświetlić klucz publiczny w narzędziu samba-tool, dodano polecenie „user|computer keytrust”. Informacje o kluczu publicznym są zapisywane w koncie za pomocą atrybutu msDS-KeyCredentialLink.
  • W kontrolerach domeny opartych na Samba i Heimdal KDC dodano wsparcie dla rozszerzenia protokołu Kerberos PKINIT do mapowania kluczy („Windows Strong and Flexible key mappings”), stosowanego podczas uwierzytelniania za pomocą kluczy publicznych. Domyślnie dozwolone jest tylko ścisłe dopasowanie certyfikatów („strong certificate binding enforcement = full”), ale możliwe jest także elastyczne dopasowanie („strong certificate binding enforcement = compatibility”), które dopuszcza certyfikaty nowsze niż konto użytkownika. Dane o mapowaniu certyfikatów dla konta są zapisywane w atrybucie altSecurityIdentities.
  • Dodano wsparcie dla rozszerzenia protokołu „Kerberos PKINIT SID”, które umożliwia użycie certyfikatów z identyfikatorem Object SID podczas uwierzytelniania. Aby podpisać certyfikaty, do narzędzia samba-tool dodano polecenie „user|computer generate-csr”.
  • W implementacji KDC (Key Distribution Center) domyślnie zapewnia się zwracanie struktury PAC (Privilege Attribute Certificate), zawierającej dane o uprawnieniach użytkownika, niezależnie od tego, czy pole PA-PAC-REQUEST zostało wskazane w zapytaniu klienta. Aby przywrócić stare zachowanie, przewidziano ustawienie „kdc always generate pac = no”.
  • W KDC dodano ustawienie „kdc require canonicalization”, które po ustawieniu na „yes” wymusza na kliencie żądanie wykonania kanonizacji nazwy użytkownika podczas logowania (AS_REQ). Jeśli kanonizacja nie zostanie zażądana, serwer zwróci błąd „użytkownik nieznany”. W sieciach z użytkownikami korzystającymi z systemu Windows, włączenie nowego ustawienia nie powinno powodować problemów, ponieważ klienci systemu Windows z definicji zawsze żądają kanonizacji. serwera W KDC dodano nowe ustawienie „kdc require canonicalization”, które, po ustawieniu na „yes”, zobowiązuje klienta do żądania wykonania kanonizacji nazwy użytkownika przy próbie uwierzytelnienia (AS_REQ). Jeśli kanonizacja nie została żądana, serwer zwróci błąd „użytkownik nieznany”. W sieciach, w których użytkownicy używają systemu Windows, włączenie nowego ustawienia nie powinno powodować problemów, bowiem klienci Windows z zasady zawsze żądają kanonizacji.

    Obowiązkowa kanonizacja pozwala chronić przed atakami typu „dollar ticket”, manipulującymi tym, że nazwy użytkowników mogą być zadawane na różne sposoby („user” i „user$”) i różnie przetwarzane w kanonizowanej i zwykłej postaci. Istota ataku polega na tym, że przestępca mógł na przykład utworzyć w AD konto komputera o nazwie „root$” i użyć go do uzyskania mandatu (ticket) od KDC, podając w żądaniu nazwę użytkownika „root” zamiast „root$”. KDC, nie znajdując użytkownika „root”, przetworzyłoby żądanie w kontekście użytkownika „root$” i wydałoby mandat, który można wykorzystać do logowania się jako użytkownik root przez SSH lub NFS do serwera Linux z SSSD.

  • W KDC dodano obejściowy wariant ochrony przed atakami „dollar ticket” dla konfiguracji z wyłączonymi obowiązkowymi żądaniami kanonizacji nazw („kdc require canonicalization = no”, stosowane domyślnie). Domyślnie, jeśli klient nie zażądał przeprowadzenia kanonizacji i sprawdzana nazwa nie została znaleziona, serwer przeprowadza dodatkowe sprawdzenie, dołączając symbol „$” do nazwy. Za pomocą nowej ustawienia „kdc name match implicit dollar without canonicalization = no” można wyłączyć to zachowanie i przeprowadzać tylko dokładne sprawdzenia (w kontekście wspomnianego ataku, serwer nie będzie sprawdzał nazwy „root$” w żądaniu „root”).
  • W Heimdal KDC domyślnie włączono wysyłanie do usług Kerberos tylko kanonizowanych nazw (sAMAccountName z PAC) zamiast oryginalnej wartości cname. Aby powrócić do starego zachowania, przewidziano ustawienie „krb5 acceptor report canonical client name = no”.
  • Aby w pełni chronić przed atakami „dollar ticket”, zaleca się ustawienie konfiguracji: strong certificate binding enforcement full, kdc always include pac yes, kdc require canonicalization yes.
  • Aby zablokować podatność CVE-2026-20833, metoda szyfrowania domeny w ustawieniach KDC domyślnie zmieniona została na AES (ustawienie „kdc default domain supported enctypes” ustawiło się na „aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha1-96”).

Źródło: opennet.ru

Kup solidny hosting stron z ochroną przed DDoS, serwery VPS VDS 🔥 Kup solidny hosting stron z ochroną przed DDoS, serwery VPS VDS | ProHoster