8.13. Gestion de l'identité
Le client RHEL 9 Kerberos ne parvient pas à authentifier un utilisateur à l'aide de PKINIT contre Heimdal KDC
Lors de l'authentification PKINIT d'un utilisateur IdM sur un client Kerberos RHEL 9, le Centre de distribution Heimdal Kerberos (KDC) sur RHEL 9 ou antérieur utilise l'algorithme de signature de sauvegarde SHA-1 car le client Kerberos ne prend pas en charge le champ supportedCMSTypes. Cependant, l'algorithme SHA-1 a été déprécié dans RHEL 9 et l'authentification de l'utilisateur échoue.
Pour contourner ce problème, activez la prise en charge de l'algorithme SHA-1 sur vos clients RHEL 9 à l'aide de la commande suivante :
# update-crypto-polices --set DEFAULT:SHA1
Par conséquent, l'authentification PKINIT fonctionne entre le client Kerberos et le KDC Heimdal.
Pour plus de détails sur les algorithmes de signature de sauvegarde pris en charge, voir Types de chiffrement Kerberos définis pour les identifiants d'algorithmes CMS.
L'authentification PKINIT d'un utilisateur échoue si un agent Kerberos RHEL 9 communique avec un agent Kerberos non RHEL 9
Si un agent Kerberos RHEL 9 interagit avec un autre agent Kerberos non RHEL 9 dans votre environnement, l'authentification d'un utilisateur par cryptographie à clé publique pour l'authentification initiale (PKINIT) échoue. Pour contourner le problème, effectuez l'une des actions suivantes :
Définissez la politique cryptographique de l'agent RHEL 9 sur
DEFAULT:SHA1pour autoriser la vérification des signatures SHA-1 :# update-crypto-polices --set DEFAULT:SHA1
Mettez à jour l'agent non RHEL 9 pour vous assurer qu'il ne signe pas les données CMS à l'aide de l'algorithme SHA-1. Pour cela, mettez à jour vos paquets Kerberos vers les versions qui utilisent SHA-256 au lieu de SHA-1 :
- CentOS 9 Stream : krb5-1.19.1-15
- RHEL 8.7 : krb5-1.18.2-17
- RHEL 7.9 : krb5-1.15.1-53
- Fedora Rawhide/36 : krb5-1.19.2-7
- Fedora 35/34 : krb5-1.19.2-3
Vous devez effectuer l'une de ces actions, que l'agent non corrigé soit un client Kerberos ou le Centre de distribution Kerberos (KDC).
Par conséquent, l'authentification PKINIT d'un utilisateur fonctionne correctement.
Notez que pour les autres systèmes d'exploitation, c'est la version krb5-1.20 qui garantit que l'agent signe les données du CMS avec SHA-256 au lieu de SHA-1.
La sous-politique DEFAULT:SHA1 doit être définie sur les clients RHEL 9 pour que PKINIT fonctionne avec les anciens KDC RHEL et les KDC AD
L'algorithme de condensé SHA-1 a été supprimé dans RHEL 9, et les messages CMS pour la cryptographie à clé publique pour l'authentification initiale (PKINIT) sont désormais signés avec l'algorithme SHA-256, plus puissant.
Alors que SHA-256 est utilisé par défaut à partir de RHEL 7.9 et RHEL 8.7, les anciens centres de distribution de clés (KDC) Kerberos sur RHEL 7.8 et RHEL 8.6 et antérieurs utilisent toujours l'algorithme de condensé SHA-1 pour signer les messages CMS. Il en va de même pour le centre de distribution de clés Active Directory (AD).
Par conséquent, les clients Kerberos de RHEL 9 ne parviennent pas à authentifier les utilisateurs à l'aide de PKINIT contre les éléments suivants :
- KDC fonctionnant sous RHEL 7.8 et antérieur
- KDC fonctionnant sous RHEL 8.6 et antérieur
- AD KDCs
Pour contourner le problème, activez la prise en charge de l'algorithme SHA-1 sur vos systèmes RHEL 9 à l'aide de la commande suivante :
# update-crypto-policies --set DEFAULT:SHA1
La prise en charge FIPS de la confiance AD nécessite la sous-politique cryptographique AD-SUPPORT
Active Directory (AD) utilise des types de chiffrement AES SHA-1 HMAC, qui ne sont pas autorisés par défaut en mode FIPS sur RHEL 9. Si vous souhaitez utiliser des hôtes IdM RHEL 9 avec une confiance AD, activez la prise en charge des types de chiffrement AES SHA-1 HMAC avant d'installer le logiciel IdM.
La conformité FIPS étant un processus qui implique des accords techniques et organisationnels, consultez votre auditeur FIPS avant d'activer la sous-politique AD-SUPPORT pour permettre aux mesures techniques de prendre en charge les types de chiffrement AES SHA-1 HMAC, puis installez RHEL IdM :
# update-crypto-policies --set FIPS:AD-SUPPORT
Directory Server se termine de manière inattendue lorsqu'il est démarré en mode de référence
En raison d'un bogue, le mode de renvoi global ne fonctionne pas dans Directory Server. Si vous démarrez le processus ns-slapd avec l'option refer en tant qu'utilisateur dirsrv, Directory Server ignore les paramètres du port et se termine de manière inattendue. Essayer d'exécuter le processus en tant qu'utilisateur root modifie les étiquettes SELinux et empêche le service de démarrer à l'avenir en mode normal. Il n'y a pas de solution de rechange disponible.
La configuration d'un renvoi pour un suffixe échoue dans Directory Server
Si vous définissez une référence de back-end dans Directory Server, la définition de l'état du back-end à l'aide de la commande dsconf <instance_name> backend suffix set --state referral échoue avec l'erreur suivante :
Error: 103 - 9 - 53 - Server is unwilling to perform - [] - need to set nsslapd-referral before moving to referral state
Par conséquent, la configuration d'un renvoi pour les suffixes échoue. Pour contourner le problème :
Réglez manuellement le paramètre
nsslapd-referral:# ldapmodify -D "cn=Directory Manager" -W -H ldap://server.example.com dn: cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config changetype: modify add: nsslapd-referral nsslapd-referral: ldap://remote_server:389/dc=example,dc=com
Définir l'état du back-end :
# dsconf <instance_name> backend suffix set --state referral
Par conséquent, avec la solution de contournement, vous pouvez configurer un renvoi pour un suffixe.
L'utilitaire dsconf n'a pas d'option pour créer des tâches de correction pour le plug-in entryUUID
L'utilitaire dsconf ne propose pas d'option permettant de créer des tâches de correction pour le plug-in entryUUID. Par conséquent, les administrateurs ne peuvent pas utiliser dsconf pour créer une tâche permettant d'ajouter automatiquement des attributs entryUUID aux entrées existantes. Une solution de contournement consiste à créer une tâche manuellement :
# ldapadd -D "cn=Directory Manager" -W -H ldap://server.example.com -x dn: cn=entryuuid_fixup___<time_stamp__,cn=entryuuid task,cn=tasks,cn=config objectClass: top objectClass: extensibleObject basedn: __<fixup base tree>__ cn: entryuuid_fixup___<time_stamp>__ filter: __<filtered_entry>__
Une fois la tâche créée, Directory Server corrige les entrées dont les attributs entryUUID sont manquants ou invalides.
Risque potentiel lié à l'utilisation de la valeur par défaut de l'option ldap_id_use_start_tls
L'utilisation de ldap:// sans TLS pour les recherches d'identité peut constituer un risque pour un vecteur d'attaque. En particulier une attaque de type "man-in-the-middle" (MITM) qui pourrait permettre à un pirate d'usurper l'identité d'un utilisateur en modifiant, par exemple, l'UID ou le GID d'un objet renvoyé lors d'une recherche LDAP.
Actuellement, l'option de configuration SSSD pour appliquer TLS, ldap_id_use_start_tls, est par défaut false. Assurez-vous que votre installation fonctionne dans un environnement de confiance et décidez s'il est sûr d'utiliser une communication non chiffrée pour id_provider = ldap. Notez que id_provider = ad et id_provider = ipa ne sont pas concernés car ils utilisent des connexions cryptées protégées par SASL et GSSAPI.
S'il n'est pas sûr d'utiliser des communications non chiffrées, appliquez le protocole TLS en définissant l'option ldap_id_use_start_tls sur true dans le fichier /etc/sssd/sssd.conf. Il est prévu de modifier le comportement par défaut dans une prochaine version de RHEL.
(JIRA:RHELPLAN-155168)
