5.11. Gestion de l'identité
Authentification MS-CHAP avec le fournisseur historique OpenSSL
Auparavant, les mécanismes d'authentification FreeRADIUS qui utilisaient MS-CHAP échouaient car ils dépendaient des fonctions de hachage MD4, et MD4 a été déprécié dans RHEL 9. Avec cette mise à jour, vous pouvez authentifier les utilisateurs FreeRADIUS avec MS-CHAP ou MS-CHAPv2 si vous activez le fournisseur OpenSSL hérité.
Si vous utilisez le fournisseur OpenSSL par défaut, l'authentification MS-CHAP et MS-CHAPv2 échoue et le message d'erreur suivant s'affiche, indiquant la correction à apporter :
Couldn't init MD4 algorithm. Enable OpenSSL legacy provider.
L'exécution de commandes sudo n'exporte plus la variable d'environnement KRB5CCNAME
Auparavant, après l'exécution des commandes sudo
, la variable d'environnement KRB5CCNAME
pointait vers le cache d'informations d'identification Kerberos de l'utilisateur d'origine, qui pouvait ne pas être accessible à l'utilisateur cible. Par conséquent, les opérations liées à Kerberos pouvaient échouer car ce cache n'était pas accessible. Avec cette mise à jour, l'exécution des commandes sudo
ne définit plus la variable d'environnement KRB5CCNAME
et l'utilisateur cible peut utiliser son cache d'informations d'identification Kerberos par défaut.
(BZ#1879869)
SSSD évalue correctement le paramètre par défaut pour le nom du keytab Kerberos dans le fichier /etc/krb5.conf
Auparavant, si vous définissiez un emplacement non standard pour votre fichier krb5.keytab
, SSSD n'utilisait pas cet emplacement et utilisait à la place l'emplacement par défaut /etc/krb5.keytab
. Par conséquent, lorsque vous essayiez de vous connecter au système, la connexion échouait car le fichier /etc/krb5.keytab
ne contenait aucune entrée.
Avec cette mise à jour, SSSD évalue désormais la variable default_keytab_name
dans /etc/krb5.conf
et utilise l'emplacement spécifié par cette variable. SSSD utilise uniquement l'emplacement par défaut /etc/krb5.keytab
si la variable default_keytab_name
n'est pas définie.
(BZ#1737489)
L'authentification au serveur d'annuaire en mode FIPS avec des mots de passe hachés avec l'algorithme PBKDF2 fonctionne désormais comme prévu
Lorsque Directory Server fonctionne en mode FIPS (Federal Information Processing Standard), la fonction PK11_ExtractKeyValue()
n'est pas disponible. Par conséquent, avant cette mise à jour, les utilisateurs dont le mot de passe était haché à l'aide de l'algorithme PBKDF2 (password-based key derivation function 2) ne pouvaient pas s'authentifier auprès du serveur lorsque le mode FIPS était activé. Avec cette mise à jour, Directory Server utilise désormais la fonction PK11_Decrypt()
pour obtenir les données de hachage du mot de passe. Par conséquent, l'authentification avec des mots de passe hachés avec l'algorithme PBKDF2 fonctionne maintenant comme prévu.