Chapitre 18. Gestion de l'identité
Ce chapitre répertorie les changements les plus notables apportés à la gestion des identités (IdM) entre RHEL 8 et RHEL 9.
18.1. Nouvelles fonctionnalités
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
Le domaine du fournisseur de fichiers implicites SSSD est désactivé par défaut
Le domaine fournisseur implicite SSSD files, qui récupère les informations sur les utilisateurs à partir de fichiers locaux tels que /etc/shadow et les informations sur les groupes à partir de /etc/groups, est désormais désactivé par défaut.
Pour récupérer des informations sur les utilisateurs et les groupes à partir de fichiers locaux avec SSSD :
Configurer SSSD. Choisissez l'une des options suivantes :
Configurez explicitement un domaine local avec l'option
id_provider=filesdans le fichier de configurationsssd.conf.[domain/local] id_provider=files ...
Activez le fournisseur
filesen définissant l'optionenable_files_domain=truedans le fichier de configurationsssd.conf.[sssd] enable_files_domain = true
Configurer le commutateur des services de noms.
# authselect enable-feature with-files-provider
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 du nouveau 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.
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.
