4.15. Gestion de l'identité
Directory Server n'utilise plus de journal des modifications global
Avec cette amélioration, le journal des modifications de Directory Server a été intégré dans la base de données principale. Auparavant, Directory Server utilisait un journal des modifications global. Cependant, cela pouvait poser des problèmes si l'annuaire utilisait plusieurs bases de données. Par conséquent, chaque suffixe a maintenant son propre journal des modifications dans le même répertoire que les fichiers de la base de données principale.
(BZ#1805717)
ansible-freeipa est maintenant disponible dans le dépôt AppStream avec toutes les dépendances
Auparavant, dans RHEL 8, avant d'installer le paquet ansible-freeipa, vous deviez d'abord activer le référentiel Ansible et installer le paquet ansible. Dans RHEL 8.6 et RHEL 9, vous pouvez installer ansible-freeipa sans aucune étape préalable. L'installation de ansible-freeipa installe automatiquement le paquetage ansible-core, une version plus basique de ansible, en tant que dépendance. Les paquets ansible-freeipa et ansible-core sont disponibles dans le dépôt rhel-9-for-x86_64-appstream-rpms.
ansible-freeipa dans RHEL 8.6 et RHEL 9 contient tous les modules qu'il contenait dans RHEL 8.
(JIRA:RHELPLAN-100359)
IdM supporte désormais les modules Ansible automountlocation, automountmap, et automountkey
Avec cette mise à jour, le paquet ansible-freeipa contient les modules ipaautomountlocation, ipaautomountmap, et ipaautomountkey. Vous pouvez utiliser ces modules pour configurer les répertoires à monter automatiquement pour les utilisateurs IdM connectés aux clients IdM dans un emplacement IdM. Notez qu'actuellement, seules les cartes directes sont prises en charge.
(JIRA:RHELPLAN-79161)
La prise en charge de la gestion des plages de sous-identifiants est disponible dans le module shadow-utils
Auparavant, shadow-utils configurait automatiquement les plages de sous-identifiants à partir des fichiers /etc/subuid et /etc/subgid. Avec cette mise à jour, la configuration des plages de sous-identifiants est disponible dans le fichier /etc/nsswitch.conf en définissant une valeur dans le champ subid. Pour plus d'informations, voir man subuid et man subgid. De plus, avec cette mise à jour, une implémentation SSSD du plugin shadow-utils est disponible, qui fournit les plages de sous-identifiants à partir du serveur IPA. Pour utiliser cette fonctionnalité, ajoutez la valeur subid: sss au fichier /etc/nsswitch.conf. Cette solution pourrait être utile dans l'environnement conteneurisé pour faciliter les conteneurs sans racine.
Notez que si le fichier /etc/nsswitch.conf est configuré par l'outil authselect, vous devez suivre les procédures décrites dans la documentation authselect. Si ce n'est pas le cas, vous pouvez modifier le fichier /etc/nsswitch.conf manuellement.
La gestion des plages de sous-identifiants est prise en charge par IdM
Avec cette mise à jour, vous pouvez gérer les sous-gammes d'ID pour les utilisateurs dans la gestion des identités. Vous pouvez utiliser l'outil CLI ipa ou l'interface WebUI IdM pour attribuer à un utilisateur des plages de sous-ID configurées automatiquement, ce qui peut s'avérer utile dans un environnement conteneurisé.
Les paquets d'installation de la gestion des identités ont été démodularisés
Auparavant, dans RHEL 8, les paquets IdM étaient distribués sous forme de modules, ce qui nécessitait d'activer un flux et d'installer le profil correspondant à l'installation souhaitée. Les paquets d'installation IdM ont été démodularisés dans RHEL 9, de sorte que vous pouvez utiliser les commandes dnf suivantes pour installer les paquets de serveur IdM :
Pour un serveur sans services DNS intégrés :
# dnf install ipa-server
Pour un serveur avec services DNS intégrés :
# dnf install ipa-server ipa-server-dns
Une alternative au dépôt traditionnel RHEL ansible-freeipa : Hub d'automatisation Ansible
Avec cette mise à jour, vous pouvez télécharger les modules ansible-freeipa depuis Ansible Automation Hub (AAH) au lieu de les télécharger depuis le dépôt RHEL standard. En utilisant AAH, vous pouvez bénéficier des mises à jour plus rapides des modules ansible-freeipa disponibles dans ce dépôt.
Dans AAH, les rôles et modules ansible-freeipa sont distribués sous forme de collection. Notez que vous avez besoin d'un abonnement à Ansible Automation Platform (AAP) pour accéder au contenu du portail AAH. Vous avez également besoin de ansible version 2.9 ou ultérieure.
La collection redhat.rhel_idm a le même contenu que le paquet traditionnel ansible-freeipa. Toutefois, le format de la collection utilise un nom de collection entièrement qualifié (FQCN) qui se compose d'un espace de noms et du nom de la collection. Par exemple, le module redhat.rhel_idm.ipadnsconfig correspond au module ipadnsconfig dans ansible-freeipa fourni par un dépôt RHEL. La combinaison d'un espace de noms et d'un nom de collection garantit que les objets sont uniques et peuvent être partagés sans conflit.
(JIRA:RHELPLAN-103147)
les modules ansible-freeipa peuvent désormais être exécutés à distance sur les clients IdM
Auparavant, les modules ansible-freeipa ne pouvaient être exécutés que sur les serveurs IdM. Cela nécessitait que votre administrateur Ansible ait un accès SSH à votre serveur IdM, ce qui constituait une menace potentielle pour la sécurité. Avec cette mise à jour, vous pouvez exécuter les modules ansible-freeipa à distance sur des systèmes qui sont des clients IdM. Par conséquent, vous pouvez gérer la configuration et les entités IdM de manière plus sécurisée.
Pour exécuter les modules ansible-freeipa sur un client IdM, choisissez l'une des options suivantes :
-
Définissez la variable
hostsde l'ordre de lecture sur un hôte client IdM. -
Ajoutez la ligne
ipa_context: clientà la tâche du playbook qui utilise le moduleansible-freeipa.
Vous pouvez également définir la variable ipa_context sur client sur un serveur IdM. Toutefois, le contexte du serveur offre généralement de meilleures performances. Si ipa_context n'est pas défini, ansible-freeipa vérifie s'il est exécuté sur un serveur ou un client et définit le contexte en conséquence. Notez que l'exécution d'un module ansible-freeipa avec la variable context définie sur server sur un hôte client IdM entraîne une erreur de missing libraries.
(JIRA:RHELPLAN-103146)
Le module ipadnsconfig exige désormais que action: member exclue un transitaire global
Avec cette mise à jour, l'exclusion des expéditeurs globaux dans la gestion de l'identité (IdM) en utilisant le module ansible-freeipa ipadnsconfig nécessite l'utilisation de l'option action: member en plus de l'option state: absent. Si vous n'utilisez que state: absent dans votre manuel de jeu sans utiliser également action: member, le manuel de jeu échoue. Par conséquent, pour supprimer tous les transitaires globaux, vous devez tous les spécifier individuellement dans le cahier d'exécution. En revanche, l'option state: present ne nécessite pas action: member.
Les groupes privés automatiques pour les utilisateurs AD permettent une configuration centralisée
Vous pouvez désormais définir de manière centralisée la façon dont les versions compatibles de SSSD sur les clients IdM gèrent les groupes privés pour les utilisateurs des domaines Active Directory de confiance. Grâce à cette amélioration, vous pouvez désormais définir explicitement la valeur de l'option auto_private_groups de SSSD pour une plage d'identifiants qui gère les utilisateurs AD.
Lorsque l'option auto_private_groups n'est pas explicitement définie, elle utilise une valeur par défaut :
-
Pour une plage d'ID
ipa-ad-trust-posix, la valeur par défaut estfalse. SSSD utilise toujours les adressesuidNumberetgidNumberde l'entrée AD. Un groupe portant l'adressegidNumberdoit exister dans AD. -
Pour une plage d'ID
ipa-ad-trust, la valeur par défaut esttrue. SSSD mappe leuidNumberà partir du SID d'entrée, legidNumberest toujours défini sur la même valeur et un groupe privé est toujours mappé.
Vous pouvez également attribuer à auto_private_groups un troisième paramètre : hybrid. Avec ce paramètre, SSSD crée un groupe privé si l'entrée de l'utilisateur a un GID égal à l'UID mais qu'il n'y a pas de groupe avec ce GID. Si l'UID et le GID sont différents, un groupe avec ce numéro de GID doit exister.
Cette fonction est utile pour les administrateurs qui souhaitent cesser de gérer des objets de groupe distincts pour les groupes privés d'utilisateurs, mais qui veulent également conserver les groupes privés d'utilisateurs existants.
(BZ#1957736)
Paramètres de journalisation personnalisables pour BIND
Avec cette amélioration, vous pouvez maintenant configurer les paramètres de journalisation pour le composant serveur DNS BIND d'un serveur de gestion d'identité dans le fichier de configuration /etc/named/ipa-logging-ext.conf.
Découverte automatique des serveurs IdM lors de la récupération d'un keytab IdM
Grâce à cette amélioration, il n'est plus nécessaire de spécifier le nom d'hôte d'un serveur IdM lors de la récupération d'un keytab Kerberos à l'aide de la commande ipa-getkeytab. Si vous ne spécifiez pas de nom d'hôte de serveur, la recherche DNS est utilisée pour trouver un serveur IdM. Si aucun serveur n'est trouvé, la commande revient à la valeur host spécifiée dans le fichier de configuration /etc/ipa/default.conf.
RHEL 9 fournit Samba 4.15.5
RHEL 9 est distribué avec Samba 4.15.5, qui apporte des corrections de bogues et des améliorations par rapport à la version 4.14 :
- Les options des utilitaires Samba ont été renommées et supprimées pour une expérience utilisateur cohérente
- Le support multicanal du serveur est désormais activé par défaut.
-
Les dialectes
SMB2_22,SMB2_24etSMB3_10, qui n'étaient utilisés que par les versions préliminaires techniques de Windows, ont été supprimés.
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. Notez que Red Hat ne prend pas en charge la rétrogradation des fichiers de base de données tdb.
Après avoir mis à jour Samba, vérifiez le fichier /etc/samba/smb.conf à l'aide de l'utilitaire testparm.
Pour plus d'informations sur les changements notables, lisez les notes de version en amont avant de procéder à la mise à jour.
Suivi des demandes des clients à l'aide de l'outil d'analyse des logs
Le démon des services de sécurité du système (SSSD) comprend désormais un outil d'analyse des journaux qui suit les demandes du début à la fin dans les fichiers journaux de plusieurs composants SSSD.
L'outil d'analyse des journaux vous permet d'examiner plus facilement les journaux de débogage de SSSD afin de vous aider à résoudre les problèmes de SSSD. Par exemple, vous pouvez extraire et imprimer les journaux SSSD concernant uniquement certaines demandes de clients à travers les processus SSSD. Pour exécuter l'outil d'analyse, utilisez la commande sssctl analyze.
(JIRA:RHELPLAN-97899)
SSSD enregistre désormais les backtraces par défaut
Avec cette amélioration, SSSD stocke désormais des journaux de débogage détaillés dans une mémoire tampon et les ajoute aux fichiers journaux lorsqu'une erreur se produit. Par défaut, les niveaux d'erreur suivants déclenchent une trace arrière :
- Niveau 0 : échecs fatals
- Niveau 1 : défaillances critiques
- Niveau 2 : défaillances graves
Vous pouvez modifier ce comportement pour chaque processus SSSD en définissant l'option debug_level dans la section correspondante du fichier de configuration sssd.conf:
- Si vous définissez le niveau de débogage sur 0, seuls les événements de niveau 0 déclenchent une rétro-trace.
- Si vous définissez le niveau de débogage sur 1, les niveaux 0 et 1 déclenchent une rétro-trace.
- Si vous réglez le niveau de débogage sur 2 ou plus, les événements des niveaux 0 à 2 déclenchent une rétrotrace.
Vous pouvez désactiver cette fonction pour chaque processus SSSD en définissant l'option debug_backtrace_enabled sur false dans la section correspondante de sssd.conf:
[sssd] debug_backtrace_enabled = true debug_level=0 ... [nss] debug_backtrace_enabled = false ... [domain/idm.example.com] debug_backtrace_enabled = true debug_level=2 ... ...
La valeur de hachage SSH par défaut de SSSD est désormais cohérente avec les paramètres d'OpenSSH
La valeur par défaut de ssh_hash_known_hosts a été changée en false. Elle est maintenant cohérente avec la configuration d'OpenSSH, qui ne hache pas les noms d'hôtes par défaut.
Toutefois, si vous devez continuer à hacher les noms d'hôtes, ajoutez ssh_hash_known_hosts = True à la section [ssh] du fichier de configuration /etc/sssd/sssd.conf.
Directory Server 12.0 est basé sur la version amont 2.0.14
Directory Server 12.0 est basé sur la version amont 2.0.14 qui apporte un certain nombre de corrections de bogues et d'améliorations par rapport à la version précédente. Pour une liste complète des changements notables, lisez les notes de mise à jour de la version amont avant de procéder à la mise à jour :
- https://directory.fedoraproject.org/docs/389ds/releases/release-2-0-14.html
- https://directory.fedoraproject.org/docs/389ds/releases/release-2-0-13.html
- https://directory.fedoraproject.org/docs/389ds/releases/release-2-0-12.html
- https://directory.fedoraproject.org/docs/389ds/releases/release-2-0-11.html
- https://directory.fedoraproject.org/docs/389ds/releases/release-2-0-10.html
- https://directory.fedoraproject.org/docs/389ds/releases/release-2-0-9.html
- https://directory.fedoraproject.org/docs/389ds/releases/release-2-0-8.html
- https://directory.fedoraproject.org/docs/389ds/releases/release-2-0-7.html
- https://directory.fedoraproject.org/docs/389ds/releases/release-2-0-6.html
- https://directory.fedoraproject.org/docs/389ds/releases/release-2-0-5.html
- https://directory.fedoraproject.org/docs/389ds/releases/release-2-0-4.html
- https://directory.fedoraproject.org/docs/389ds/releases/release-2-0-3.html
- https://directory.fedoraproject.org/docs/389ds/releases/release-2-0-2.html
- https://directory.fedoraproject.org/docs/389ds/releases/release-2-0-1.html
Directory Server stocke désormais les fichiers de bases de données mappés en mémoire sur un système de fichiers tmpfs
Dans Directory Server, le paramètre nsslapd-db-home-directory définit l'emplacement des fichiers en mémoire des bases de données. Cette amélioration modifie la valeur par défaut du paramètre, qui passe de /var/lib/dirsrv/slapd-instance_name/db/ à /dev/shm/. Par conséquent, lorsque les bases de données internes sont stockées sur un système de fichiers tmpfs, les performances de Directory Server augmentent.
