Chapitre 5. Authentification et interopérabilité
Auparavant il n'était pas possible de gérer les clés publiques SSH de l'utilisateur et de l'hôte de manière centralisée. Red Hat Enterprise Linux 6.3 inclut la gestion de clé publique SSH pour les serveurs Identity Management (serveur de gestion des identités) en tant qu'aperçu technologique. OpenSSH sur les clients Identity Management est automatiquement configuré pour utiliser des clés publiques qui sont stockées sur le serveur Identity Management. Les identités de l'hôte et utilisateur SSH peuvent maintenant être gérée de manière centralisée dans Identity Management. BZ#803822n
Red Hat Enterprise Linux 6.3 offre la possibilité de contrôler le contexte SELinux d'un utilisateur sur un système distant. Les règles de mappage de l'utilisateur SELinux peuvent être définies et, optionnellement, associées aux règles HBAC. Ces mappages définissent le contexte reçu par un utilisateur selon l'hôte auprès duquel ils se connectent et selon l'appartenance de groupe. Lorsqu'un utilisateur se connecte à un hôte distant qui est configuré pour utiliser SSSD avec le backend Identity Management, le contexte SELinux de l'utilisateur est automatiquement définit en fonction des règles de mappages définies pour cet utilisateur. Pour obtenir davantage d'informations, reportez-vous à http://freeipa.org/page/SELinux_user_mapping. Cette fonctionnalité est considérée comme un aperçu technologique. BZ#803821
SSH peut maintenant être paramétré de manière à requérir de multiples façons de s'authentifier (tandis que précédemment, SSH permettait de multiples façons de s'authentifier, mais une seule était requise pour une établir une connexion réussie) ; par exemple, se connecter à une machine activée SSH requiert qu'une phrase de passe ainsi qu'une clé publique soit saisies. Les options RequiredAuthentications1 et RequiredAuthentications2 peuvent être configurées dans le fichier /etc/ssh/sshd_config pour spécifier les authentifications requises pour une connexion réussie. Par exemple :
~]# echo "RequiredAuthentications2 publickey,password" >> /etc/ssh/sshd_config/etc/ssh/sshd_config mentionnées ci-dessus, veuillez vous reporter à la page man sshd_config. BZ#657378
Dans Red Hat Entreprise Linux 6.3, SSSD inclut une nouvelle fonctionnalité comme aperçu technologique : le support pour la mise en cache de mappages automount. Cette fonctionnalité fournit plusieurs avantages aux environnements qui opèrent avec autofs :
- La mappages automount mis en cache facilitent les opérations de montage à la machine cliente, même lorsque le serveur LDAP est injoignable et le serveur NFS reste joignable.
- Lorsque le démon
autofsest configuré pour rechercher les mappages automount via SSSD, seul un fichier doit être configuré :/etc/sssd/sssd.conf. Auparavant, le fichier/etc/sysconfig/autofsdevait être configuré pour récupérer des données autofs. - La mise en cache des mappages automount résulte en une performance plus rapide sur le client et en moins de trafic sur le serveur LDAP. BZ#761570
SSSD a modifié le comportement de l'option debug_level dans le fichier /etc/sssd/sssd.conf. Auparavant, il était possible de paramétrer l'option debug_level dans la section de configuration [sssd] et le résultat était qu'elle deviendrait le paramètre par défaut pour d'autres sections de configuration, à moins qu'elles ne la remplace de manière explicite.
debug_level soit toujours spécifiée indépendamment dans chaque section du fichier de configuration, au lieu d'acquérir la valeur par défaut de la section [sssd].
~]# python /usr/lib/python2.6/site-packages/sssd_update_debug_levels.pydebug_level a bien été spécifiée dans la section [sssd]. Si c'est en effet le cas, il ajoutera cette même valeur de niveau à chaque autre section dans le fichier sssd.conf dans lequel l'option debug_level n'est pas spécifiée. Si l'option debug_level existe déjà explicitement dans une autre section, elle restera inchangée.
Une nouvelle option, ldap_chpass_update_last_change, a été ajoutée à la configuration SSSD. Si cette option est activée, SSSD tentera de modifier l'attribut LDAP shadowLastChange sur l'heure actuelle. Remarquez que ceci est uniquement lié à un cas où la politique du mot de passe LDAP est utilisée (ce qui est habituellement effectué par un serveur LDAP). C'est-à-dire, lorsque l'opération étendue LDAP est utilisée pour modifier le mot de passe. Remarquez aussi que l'attribut doit être accessible en écriture par l'utilisateur modifiant le mot de passe. BZ#739312
