Hat hónapnyi fejlesztés után megjelent a Samba 4.24.0 verzió, amely a Samba 4 ágat folytatja, és teljes körűen megvalósítja a tartományvezérlőt és az Active Directory szolgáltatást, amely kompatibilis a Windows Server megvalósításával és képes kiszolgálni minden támogatott Microsoft Windows kliens verziót, beleértve a Windows 11-et is. A Samba 4 egy sokoldalú szervertermék, amely fájlszerver, nyomtatószolgáltatás és azonosító szerver (winbind) megvalósítást is kínál. A projekt kódja C nyelven íródott, és GPLv3 licenc alatt terjesztik.
A Samba 4.24 főbb változásai:
- Új VFS-modul, a vfs_aio_ratelimit került bevezetésre, amely korlátozza az aszinkron bemeneti/kimeneti (AIO) műveletek intenzitását (rate-limit). A korlátozások byte/másodperc vagy műveletek/másodperc formájában állíthatók be. Ha a megadott határértéket túllépik, a modul mesterséges késleltetéseket kezd alkalmazni az aszinkron műveletekben a megadott felső küszöb fenntartása érdekében.
- A vfs_ceph_new VFS-modulban támogatást kapott az RPC protokoll, a Keybridge és az FSCrypt mód az adatok és fájlnevek titkosításához CephFS fájlrendszerben. A titkosítás külön könyvtárak szintjén is engedélyezhető.
- A vfs_streams_xattr VFS-modul, amely lehetővé teszi NTFS alternatív adathalmazon való tárolást (NTFS alternate data stream) a fájlok kiterjesztett attribútumaiban (xattr) Linux alatt, mostantól tartalmazza a „streams_xattr:max xattrs per stream” beállítást, amely meghatározza a tárolt adatokhoz alkalmazott xattr maximális számát. Linux alatt az xattr mérete 65536 byte-ra korlátozódik, de az XFS fájlrendszer lehetővé teszi, hogy egy fájlhoz több xattr-t is hozzárendeljenek, így akár 1 MB alternatív adat tárolására is lehetőség van.
- Bevezetésre került az autentikációval kapcsolatos információk auditálásának támogatása. Új hibakeresési osztályok, a „dsdb_password_audit” és a „dsdb_password_json_audit” kerültek hozzáadásra, amelyek a naplózás során az Active Directory attribútumainak módosításait tükrözik: altSecurityIdentities, dNSHostName, msDS-AdditionalDnsHostName, msDS-KeyCredentialLink és servicePrincipalName.
- Támogatást kapott a Microsoft Entra ID és a Keycloak külső jelszókezelő rendszerek, amelyek a jelszó megváltoztatásánál jelszó-visszaállítási (SSPR, password reset) műveletet használnak anélkül, hogy a régi jelszót a vezérlőbe továbbítanák. domain. A jelszók hatályának betartásához, a jelszó visszaállításakor további paraméterek („jelszópolitikai utalások”) kerülnek átadásra, amelyek lehetővé teszik az eljárás kezelését, mint a jelszó szokásos módosítását. Most a Samba figyelembe veszi az ilyen paramétereket a jelszavakra vonatkozó helyi politikák alkalmazásánál.
- Hozzáadva a Kerberos PKINIT KeyTrust hitelesítési mechanizmusának támogatása, amely lehetővé teszi, hogy a Samba és Heimdal KDC alapú domain vezérlők a „Windows Hello for Business Key-Trust bejelentkezések” módszert alkalmazzák a PKINIT hitelesítési mechanizmus önaláírt kulcsokkal való használatára. Az nyilvános kulcs hozzáadásához és megtekintéséhez a samba-tool eszközbe a „user|computer keytrust” parancs került bevezetésre. Az nyilvános kulcsról szóló információk az msDS-KeyCredentialLink attribútum révén kerülnek tárolásra a fiókban.
- A Samba és Heimdal KDC alapú domain vezérlőkbe a Kerberos PKINIT protokoll kiterjesztésének támogatása került bevezetésre a kulcsmappinghez („Windows Strong and Flexible key mappings”), amely nyilvános kulcsokkal történő hitelesítéskor alkalmazható. Alapértelmezés szerint csak pontos tanúsítványpárosítás megengedett („strong certificate binding enforcement = full”), de rugalmas párosítás is lehetséges („strong certificate binding enforcement = compatibility”), amely lehetővé teszi a felhasználói fióknál újabb tanúsítványok használatát. A tanúsítványok párosításáról szóló adatok a altSecurityIdentities attribútumban kerülnek tárolásra.
- A Kerberos PKINIT SID protokoll kiterjesztésének támogatása került hozzáadásra, amely lehetővé teszi az Object SID azonosítóval rendelkező tanúsítványok használatát a hitelesítés során. A tanúsítványok aláírásához a samba-tool eszközbe a „user|computer generate-csr” parancs került bevezetésre.
- A KDC (Kulcskal分központ) megvalósításában alapértelmezés szerint a PAC (Privilege Attribute Certificate) struktúrájának visszaadása biztosított, amely a felhasználó jogosultságaival kapcsolatos adatokat tartalmaz, függetlenül attól, hogy a PA-PAC-REQUEST mező szerepel-e az ügyfél kérésében. A régi viselkedés visszaállításához a „kdc always generate pac = no” beállítás érhető el.
- A KDC-be a „kdc require canonicalization” beállítás került hozzáadásra, amelynek „igen” értékére a kliensnek kérnie kell a felhasználónevének kanonizációját az authentikáláskor (AS_REQ). Ha a kanonizációt nem kérik, a szerver „felhasználó ismeretlen” hibát ad vissza. szerverhez A Windows OS-t használó felhasználókkal rendelkező hálózatokban az új beállítás aktiválásának nem kell problémát okoznia, mivel a Windows kliens alapértelmezés szerint mindig kéri a kanonizációt.
A kötelező kanonizáció védelmet nyújt a "dollar ticket" típusú támadások ellen, amelyek manipulálják, hogy a felhasználónevek eltérően adhatók meg ("user" és "user$") és eltérően dolgozzák fel őket a kanonizált és a normál megjelenítésekben. A támadás lényegében abban rejlik, hogy a támadó például létrehozhatott az AD-ben egy "root$" nevű számítógép-fiókot, és ezt felhasználhatja arra, hogy a KDC-től mandátumot (ticket) szerezzen, a kérésben a felhasználónevet "root" helyett "root$"-ra átírva. Mivel a KDC nem találja a "root" felhasználót, a kérdést a "root$" felhasználó kontextusában dolgozná fel, és olyan mandátumot adna ki, amelyet a root felhasználó SSH vagy NFS kapcsolaton keresztül történő Linux-szerverhez való csatlakozáshoz lehet használni az SSSD-vel.
- A KDC-be egy alternatív védelmi módszer került bevezetésre a "dollar ticket" támadások ellen az olyan konfigurációk számára, ahol a kötelező névkanonizációs kérések le vannak kapcsolva ("kdc require canonicalization = no", alapértelmezett beállítás). Alapértelmezés szerint, ha az ügyfél nem kérte a kanonizáció végrehajtását, és a vizsgált név nem található, a szerver további ellenőrzést végez, a névhez hozzáfűzve a "$" jelet. Az új beállítással, a "kdc name match implicit dollar without canonicalization = no" opcióval le lehet tiltani ezt a viselkedést, és csak pontos ellenőrzéseket végezni (a fent említett támadás kontextusában a szerver nem ellenőrzi a "root$" nevet a "root" kérése esetén).
- A Heimdal KDC-ben alapértelmezés szerint csak kanonizált neveket (sAMAccountName a PAC-ból) küldünk el a Kerberos szolgáltatásoknak az eredeti cname érték helyett. Az régi viselkedés visszaállítására a "krb5 acceptor report canonical client name = no" beállítás érhető el.
- A teljes védelem érdekében a "dollar ticket" támadásokkal szemben az alábbi beállítások alkalmazását javasoljuk: strong certificate binding enforcement full, kdc always include pac yes, kdc require canonicalization yes.
- A CVE-2026-20833 sérülékenység blokkolásához a KDC konfiguráció eddigi domain titkosítási módszere alapértelmezés szerint AES-re változott (a "kdc default domain supported enctypes" beállítása "aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha1-96" értékre lett állítva).
Forrás: opennet.ru
