Kapitel 5. Authentifizierung und Interoperabilität
Bislang war es nicht möglich, öffentliche SSH-Schlüssel von Host und Benutzer zentral zu verwalten. Red Hat Enterprise Linux 6.3 implementiert nun die Verwaltung von öffentlichen SSH-Schlüsseln für Identitätsverwaltungs-Server als Technologievorschau. OpenSSH ist auf Identitätsverwaltungs-Clients automatisch zur Verwendung öffentlicher Schlüssel konfiguriert, die auf dem Identitätsverwaltungs-Server gespeichert sind. SSH-Host- und SSH-Benutzeridentitäten können nun zentral in der Identitätsverwaltung verwaltet werden. BZ#803822n
Red Hat Enterprise Linux 6.3 führt die Fähigkeit ein, den SELinux-Kontext eines Benutzers auf einem entfernten System zu steuern. Regeln zur SELinux-Benutzerzuordnung können definiert werden und optional mit HBAC-Regeln verknüpft werden. Diese Zuordnungen definieren den Kontext, den ein Benutzer erhält, abhängig von dem Host, an dem er sich anmeldet, und der Gruppenmitgliedschaft. Wenn sich ein Benutzer an einem entfernten Host anmeldet, der zur Verwendung von SSSD mit dem Identitätsverwaltungs-Backend konfiguriert ist, so wird der SELinux-Kontext des Benutzers automatisch eingestellt entsprechend der Zuordnungsregeln, die für diesen Benutzer definiert wurden. Weitere Informationen finden Sie unter http://freeipa.org/page/SELinux_user_mapping. Dieses Feature ist als Technologievorschau enthalten. BZ#803821
SSH kann nun derart eingerichtet werden, um mehrere Authentifizierungswege zu erfordern (bislang erlaubte SSH zwar mehrere Authentifizierungswege, jedoch war davon nur einer für eine erfolgreiche Anmeldung erforderlich); so z.B. ein Rechner mit aktiviertem SSH, der die Angabe sowohl einer Passphrase als auch eines öffentlichen Schlüssels erfordert. Die Optionen RequiredAuthentications1
und RequiredAuthentications2
können in der /etc/ssh/sshd_config
Datei konfiguriert werden, um Authentifizierungen zu spezifizieren, die für eine erfolgreiche Anmeldung erforderlich sind. Zum Beispiel:
~]# echo "RequiredAuthentications2 publickey,password" >> /etc/ssh/sshd_config
/etc/ssh/sshd_config
-Optionen einen Blick auf die sshd_config
-Handbuchseite. BZ#657378
In Red Hat Enterprise Linux 6.3 implementiert SSSD ein neues Technologievorschau-Feature: Unterstützung zum Cachen von automount-Zuordnungen. Dieses Feature bietet gegenüber Umgebungen, die mit autofs
arbeiten, mehrere Vorteile:
- Gecachte automount-Zuordnungen erleichtern einem Client-Rechner das Durchführen von Einhängeoperationen, wenn der LDAP-Server nicht erreichbar ist, der NFS-Server jedoch weiterhin verfügbar ist.
- Wenn der
autofs
-Daemon konfiguriert wurde, um automount-Zuordnungen via SSSD abzurufen, muss nur eine einzige Datei konfiguriert werden:/etc/sssd/sssd.conf
. Bislang musste die/etc/sysconfig/autofs
-Datei konfiguriert werden, um autofs-Daten abzurufen. - Das Cachen der automount-Zuordnungen ermöglicht bessere Performance auf dem Client und weniger Datenverkehr auf dem LDAP-Server. BZ#761570
SSSD hat das Verhalten der debug_level
-Option in der /etc/sssd/sssd.conf
-Datei geändert. Bislang war es möglich, die debug_level
-Option im [sssd]
-Konfigurationsabschnitt festzulegen, wodurch dies als Standardwert für andere Konfigurationsabschnitte übernommen wurde, sofern dort der Wert nicht ausdrücklich außer Kraft gesetzt wurde.
debug_level
-Option in allen Abschnitten der Konfigurationsdatei unabhängig voneinander zu spezifizieren, da diese nicht länger einen Standardwert vom [sssd]
-Abschnitt beziehen.
~]# python /usr/lib/python2.6/site-packages/sssd_update_debug_levels.py
debug_level
-Option im [sssd]
Abschnitt spezifiziert war. Ist dies der Fall, fügt es denselben Level-Wert in all jene anderen Abschnitte der sssd.conf
-Datei ein, in denen debug_level
nicht spezifiziert ist. Falls die debug_level
-Option in einem anderen Abschnitt bereits explizit existiert, wird dieser vorhandene Wert unverändert belassen.
Eine neue Option namens ldap_chpass_update_last_change
wurde zur SSSD-Konfiguration hinzugefügt. Falls diese Option aktiviert ist, versucht SSSD, das shadowLastChange
-LDAP-Attribut auf die aktuelle Zeit zu ändern. Beachten Sie, dass dies nur dann der Fall ist, wenn die LDAP-Passwortrichtlinie verwendet wird (normalerweise vom LDAP-Server gehandhabt), d.h., wenn die erweiterte LDAP-Operation zur Änderung des Passworts verwendet wird. Beachten Sie zudem, dass das Attribut für den Benutzer, der das Passwort ändert, schreibbar sein muss. BZ#739312