Sortie de Samba 4.24.0

Après 6 mois de développement, la version Samba 4.24.0 est publiée, poursuivant l'évolution de la branche Samba 4 avec une mise en œuvre complète du contrôleur de domaine et du service Active Directory, compatible avec l'implémentation de Windows Server et capable de prendre en charge toutes les versions de clients Windows prises en charge par Microsoft, y compris Windows 11. Samba 4 est un produit serveur multifonctionnel qui fournit également une implémentation de serveur de fichiers, de service d'impression et de serveur d'identité (winbind). Le code du projet est écrit en langage C et est distribué sous la licence GPLv3.

Modifications clés dans Samba 4.24 :

  • Un nouveau module VFS vfs_aio_ratelimit a été ajouté pour limiter l'intensité (rate-limit) des opérations d'entrée/sortie asynchrones (AIO). Les limites peuvent être définies en octets par seconde ou en opérations par seconde. Lorsqu'une limite spécifiée est dépassée, le module commence à introduire des délais artificiels dans les opérations asynchrones pour maintenir le plafond supérieur fixé.
  • Le module VFS vfs_ceph_new a ajouté le support du protocole RPC Keybridge et du mode FSCrypt pour le chiffrement des données et des noms de fichiers dans le système de fichiers CephFS. Le chiffrement peut être activé au niveau de répertoires individuels.
  • Dans le module VFS vfs_streams_xattr, qui permet de conserver des ensembles de données alternatifs NTFS (NTFS alternate data stream) dans les attributs étendus de fichiers (xattr) sous Linux, un paramètre « streams_xattr:max xattrs per stream » a été ajouté, définissant le nombre maximal d'xattr autorisés pour le stockage de données. Sous Linux, la taille d'un xattr est limitée à 65536 octets, mais le système de fichiers XFS permet d'attacher plusieurs xattr à un seul fichier, ce qui permet d'utiliser plusieurs xattr pour stocker jusqu'à 1 Mo de données alternatives.
  • La prise en charge de l'audit des informations liées à l'authentification a été mise en œuvre. Des classes de débogage « dsdb_password_audit » et « dsdb_password_json_audit » ont été ajoutées pour refléter dans le journal les modifications des attributs Active Directory : altSecurityIdentities, dNSHostName, msDS-AdditionalDnsHostName, msDS-KeyCredentialLink et servicePrincipalName.
  • La prise en charge des systèmes externes de gestion des mots de passe Microsoft Entra ID et Keycloak, utilisant une opération de réinitialisation du mot de passe (SSPR, password reset) lors du changement de mot de passe sans transmettre l'ancien mot de passe au contrôleur, a été ajoutée. de domaine. Pour se conformer aux politiques régissant la durée de validité des mots de passe, des paramètres supplémentaires (« hints de politique de mot de passe ») sont transmis lors de la réinitialisation du mot de passe, permettant de traiter l'opération comme un changement de mot de passe ordinaire. Samba prend désormais en compte ces paramètres lors de l'application des politiques locales liées aux mots de passe.
  • Ajout du support du mécanisme d'authentification Kerberos PKINIT KeyTrust, permettant aux contrôleurs de domaine basés sur Samba et Heimdal KDC d'utiliser la méthode « Windows Hello for Business Key-Trust logons » pour appliquer le mécanisme d'authentification PKINIT avec des clés auto-signées. Pour ajouter et visualiser la clé publique dans l'outil samba-tool, la commande « user|computer keytrust » a été ajoutée. Les informations sur la clé publique sont enregistrées dans le compte à l'aide de l'attribut msDS-KeyCredentialLink.
  • Les contrôleurs de domaine basés sur Samba et Heimdal KDC ajoutent le support de l'extension du protocole Kerberos PKINIT pour le mappage de clés (« Mappages de clés Windows forts et flexibles »), utilisé lors de l'authentification par clés publiques. Par défaut, seul le mappage exact des certificats est autorisé (« enforcement de liaison de certificat fort = total »), mais un mappage flexible (« enforcement de liaison de certificat fort = compatibilité ») est également possible, permettant des certificats plus récents que le compte d'utilisateur. Les données de mappage des certificats pour le compte sont enregistrées dans l'attribut altSecurityIdentities.
  • Ajout du support de l'extension du protocole « Kerberos PKINIT SID », permettant d'utiliser des certificats avec un identifiant Object SID lors de l'authentification. Pour la signature des certificats, la commande « user|computer generate-csr » a été ajoutée à l'outil samba-tool.
  • Dans l'implémentation du KDC (Key Distribution Center), le retour par défaut de la structure PAC (Privilege Attribute Certificate), contenant des données sur les privilèges de l'utilisateur, est assuré, qu'une entrée PA-PAC-REQUEST soit spécifiée dans la requête du client ou non. Pour revenir au comportement ancien, la configuration « kdc always generate pac = no » est prévue.
  • Dans le KDC, une configuration « kdc require canonicalization » a été ajoutée, si elle est définie sur « yes », le client doit demander la canonisation du nom d'utilisateur lors de l'authentification (AS_REQ). Si la canonisation n'est pas demandée, le serveur renverra une erreur « utilisateur inconnu ». Dans les réseaux avec des utilisateurs utilisant des systèmes d'exploitation Windows, l'activation de cette nouvelle configuration ne devrait pas poser de problèmes, car les clients Windows demandent toujours par défaut la canonisation. serveur authentification (AS_REQ). Si la canonisation n'est pas demandée, le serveur renverra une erreur « utilisateur inconnu ». Dans les réseaux avec des utilisateurs utilisant le système d'exploitation Windows, l'activation de ce nouveau paramètre ne devrait pas poser de problème, car les clients Windows demandent par défaut toujours la canonisation.

    La canonisation obligatoire permet de se protéger contre les attaques de type « dollar ticket », qui exploitent le fait que les noms d'utilisateur peuvent être définis différemment (« user » et « user$ ») et traités différemment dans la représentation canonisée et ordinaire. L'essence de l'attaque réside dans le fait qu'un attaquant, par exemple, pourrait créer un compte ordinateur dans AD avec le nom « root$ » et l'utiliser pour obtenir un mandat (ticket) auprès de KDC, en envoyant le nom d'utilisateur « root » au lieu de « root$ » dans la requête. Ne trouvant pas l'utilisateur « root », KDC traiterait la requête dans le contexte de l'utilisateur « root$ » et délivrerait un mandat qui peut être utilisé pour se connecter sous l'utilisateur root via SSH ou NFS à un serveur Linux avec SSSD.

  • KDC a ajouté une option de contournement pour se protéger contre les attaques « dollar ticket » pour les configurations avec les requêtes de canonisation des noms désactivées (« kdc require canonicalization = no », appliqué par défaut). Par défaut, si le client n'a pas demandé l'exécution de la canonisation et que le nom vérifié n'est pas trouvé, le serveur effectue une vérification supplémentaire en ajoutant le caractère « $ » au nom. Avec le nouveau paramètre « kdc name match implicit dollar without canonicalization = no », il est possible de désactiver ce comportement et d'effectuer uniquement des vérifications exactes (dans le contexte de l'attaque mentionnée, le serveur ne vérifiera pas le nom « root$ » lors de la requête « root »).
  • Dans Heimdal KDC, l'envoi par défaut aux services Kerberos de noms uniquement canonisés (sAMAccountName du PAC) au lieu de la valeur d'origine cname est activé. Pour revenir au comportement précédent, le paramètre « krb5 acceptor report canonical client name = no » est prévu.
  • Pour une protection complète contre les attaques « dollar ticket », il est recommandé de définir les paramètres : strong certificate binding enforcement full, kdc always include pac yes, kdc require canonicalization yes.
  • Pour bloquer la vulnérabilité CVE-2026-20833, la méthode de cryptage du domaine dans les paramètres KDC est par défaut modifiée en AES (le paramètre « kdc default domain supported enctypes » est défini sur « aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha1-96 »).

Source : opennet.ru

Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS 🔥 Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS | ProHoster