Chapitre 2. Authentification
ca-certificate rebasé sur la version 2.4
Le paquet ca-certificates a été mis à niveau à la version en amont 2.4, qui fournit un certain nombre de correctifs de bogues et d'améliorations par rapport à la version précédente. Plus particulièrement, ca-certificates contient désormais les modifications suivantes :
Mozilla a précédemment supprimé sa confiance de plusieurs certificats CA hérités contenant des clés RSA 1024 bits. Cette version du paquet ca-certificates modifie la liste Mozilla de manière à continuer à faire confiance à ces certififcats CA hérités par défaut. Ces modifications ont été effectuées pour s'assurer de la compatibilité avec des déploiements PKI existants et avec des logiciels basés sur OpenSSL ou GnuTLS.
Le paquet ca-certificates inclut désormais la commande
ca-legacy, qui peut être utilisée pour désactiver les modifications de compatibilité mentionnées. Veuillez consulter la page de manuel ca-legacy(8) pour obtenir davantage d'informations sur la manière d'utiliser la commande.
Il est également recommandé aux utilisateurs qui souhaitent désactiver les modifications héritées de se référer à l'article de la base des connaissances 1413643, qui fournit des détails sur ces modifications et les conséquences potentielles de leur désactivation.
Remarquez que l'utilisation du stockage CA unifié est requise pour être en mesure d'utiliser la commande
ca-legacy. Veuillez consulter la page de manuel update-ca-trust(8) pour apprendre comment activer le stockage CA unifié.
Prise en charge des confiances à sens unique
Identity Management autorise désormais l'utilisateur à configurer une confiance à sens unique en exécutant la commande
ipa trust-add.
openldap rebasé sur la version 2.4.40
Les paquets openldap ont été mis à niveau à la version en amont 2.4.40, qui fournit un certain nombre de correctifs de bogues ainsi qu'une amélioration par rapport à la version précédente. Plus particulièrement, des règles de correspondance ORDERING ont été ajoutées aux descriptions de type d'attribut
ppolicy. Parmi les bogues corrigés figure : Le serveur ne se termine plus de manière inattendue lors du traitement des archives SRV, et des informations objectClass manquantes ont été ajoutées, celles-ci autorisent l'utilisateur à modifier la configuration frontale par le biais de moyens standards.
Authentification du cache sur SSSD
L'authentification du cache sans tentative de reconnexion est désormais disponible sur SSSD même en mode en ligne. Une authentification directe sur le serveur réseau de manière répétitive pourrait causer une latence d'application excessive, qui pourrait rendre le processus assez long.
SSSD autorise le mappage d'UID et de GID sur des clients individuels
Il est désormais possible de mapper des utilisateurs avec un UID et un GID différent sur des clients Red Hat Enterprise Linux spécifiques à travers une configuration du côté client en utilisant SSSD. Cette possibilité d'outrepasser le côté client peut résoudre des problèmes causés par les duplications d'UID et de GID.
SSSD peut désormais refuser l'accès SSH aux comptes verrouillés
Auparavant, lorsque SSSD utilisait OpenLDAP comme base de données d'authentification, les utilisateurs pouvaient s'authentifier sur le système avec succès en utilisant une clé SSH même après le verrouillage du compte utilisateur. Le paramètre
ldap_access_order accepte désormais la valeur ppolicy, qui peut refuser l'accès SSH à un utilisateur se trouvant dans la situation décrite. Pour obtenir davantage d'informations sur l'utilisation de ppolicy, veuillez consulter la description ldap_access_order sur la page de manuel sssd-ldap(5).
L'utilitaire sudo est désormais capable de vérifier le checksum des commandes
La configuration de l'utilitaire sudo peut désormais stocker le checksum d'une commande ou d'un script autorisé. Lorsque la commande ou le script est exécuté à nouveau, le checksum est comparé au checksum stocké pour vérifier si quelquechose a changé. Si la commande ou le binaire a été modifié, l'utilitaire sudo refusera d'exécuter la commande ou journalisera un avertissement. Cette fonctionnalité permet de déléguer les responsabilités et les activités de résolution de problèmes correctement dans le cas où un incident se produirait.
Prise en charge smart card SSSD
Désormais, SSSD prend en charge les smart cards pour une authentification locale. Avec cette fonctionnalité, l'utilisateur peut utiliser une smart card pour journaliser sur le système à l'aide d'un console basée texte ou graphique, ainsi qu'en utilisant des services locaux, comme le service sudo. L'utilisateur place la smart card dans le lecteur et fournit le nom d'utilisateur et le code PIN de la smart card à l'invite de connexion.Si le certificat de la smart card est vérifié, l'utilisateur est alors authentifié avec succès.
Remarquez qu'actuellement, SSSD n'autorise pas à l'utilisateur d'acquérir un ticket Kerberos en utilisant une smart card. Pour obtenir un ticket Kerberos, l'utilisateur doit s'authentifier en utilisant l'utilitaire kinit.
Prise en charge de mutiples profils de certificats
Désormais, Identity Management prend en charge les profils multiples pour délivrer des certificats de serveur et autres, au lieu de ne prendre en charge qu'un profil de certificat à serveur unique. Les profils sont stockés dans le système Certificate.
Password Vault
Une nouvelle fonctionnalité autorisant le stockage central sécurités des informations privées d'utilisateur, comme les mots de passe et les clés, a été ajoutée à Identity Management. Password Vault est créé au-dessus du sous-système KRA (« Key Recovery Authority ») de PKI (« Public Key Infrastructure »).
Prise en charge DNSSEC sur Identity Management
Les serveurs Identity Management avec DNS intégré prennent désormais en charge DNSSEC (« DNS Security Extensions »), qui est un ensemble d'extensions de DNS améliorant la sécurité du protocole DNS. Des zones DNS hébergées sur serveurs Identity Management peuvent être automatiquement signées en utilisant DNSSEC. Les clés de chiffrement sont automatiquement générées et pivotées.
Il est recommandé aux utilisateurs qui décident de sécuriser leurs zones DNS avec DNSSEC de lire et suivre ces documents :
DNSSEC Operational Practices, Version 2 : http://tools.ietf.org/html/rfc6781#section-2
Secure Domain Name System (DNS) Deployment Guide : http://dx.doi.org/10.6028/NIST.SP.800-81-2
Remarquez que les serveurs Identity Management servers avec DNS intégré utilisent DNSSEC pour valider les réponses DNS obtenues des autres serveurs DNS. Ceci peut affecter la disponibilité des zones DNS qui ne sont pas configurées conformément aux pratiques de dénomination recommandées décrites dans le Guide de mise en réseau Red Hat Enterprise Linux : https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Configure_Host_Names.html#sec-Recommended_Naming_Practices
Proxy HTTPS Kerberos dans Identity Management
Une fonction proxy KDC (« Key Distribution Center »), interopérable avec l'implémentation MS-KKDCP (« Microsoft Kerberos KDC Proxy Protocol »), est désormais disponible sur Identity Management et autorise aux clients d'accéder aux services KDC et
kpasswd en utilisant HTTPS. Les administrateurs système peuvent désormais exposer le proxy sur le bord de leur réseauen implémentant un simple proxy HTTPS inversé sans avoir besoin de paramétrer et gérer une application dédiée.
Réactualisation en arrière-plan des entrées mises en cache
Désormais, SSSD autorise aux entrées du cache d'être mises à jour hors-bande en arrière-plan. Avant cette mise à jour, lorsque la validité des entrées mises en cache expirait, SSSD les récupérait du serveur distant et les stockait à nouveau dans la base de données, ce qui prenait assez longtemps. Avec cette mise à jour, les entrées sont retournées instantanément car le serveur principal les conserve à jour à tout moment. Remarquez que ceci cause une charge plus importante sur le serveur car SSSD télécharge les entrées de manière périodique plutôt qu'à la demande.
Mise en cache des opérations initgroups
Le cache mémoire rapide SSSD prend désormais en charge les opérations
initgroups, qui améliore la vitesse de traitement des initgroups et augmente les performances de certaines applications, par exemple GlusterFS et slapi-nis.
Négociation d'authentification rationalisée avec mod_auth_gssapi
Identity Management utilise désormais le module
mod_auth_gssapi, qui utilise les appels GSSAPI au lieu des appels Kerberos directs utilisés par l'ancien module mod_auth_kerb utilisé.
Capacités de gestion de cycle de vie d'utilisateur
La gestion des cycles de vie des utilisateurs donne à l'administrateur un plus grand degré de contrôle sur l'activation et la désactivation des comptes utilisateurs. L'administrateur peut désormais provisionner des nouveaux comptes utilisateurs en les ajoutant à une zone de production sans les activer totalement, il peut activer des comptes utilisateurs désactivés pour les rendre totalement opérationnels, ou désactiver les comptes utilisateurs sans totalement les supprimer de la base de données.
Les capacités de gestion de cycle de vie des utilisateurs apportent d'importants bénéfices à des déploiements IdM de grande taille. Remarquez que des utilisateurs peuvent également être ajoutés à la zone de production directement depuis un client LDAP standard, en utilisant des opérations LDAP directes. Précédemment, IdM prenait uniquement en charge la gestion des utilisateurs utilisant des outils de ligne de commande IdM ou l'interface utilisateur web IdM.
Prise en charge SCEP sur certmonger
Le service
certmonger a été mis à jour pour prendre en charge le protocole SCEP (« Simple Certificate Enrollment Protocol »). Il est désormais possible de délivrer un nouveau certificat et de renouveller ou remplacer des certificats existants via SCEP.
Nouveaux paquets : ipsilon
Les paquets ipsilon offrent le service de fournisseur d'identité pour les SSO (« Single sign-on ») fédérés. Ipsilon lie les fournisseurs d'authentification et les applications ou utilitaires pour qu'ils autorisent SSO. Cela inclut un serveur et des utilitaires pour configurer les fournisseurs de service basés Apache.
L'authentification utilisateur pour le SSO fourni par Ipsilon est effectuée avec un système de gestion des identités séparé, comme un serveur Identity Management. Ipsilon communique avec diverses applications et utilitaires à travers des protocoles de fédération, tels que SAML ou OpenID.
NSS augmente les valeurs minimum acceptées de la puissance des clés
La bibliothèque NSS (« Network Security Services ») sur Red Hat Enterprise Linux 7.2 n'accepte plus les paramètres d'échange de clés DH (« Diffie-Hellman ») de moins de 768 bits, ni les certificats RSA et DSA avec des tailles de clé de moins de 1023 bits. Le renforcement de la valeur minimum acceptée des clés permet d'empêcher les attaques exploitant les vulnérabilités de sécurité connues, telles que Logjam (CVE-2015-4000) et FREAK (CVE-2015-0204).
Remarquez désormais que les tentatives de connexion à un serveur en utilisant des clés plus faibles que les nouvelles valeurs minimums échoueront, même si de telles connexions ont fonctionné dans les versions précédentes de Red Hat Enterprise Linux.
nss et nss-util rebasés à la version 3.19.1
Les paquets nss et nss-util ont été mis à niveau à la version en amont 3.19.1, qui offre un certain nombre de correctifs de bogues et améliorations comparé à la version précédente. Plus particulièrement, la mise à jour permet aux utilisateurs de mettre à niveau à la version Mozila Firefox 38 Extended Support et empêche aux personnes malveillantes d'exploiter la vulnérabilité de sécurité Logjam CVE-2015-4000.
Prise en charge complète des modules Apache pour IdM
Les modules Apache suivants pour IdM (« Identity Management »), ajoutés en tant qu'aperçu technologique sur Red Hat Enterprise Linux 7.1, sont désormais complètement pris en charge :
mod_authnz_pam, mod_lookup_identity, et mod_intercept_form_submit. Les modules Apache peuvent être utilisés par des applications externes pour effectuer des interactions plus serrées avec IdM, au-delà d'une simple authentification.
