4.13. Gestion de l'identité
Prise en charge par SSSD de la conversion des répertoires personnels en minuscules
Avec cette amélioration, vous pouvez désormais configurer SSSD pour qu'il convertisse les répertoires personnels des utilisateurs en minuscules. Cela permet de mieux s'intégrer à la nature sensible à la casse de l'environnement RHEL. L'option override_homedir de la section [nss] du fichier /etc/sssd/sssd.conf reconnaît désormais la valeur du modèle %h. Si vous utilisez %h dans le cadre de la définition de override_homedir, SSSD remplace %h par le répertoire personnel de l'utilisateur en minuscules.
Jira:RHELPLAN-139430
SSSD prend désormais en charge la modification des mots de passe des utilisateurs LDAP à l'aide de la stratégie de mot de passe shadow
Avec cette amélioration, si vous définissez ldap_pwd_policy sur shadow dans le fichier /etc/sssd/sssd.conf, les utilisateurs LDAP peuvent désormais modifier leur mot de passe stocké dans LDAP. Auparavant, les modifications de mot de passe étaient rejetées si ldap_pwd_policy était défini sur shadow, car il n'était pas clair si les attributs LDAP shadow correspondants étaient mis à jour.
En outre, si le serveur LDAP ne peut pas mettre à jour automatiquement les attributs shadow, définissez l'option ldap_chpass_update_last_change sur True dans le fichier /etc/sssd/sssd.conf pour indiquer à SSSD de mettre à jour l'attribut.
Bugzilla:1507035
IdM prend désormais en charge le paramètre min_lifetime
Avec cette amélioration, le paramètre min_lifetime a été ajouté au fichier /etc/gssproxy/*.conf. Le paramètre min_lifetime déclenche le renouvellement d'un ticket de service si sa durée de vie restante est inférieure à cette valeur.
Par défaut, sa valeur est de 15 secondes. Pour les clients de volume réseau tels que NFS, afin de réduire le risque de perte d'accès en cas d'indisponibilité momentanée du KDC, fixez cette valeur à 60 secondes.
Le module ipapwpolicy ansible-freeipa prend désormais en charge de nouvelles options de politique de mot de passe
Avec cette mise à jour, le module ipapwpolicy inclus dans le paquetage ansible-freeipa prend en charge des options supplémentaires de la bibliothèque libpwquality:
maxrepeat- Spécifie le nombre maximum de caractères identiques dans une séquence.
maxsequence- Spécifie la longueur maximale des séquences de caractères monotones (abcd).
dictcheck- Vérifie si le mot de passe est un mot du dictionnaire.
usercheck- Vérifie si le mot de passe contient le nom d'utilisateur.
Si l'une des options de la nouvelle politique de mot de passe est activée, la longueur minimale des mots de passe est de 6 caractères. Les paramètres de la politique relative aux nouveaux mots de passe ne s'appliquent qu'aux nouveaux mots de passe.
Dans un environnement mixte avec des serveurs RHEL 7 et RHEL 8, les nouveaux paramètres de la politique de mot de passe ne sont appliqués que sur les serveurs fonctionnant sous RHEL 8.4 ou une version ultérieure. Si un utilisateur est connecté à un client IdM et que ce dernier communique avec un serveur IdM fonctionnant sous RHEL 8.3 ou une version antérieure, les nouvelles exigences en matière de stratégie de mot de passe définies par l'administrateur système ne s'appliquent pas. Pour garantir un comportement cohérent, mettez à niveau tous les serveurs vers RHEL 8.4 ou une version ultérieure.
Jira:RHELPLAN-137416
IdM prend désormais en charge le module de gestion Ansible ipanetgroup
En tant qu'administrateur du système de gestion des identités (IdM), vous pouvez intégrer IdM aux domaines NIS et aux groupes nets. Le module ipanetgroup ansible-freeipa vous permet de réaliser les opérations suivantes :
- Vous pouvez faire en sorte qu'un groupe net IdM existant contienne des utilisateurs, des groupes, des hôtes et des groupes d'hôtes IdM spécifiques, ainsi que des groupes nets IdM imbriqués.
- Vous pouvez vous assurer que des utilisateurs, des groupes, des hôtes et des groupes d'hôtes IdM spécifiques, ainsi que des groupes nets IdM imbriqués, sont absents d'un groupe net IdM existant.
- Vous pouvez vous assurer qu'un groupe de réseau spécifique est présent ou absent dans IdM.
Jira:RHELPLAN-137411
Nouvelles variables de rôle ipaclient_configure_dns_resolver et ipaclient_dns_servers Ansible ipaclient spécifiant le résolveur DNS du client
Auparavant, lors de l'utilisation du rôle ansible-freeipa ipaclient pour installer un client Identity Management (IdM), il n'était pas possible de spécifier le résolveur DNS pendant le processus d'installation. Vous deviez configurer le résolveur DNS avant l'installation.
Grâce à cette amélioration, vous pouvez spécifier le résolveur DNS lorsque vous utilisez le rôle ipaclient pour installer un client IdM avec les variables ipaclient_configure_dns_resolver et ipaclient_dns_servers. Par conséquent, le rôle ipaclient modifie le fichier resolv.conf et les utilitaires NetworkManager et systemd-resolved pour configurer le résolveur DNS sur le client de la même manière que le rôle ansible-freeipa ipaserver le fait sur le serveur IdM. Par conséquent, la configuration du DNS lors de l'utilisation du rôle ipaclient pour installer un client IdM est désormais plus efficace.
L'utilisation du programme d'installation en ligne de commande ipa-client-install pour installer un client IdM nécessite toujours la configuration du résolveur DNS avant l'installation.
Jira:RHELPLAN-137406
L'utilisation du rôle ipaclient pour installer un client IdM avec un OTP ne nécessite aucune modification préalable du contrôleur Ansible
Auparavant, la commande kinit sur le contrôleur Ansible était une condition préalable à l'obtention d'un mot de passe à usage unique (OTP) pour le déploiement du client Identity Management (IdM). La nécessité d'obtenir l'OTP sur le contrôleur était un problème pour Red Hat Ansible Automation Platform (AAP), où le paquetage krb5-workstation n'était pas installé par défaut.
Avec cette mise à jour, la demande de TGT de l'administrateur est désormais déléguée au premier serveur IdM spécifié ou découvert. Par conséquent, vous pouvez désormais utiliser un OTP pour autoriser l'installation d'un client IdM sans modification supplémentaire du contrôleur Ansible. Cela simplifie l'utilisation du rôle ipaclient avec AAP.
Jira:RHELPLAN-137403
L'IdM impose désormais la présence de la structure MS-PAC dans les tickets Kerberos
À partir de RHEL 9.2, pour renforcer la sécurité, Identity Management (IdM) et MIT Kerberos imposent désormais la présence de la structure du certificat d'attribut de privilège (MS-PAC) dans les tickets Kerberos émis par le centre de distribution Kerberos (KDC) de RHEL IdM.
En novembre 2022, en réponse à CVE-2022-37967, Microsoft a introduit une signature étendue qui est calculée sur l'ensemble de la structure MS-PAC plutôt que sur la somme de contrôle du serveur. À partir de RHEL 9.2, les tickets Kerberos émis par IdM KDC contiennent également la signature étendue.
La présence de la signature étendue n'est pas encore imposée dans l'IdM.
Jira:RHELPLAN-159146
Nouveau modèle de configuration de domaine pour le KDC permettant un cryptage des clés conforme à la norme FIPS 140-3
Cette mise à jour fournit un nouvel exemple de configuration du domaine ( EXAMPLE.COM) dans le fichier /var/kerberos/krb5kdc/kdc.conf. Elle apporte deux changements :
-
La famille
AES HMAC SHA-2, conforme à la norme FIPS 140-3, est ajoutée à la liste des types pris en charge pour le cryptage des clés. -
Le type de cryptage de la clé principale du KDC passe de
AES 256 HMAC SHA-1àAES 256 HMAC SHA-384.
Cette mise à jour concerne les domaines MIT autonomes. Ne modifiez pas la configuration du centre de distribution Kerberos (KDC) dans RHEL Identity Management.
L'utilisation de ce modèle de configuration est recommandée pour les nouveaux royaumes. Le modèle n'affecte pas les royaumes déjà déployés. Si vous envisagez de mettre à jour la configuration de votre royaume conformément au modèle, tenez compte des points suivants :
Pour mettre à jour la clé principale, il ne suffit pas de modifier les paramètres de la configuration du KDC. Suivez la procédure décrite dans la documentation MIT Kerberos : https://web.mit.edu/kerberos/krb5-1.20/doc/admin/database.html#updating-the-master-key
L'ajout de la famille AES HMAC SHA-2 aux types pris en charge pour le chiffrement des clés est sans danger à tout moment car il n'affecte pas les entrées existantes dans le KDC. Les clés ne seront générées que lors de la création de nouveaux mandants ou du renouvellement des identifiants. Notez que les clés de ce nouveau type ne peuvent pas être générées sur la base de clés existantes. Pour que ces nouveaux types de chiffrement soient disponibles pour un certain mandant, ses informations d'identification doivent être renouvelées, ce qui signifie que les keytabs des mandants de service doivent également être renouvelés.
Le seul cas où les mandants ne doivent pas comporter de clé AES HMAC SHA-2 est celui des billets d'attribution de tickets (TGT) inter-royaumes d'Active Directory (AD). Comme AD ne met pas en œuvre la norme RFC8009, il n'utilise pas la famille de types de chiffrement AES HMAC SHA-2. Par conséquent, un TGS-REQ inter-royaumes utilisant un TGT inter-royaumes chiffré sur AES HMAC SHA-2 échouerait. La meilleure façon d'empêcher le client MIT Kerberos d'utiliser AES HMAC SHA-2 contre AD est de ne pas fournir de clés AES HMAC SHA-2 pour les mandants AD inter-royaumes. Pour ce faire, assurez-vous que vous créez les entrées TGT inter-royaumes avec une liste explicite de types de chiffrement de clé qui sont tous pris en charge par AD :
kadmin.local <<EOF add_principal +requires_preauth -e aes256-cts-hmac-sha1-96,aes128-cts-hmac-sha1-96 -pw [password] krbtgt/[MIT realm]@[AD realm] add_principal +requires_preauth -e aes256-cts-hmac-sha1-96,aes128-cts-hmac-sha1-96 -pw [password] krbtgt/[AD realm]@[MIT realm] EOF
Pour que les clients MIT Kerboros utilisent les types de chiffrement AES HMAC SHA-2, vous devez également définir ces types de chiffrement comme permitted dans la configuration du client et du KDC. Sur RHEL, ce paramètre est géré par le système crypto-policy. Par exemple, sur RHEL 9, les hôtes utilisant la politique de chiffrement DEFAULT autorisent les tickets chiffrés AES HMAC SHA-2 et AES HMAC SHA-1, tandis que les hôtes utilisant la politique de chiffrement FIPS n'acceptent que les tickets chiffrés AES HMAC SHA-2.
Configurer pam_pwhistory à l'aide d'un fichier de configuration
Avec cette mise à jour, vous pouvez configurer le module pam_pwhistory dans le fichier de configuration /etc/security/pwhistory.conf. Le module pam_pwhistory enregistre le dernier mot de passe de chaque utilisateur afin de gérer l'historique des changements de mot de passe. Un support a également été ajouté dans authselect qui vous permet d'ajouter le module pam_pwhistory à la pile PAM.
Bugzilla:2126640, Bugzilla:2142805
samba repassé à la version 4.17.5
Les paquets samba ont été mis à jour vers la version amont 4.17.5, qui apporte des corrections de bogues et des améliorations par rapport à la version précédente. Les changements les plus notables :
- Les améliorations apportées à la sécurité dans les versions précédentes ont eu un impact sur les performances du serveur Server Message Block (SMB) pour les charges de travail à forte teneur en métadonnées. Cette mise à jour améliore les performances dans ce scénario.
-
L'option
--jsona été ajoutée à l'utilitairesmbstatuspour afficher des informations d'état détaillées au format JSON. -
Les modules
samba.smb.confetsamba.samba3.smb.confont été ajoutés à l'API Pythonsmbconf. Vous pouvez les utiliser dans des programmes Python pour lire et, éventuellement, écrire la configuration Samba de manière native.
Notez que le protocole server message block version 1 (SMB1) est obsolète depuis Samba 4.11 et sera supprimé dans une prochaine version.
Sauvegardez les fichiers de base de données avant de démarrer Samba. Lorsque les services smbd, nmbd, ou winbind démarrent, Samba met automatiquement à jour ses fichiers de base de données tdb. Red Hat ne prend pas en charge la rétrogradation des fichiers de base de données tdb.
Après avoir mis à jour Samba, utilisez l'utilitaire testparm pour vérifier le fichier /etc/samba/smb.conf.
Pour plus d'informations sur les changements notables, lisez les notes de version en amont avant de procéder à la mise à jour.
ipa-client-install supporte désormais l'authentification avec PKINIT
Auparavant, le site ipa-client-install ne prenait en charge que l'authentification par mot de passe. Cette mise à jour permet à ipa-client-install de prendre en charge l'authentification par PKINIT.
Par exemple :
ipa-client-install --pkinit-identity=FILE:/path/to/cert.pem,/path/to/key.pem --pkinit-anchor=FILE:/path/to/cacerts.pem
Pour utiliser l'authentification PKINIT, vous devez établir la confiance entre IdM et la chaîne CA du certificat PKINIT. Pour plus d'informations, voir la page de manuel ipa-cacert-manage(1). En outre, les règles de mappage de l'identité du certificat doivent mapper le certificat PKINIT de l'hôte à un principal qui a la permission d'ajouter ou de modifier un enregistrement d'hôte. Pour plus d'informations, voir la page de manuel ipa certmaprule-add.
Red Hat IdM et Certificate System prennent désormais en charge le protocole EST
Enrollment over Secure Transport (EST) est une nouvelle fonctionnalité du sous-système de certification qui est spécifiée dans la RFC 7030 et qui est utilisée pour fournir des certificats à partir d'une autorité de certification (CA). EST met en œuvre le côté serveur de l'opération, comme /getcacerts, /simpleenroll, et /simplereenroll.
Notez que Red Hat prend en charge à la fois EST et le Simple Certificate Enrollment Protocol (SCEP) original dans le système de certificats.
Purge automatique des certificats expirés
Cette mise à jour ajoute un mécanisme automatique pour purger les certificats expirés et les enregistrements de demande de la base de données. Vous pouvez activer cette fonction en fonction de certaines règles, telles que la limite de taille de la recherche, la limite de temps de la recherche et la durée de conservation.
Pour supprimer les enregistrements en toute sécurité, l'autorité de certification doit utiliser la méthode Random Certificate Serial Numbers v1 (RSNv3) pour générer les numéros de série des certificats et les identifiants des demandes d'inscription ou de renouvellement. L'AC fournit un travail d'élagage qui supprime les éléments suivants :
- Certificats expirés depuis un certain temps.
- Demandes complétées correspondant aux certificats expirés.
- Demandes incomplètes qui sont restées inactives pendant un certain temps.
Vous devez planifier l'exécution régulière de cette tâche afin de supprimer un certain nombre d'enregistrements à chaque exécution. Les enregistrements restants seront supprimés lors des exécutions suivantes. Pour les déploiements importants, vous pouvez répartir la tâche entre les serveurs du cluster.
Améliorer l'utilisation du cache négatif
Cette mise à jour améliore les performances du SSSD pour les recherches par identifiant de sécurité (SID). Elle stocke désormais les SID non existants dans le cache négatif pour les domaines individuels et demande le domaine auquel le SID appartient.
ACME prend désormais en charge la suppression automatique des certificats expirés
Auparavant, le service ACME (Automated Certificate Management Environment) de la gestion des identités (IdM) ne supprimait pas les certificats expirés de l'autorité de certification (AC). Comme ACME émet des certificats de courte durée (90 jours), les certificats expirés s'accumulaient dans l'autorité de certification, ce qui affectait les performances.
Grâce à cette amélioration, ACME peut désormais supprimer automatiquement les certificats expirés à des intervalles spécifiés.
La suppression des certificats expirés est désactivée par défaut. Pour l'activer, entrez :
# ipa-acme-manage pruning --enable --cron "0 0 1 * *"
Les certificats expirés sont ainsi supprimés le premier jour de chaque mois à minuit.
Les certificats expirés sont supprimés après leur période de conservation. Par défaut, cette période est de 30 jours après l'expiration.
Pour plus de détails, voir la page de manuel ipa-acme-manage(1).
Le serveur d'annuaire prend désormais en charge les clés privées ECDSA pour TLS
Auparavant, vous ne pouviez pas utiliser d'algorithmes cryptographiques plus puissants que RSA pour sécuriser les connexions au serveur Directory. Avec cette amélioration, Directory Server prend désormais en charge les clés ECDSA et RSA.
Directory Server prend désormais en charge la journalisation étendue des opérations de recherche
Auparavant, les enregistrements dans le journal des accès n'indiquaient pas pourquoi certaines opérations de recherche avaient une valeur etime très élevée. Avec cette version, vous pouvez activer l'enregistrement de statistiques telles que le nombre de consultations d'index (opérations de lecture de la base de données) et la durée totale des consultations d'index pour chaque opération de recherche. Ces enregistrements statistiques peuvent aider à analyser pourquoi la valeur etime peut être si coûteuse en ressources.
Bugzilla:1859271
Le niveau de journalisation des erreurs NUNC_STANS a été remplacé par le nouveau niveau de journalisation 1048576
Auparavant, vous ne pouviez pas facilement déboguer les problèmes liés à la politique de mot de passe. Avec le nouveau niveau de journalisation 1048576 pour le journal des erreurs, vous pouvez maintenant vérifier les informations suivantes sur la politique de mot de passe :
- Quelle politique locale rejette ou autorise la mise à jour d'un mot de passe.
- La violation exacte de la syntaxe.
Directory Server introduit le journal de sécurité
Pour suivre correctement les problèmes au fil du temps, Directory Server dispose désormais d'un journal spécialisé qui conserve les données de sécurité. Le journal de sécurité ne tourne pas rapidement et consomme moins de ressources disque que le journal d'accès qui contient toutes les informations, mais nécessite une analyse coûteuse pour obtenir les données de sécurité.
Le nouveau journal du serveur enregistre les événements de sécurité tels que les événements d'authentification, les problèmes d'autorisation, les attaques DoS/TCP et d'autres événements.
Directory Server stocke le journal de sécurité dans le répertoire /var/log/dirsrv/slapd-instance_name/ avec d'autres fichiers journaux.
Directory Server peut désormais compresser les fichiers journaux archivés
Auparavant, les fichiers journaux archivés n'étaient pas compressés. Avec cette version, vous pouvez activer la compression des fichiers journaux d'accès, d'erreur, d'audit, d'échec d'audit et de sécurité afin d'économiser de l'espace disque. Notez que seule la compression des fichiers journaux de sécurité est activée par défaut.
Utilisez les nouveaux attributs de configuration suivants dans l'entrée cn=config pour gérer la compression :
-
nsslapd-accesslog-compresspour le journal d'accès -
nsslapd-errorlog-compresspour le journal des erreurs -
nsslapd-auditlog-compresspour le journal d'audit -
nsslapd-auditfaillog-compresspour le journal des échecs d'audit -
nsslapd-securelog-compresspour le journal de sécurité
Bugzilla:1132524
Nouveau paramètre de configuration nsslapd-auditlog-display-attrs pour le journal d'audit du serveur d'annuaire
Auparavant, il était difficile de déterminer qui avait modifié une entrée si le nom distinctif (DN) de l'entrée ne contenait pas d'informations d'identification claires. Avec le nouveau paramètre nsslapd-auditlog-display-attrs, vous pouvez définir des attributs supplémentaires que Directory Server affiche dans le journal d'audit pour fournir plus de détails sur l'entrée modifiée.
Par exemple, si vous attribuez la valeur cn au paramètre nsslapd-auditlog-display-attrs, le journal d'audit affiche l'attribut cn dans la sortie :
time: 20221014125914 dn: uid=73747737483,ou=people,dc=example,dc=com result: 0 *#cn: John Smith* changetype: modify replace: displayName displayName: jsmith - replace: modifiersname modifiersname: cn=dm - replace: modifytimestamp modifytimestamp: 20221014165914Z
Si vous souhaitez que le journal d'audit inclue tous les attributs d'une entrée modifiée, vous pouvez utiliser un astérisque (*) comme valeur du paramètre.
Une nouvelle option de configuration pamModuleIsThreadSafe est désormais disponible
Lorsqu'un module PAM est thread-safe, vous pouvez améliorer le débit d'authentification PAM et le temps de réponse de ce module spécifique en définissant la nouvelle option de configuration pamModuleIsThreadSafe sur yes:
`pamModuleIsThreadSafe: yes`
Cette configuration s'applique à l'entrée de configuration du module PAM (enfant de cn=PAM Pass Through Auth,cn=plugins,cn=config).
Utilisez l'option pamModuleIsThreadSafe dans le fichier de configuration dse.ldif ou la commande ldapmodify. Notez que la commande ldapmodify nécessite le redémarrage du serveur.
Directory Server peut désormais importer un paquet de certificats
Auparavant, lorsque vous essayiez d'ajouter un paquet de certificats à l'aide de l'utilitaire dsconf ou dsctl, la procédure échouait avec une erreur et le paquet de certificats n'était pas importé. Ce comportement était dû à l'utilitaire certutil qui ne pouvait importer qu'un seul certificat à la fois. Avec cette mise à jour, Directory Server contourne le problème avec l'utilitaire certutil, et un paquet de certificats est ajouté avec succès.
