11.12. Gestion de l'identité
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.
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 qui n'ont pas de SID ne peuvent pas se connecter à IdM après une mise à jour
Après la mise à niveau de votre réplique IdM vers RHEL 9.2, le centre de distribution Kerberos (KDC) IdM peut ne pas délivrer de tickets d'attribution de tickets (TGT) aux utilisateurs qui n'ont pas d'identifiants de sécurité (SID) attribués à leurs comptes. Par conséquent, les utilisateurs ne peuvent pas se connecter à leurs comptes.
Pour contourner le problème, générez des SID en exécutant la commande suivante en tant qu'administrateur IdM sur une autre réplique IdM dans la topologie :
# ipa config-mod --enable-sid --add-sids
Ensuite, si les utilisateurs ne peuvent toujours pas se connecter, examinez le journal des erreurs du serveur d'annuaire. Vous devrez peut-être ajuster les plages d'ID pour inclure les identités POSIX des utilisateurs.
Voir la solution de la base de connaissances When upgrading to RHEL9, IDM users are not able to login anymore pour plus d'informations.
Jira:RHELPLAN-157939
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
MIT krb5 L'utilisateur ne parvient pas à obtenir un TGT AD en raison de l'incompatibilité des types de chiffrement générant le PAC de l'utilisateur
Dans MIT krb5 1.20 et les paquets ultérieurs, un certificat d'attribut de privilège (PAC) est inclus par défaut dans tous les tickets Kerberos. Le Centre de distribution Kerberos (KDC) du MIT sélectionne le type de chiffrement le plus puissant disponible pour générer la somme de contrôle du KDC dans le PAC, qui est actuellement le type de chiffrement AES HMAC-SHA2 défini dans la RFC8009. Cependant, Active Directory (AD) ne prend pas en charge cette RFC. Par conséquent, dans une configuration AD-MIT cross-realm, un utilisateur de MIT krb5 ne parvient pas à obtenir un ticket AD (TGT) parce que le TGT cross-realm généré par MIT KDC contient un type de somme de contrôle KDC incompatible dans le PAC.
Pour contourner le problème, définissez le paramètre disable_pac à true pour le domaine MIT dans la section [realms] du fichier de configuration /var/kerberos/krb5kdc/kdc.conf. En conséquence, le KDC du MIT génère des tickets sans PAC, ce qui signifie qu'AD ne procède pas à la vérification de la somme de contrôle et qu'un utilisateur de MIT krb5 peut obtenir un TGT AD.
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
L'ajout d'une réplique RHEL 9 en mode FIPS à un déploiement IdM en mode FIPS initialisé avec RHEL 8.6 ou une version antérieure échoue
La politique cryptographique FIPS par défaut de RHEL 9 visant à se conformer à la norme FIPS 140-3 n'autorise pas l'utilisation de la fonction de dérivation de clé des types de chiffrement AES HMAC-SHA1, telle que définie par la RFC3961, section 5.1.
Cette contrainte constitue un obstacle lors de l'ajout d'une réplique Identity Management (IdM) RHEL 9 en mode FIPS à un environnement IdM RHEL 8 en mode FIPS dans lequel le premier serveur a été installé sur un système RHEL 8.6 ou antérieur. En effet, il n'existe pas de types de chiffrement communs entre RHEL 9 et les versions précédentes de RHEL, qui utilisent généralement les types de chiffrement AES HMAC-SHA1 mais pas les types de chiffrement AES HMAC-SHA2.
Vous pouvez afficher le type de cryptage de votre clé principale IdM en entrant la commande suivante sur le serveur :
# kadmin.local getprinc K/M | grep -E '^Key:'
Pour contourner le problème, activez l'utilisation de AES HMAC-SHA1 sur la réplique RHEL 9 :
update-crypto-policies --set FIPS:AD-SUPPORT
- AVERTISSEMENT
- Cette solution de contournement pourrait être contraire à la conformité FIPS.
Par conséquent, l'ajout de la réplique RHEL 9 au déploiement IdM se déroule correctement.
Notez que des travaux sont en cours pour fournir une procédure permettant de générer les clés Kerberos cryptées AES HMAC-SHA2 manquantes sur les serveurs RHEL 7 et RHEL 8. Cela permettra d'atteindre la conformité FIPS 140-3 sur la réplique RHEL 9. Toutefois, ce processus ne sera pas entièrement automatisé, car la conception de la cryptographie des clés Kerberos rend impossible la conversion des clés existantes en différents types de cryptage. La seule solution consiste à demander aux utilisateurs de renouveler leurs mots de passe.
SSSD enregistre correctement les noms DNS
Auparavant, si le DNS était mal configuré, SSSD échouait toujours lors de la première tentative d'enregistrement du nom DNS. Pour contourner ce problème, cette mise à jour fournit un nouveau paramètre : dns_resolver_use_search_list. Définissez dns_resolver_use_search_list = false pour éviter d'utiliser la liste de recherche DNS.
Bugzilla:1608496
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.
Directory Server ne peut importer des fichiers LDIF qu'à partir de /var/lib/dirsrv/slapd-instance_name/ldif/
Depuis RHEL 8.3, Red Hat Directory Server (RHDS) utilise ses propres répertoires privés et la directive PrivateTmp systemd est activée par défaut pour les services LDAP. Par conséquent, RHDS ne peut importer des fichiers LDIF qu'à partir du répertoire /var/lib/dirsrv/slapd-instance_name/ldif/ . Si le fichier LDIF est stocké dans un répertoire différent, tel que /var/tmp, /tmp, ou /root, l'importation échoue avec une erreur similaire à la suivante :
Could not open LDIF file "/tmp/example.ldif", errno 2 (No such file or directory)
Pour contourner ce problème, procédez comme suit :
Déplacer le fichier LDIF dans le répertoire
/var/lib/dirsrv/slapd-instance_name/ldif/répertoire :# mv /tmp/example.ldif /var/lib/dirsrv/slapd-instance_name__/ldif/Définir les autorisations permettant à l'utilisateur
dirsrvde lire le fichier :# chown dirsrv /var/lib/dirsrv/slapd-instance_name/ldif/example.ldifRétablir le contexte SELinux :
# restorecon -Rv /var/lib/dirsrv/slapd-instance_name/ldif/
Pour plus d'informations, voir l'article de la solution LDAP Service cannot access files under the host's /tmp and /var/tmp directories.
