11.13. Gestion de l'identité
MIT Kerberos ne prend pas en charge les certificats ECC pour PKINIT
MIT Kerberos n'implémente pas le document RFC5349 request for comments, qui décrit la conception de la prise en charge de la cryptographie à courbe elliptique (ECC) dans la cryptographie à clé publique pour l'authentification initiale (PKINIT). Par conséquent, le paquet MIT krb5-pkinit, utilisé par RHEL, ne prend pas en charge les certificats ECC. Pour plus d'informations, voir Prise en charge de la cryptographie à courbe elliptique (ECC) dans la cryptographie à clé publique pour l'authentification initiale dans Kerberos (PKINIT).
La sous-politique DEFAULT:SHA1 doit être définie sur les clients RHEL 9 pour que PKINIT fonctionne contre 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.
Cependant, le centre de distribution Kerberos (KDC) d'Active Directory (AD) utilise toujours l'algorithme de condensé SHA-1 pour signer les messages CMS. Par conséquent, les clients Kerberos RHEL 9 ne parviennent pas à authentifier les utilisateurs en utilisant PKINIT contre un KDC AD.
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
L'authentification PKINIT d'un utilisateur échoue si un agent Kerberos RHEL 9 communique avec un agent Kerberos non RHEL-9 et non AD
Si un agent Kerberos RHEL 9, qu'il s'agisse d'un client ou d'un centre de distribution Kerberos (KDC), interagit avec un agent Kerberos non RHEL-9 qui n'est pas un agent Active Directory (AD), l'authentification PKINIT de l'utilisateur é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 et non AD pour vous assurer qu'il ne signe pas les données CMS à l'aide de l'algorithme SHA-1. Pour cela, mettez à jour votre client Kerberos ou les paquets KDC avec 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
Par conséquent, l'authentification PKINIT de l'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 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
Le client Heimdal ne parvient pas à authentifier un utilisateur à l'aide de PKINIT contre le KDC RHEL 9
Par défaut, un client Heimdal Kerberos initie l'authentification PKINIT d'un utilisateur IdM en utilisant Modular Exponential (MODP) Diffie-Hellman Group 2 pour Internet Key Exchange (IKE). Cependant, le Centre de distribution Kerberos (KDC) du MIT sur RHEL 9 ne prend en charge que les groupes MODP 14 et 16.
Par conséquent, la demande de pré-authentification échoue avec l'erreur krb5_get_init_creds: PREAUTH_FAILED sur le client Heimdal et Key parameters not accepted sur le KDC MIT RHEL.
Pour contourner ce problème, assurez-vous que le client Heimdal utilise le groupe MODP 14. Définissez le paramètre pkinit_dh_min_bits dans la section libdefaults du fichier de configuration du client sur 1759 :
[libdefaults] pkinit_dh_min_bits = 1759
En conséquence, le client Heimdal complète la pré-authentification PKINIT contre le KDC MIT de RHEL.
IdM en mode FIPS ne prend pas en charge l'utilisation du protocole NTLMSSP pour établir une confiance bidirectionnelle entre forêts
L'établissement d'une confiance bidirectionnelle entre Active Directory (AD) et Identity Management (IdM) avec le mode FIPS activé échoue parce que l'authentification NTLMSSP (New Technology LAN Manager Security Support Provider) n'est pas conforme à la norme FIPS. IdM en mode FIPS n'accepte pas le hachage NTLM RC4 que le contrôleur de domaine AD utilise lors de la tentative d'authentification.
Échec des demandes de certificats de transfert de technologie entre IdM et AD
Les informations du certificat d'attributs de privilèges (PAC) dans les tickets IdM Kerberos sont désormais signées avec le cryptage AES SHA-2 HMAC, qui n'est pas pris en charge par Active Directory (AD).
Par conséquent, les demandes de TGS entre IdM et AD, c'est-à-dire les configurations de confiance à double sens, échouent avec l'erreur suivante :
"Erreur générique (voir texte électronique) lors de l'obtention des informations d'identification pour <service principal>"
Le chiffrement et le déchiffrement de la chambre forte IdM échouent en mode FIPS
Le chiffrement OpenSSL RSA-PKCS1v15 est bloqué si le mode FIPS est activé. Par conséquent, les chambres fortes de gestion de l'identité (IdM) ne fonctionnent pas correctement, car IdM utilise actuellement le cryptage PKCS1v15 pour envelopper la clé de session avec le certificat de transport.
Les utilisateurs IdM migrés peuvent être incapables de se connecter en raison de la non-concordance des identifiants de domaine
Si vous avez utilisé le script ipa migrate-ds pour migrer des utilisateurs d'un déploiement IdM à un autre, ces utilisateurs peuvent avoir des problèmes pour utiliser les services IdM parce que leurs identifiants de sécurité (SID) n'ont pas le SID du domaine de l'environnement IdM actuel. Par exemple, ces utilisateurs peuvent récupérer un ticket Kerberos avec l'utilitaire kinit, mais ils ne peuvent pas se connecter. Pour résoudre ce problème, consultez l'article suivant de la base de connaissances : Migrated IdM users unable to log in due to mismatching domain SIDs (Utilisateurs IdM migrés incapables de se connecter en raison de la non-concordance des SID de domaine).
(JIRA:RHELPLAN-109613)
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)
