Ein evtl. schon vorhandenes Kerberos Ticket kann auch über den Webbrowser zur Authentifizierung an Webseiten genutzt werden. Da der zentrale WebSSO Dienst der FAU diese Art der Authentifizierung unterstützt können somit alle angebundenen Webseiten ohne weitere Anpassungen ebenfalls davon Gebrauch machen.
Nach erfolgter Konfiguration Ihres Browsers, bedeutet dies, dass Sie automatisch via Kerberos am WebSSO Dienst der FAU angemeldet werden, sobald Sie auf eine entsprechend angebundene Webseite zugreifen – ohne zusätzliche Passworteingabe.
Voraussetzungen
Voraussetzung für diese Anleitung ist eine funktionierende Grundkonfiguration von Kerberos für Ihr System. Falls noch nicht geschehen, führen Sie bitte die entsprechenden Einrichtungsschritte wie beschrieben durch, bevor Sie dieser Anleitung weiter folgen.
Ob Ihr System korrekt konfiguriert ist, können Sie wie folgt prüfen.
bash$ klist
Ticket cache: FILE:/tmp/krb5cc_[UID]_Zn59m9
Default principal: [Kennung]@LINUX.FAU.DE
Valid starting Expires Service principal
01.06.2017 14:30:51 02.06.2017 00:30:51 krbtgt/LINUX.FAU.DE@LINUX.FAU.DE
Der Aufruf von klist sollte eine ähnliche Ausgabe wie im Beispiel als Ergebnis liefern.
Konfiguration
In der Regel übermitteln die gängigen Webbrowser ein evtl. vorhandenes Kerberos Ticket aus Sicherheitsgründen nicht automatisch. Um die Übermittlung für bestimmte Domains freizuschalten bedarf es je nach Browser einiger spezieller Einstellungen.
In den unten aufgeführten Konfigurationsbeispielen wird jeweils der zentrale WebSSO Dienst der FAU freigeschalten. Für andere Dienste, die nicht das zentrale SSO nutzen sind zusätzliche Einträge erforderlich.
Mozilla Firefox
Diese Einstellung wirkt nur für den angemeldeten Benutzer!
Zur Konfiguration von Mozilla Firefox gehen Sie bitte wie folgt vor.
Geben Sie in die Adressleiste Ihres Browsers about:config ein
Kerberos Tickets haben eine begrenzte Laufzeit und müssen vor Ablauf durch eine erneute Passworteingabe erneuert werden. Der RRZE-Standard sieht eine Ticketlaufzeit von 10 Stunden vor, was für einen normalen Arbeitstag ausreichend ist.
Bei länger laufenden Prozessen, z.B. Simulationen oder sonstige aufwendige Berechnungen kann das Ablaufen des Kerberos Tickets jedoch zu Problemen führen.
Im Folgenden werden die Probleme beschrieben, die bei langlaufenden Prozessen im Zusammenhang mit Kerberos auftreten können und Lösungsmöglichkeiten aufgezeigt.
Problembeschreibung
In der Standardkonfiguration des LINUXKDC ist definiert, das ein Ticket maximal 10 Stunden gültig ist und bis auf maximal 7 Tage verlängert werden kann. (Dies entspricht übrigens auch den Windows-Standardwerten: https://technet.microsoft.com/en-us/library/dd277401.aspx)
Das heißt alle 10 Stunden muss ein Benutzer sein Passwort eingeben, um sein Ticket zu erneuern. Das kann z.B. implizit beim Entsperren des Bildschirms passieren oder explizit durch den Aufruf von kinit (siehe unten) oder erneutes Einloggen. Sperrt man ab und zu seinen Bildschirm (z.B. in der Mittagspause), so wird hier beim Entsperren ein neues Ticket vergeben und es entstehen keine Probleme.
Die Wahl der maximalen Ticketlaufzeit ist ein Kompromiss zwischen Komfort und Sicherheit, da einmal ausgestellte Tickets im Falle des Missbrauchs nicht widerrufen werden können und so für die gesamte Restlaufzeit des Tickets benutzbar bleiben.
Durch Zusatztools wie krenew (siehe unten) kann eine automatisierte Verlängerung des Tickets auf die maximale Laufzeit von 7 Tagen erreicht werden.
Für Prozesse, die über einen längeren Zeitraum Berechnungen anstellen und auf ein gültiges Ticket (z.B. zum Zugriff auf das Home-Verzeichnis) angewiesen sind, kann ein ablaufendes Ticket allerdings zum Problem werden. Eigentlich möchte man sicherstellen, dass das Ticket bis zur Beendigung des Prozesses nicht abläuft.
Lösungsmöglichkeiten
Verschiedene Strategien für langlaufende Prozesse mit Kerberos.
Mit kinit kann explizit ein neues Ticket beim LINUXKDC angefordert werden.
Unter Verwendung bestimmter Optionen kann ein länger laufendes bzw. ein spezielles, verlängerbares Ticket erworben werden, um damit langlaufende Prozesse auszuführen. Im Folgenden werden einige Anwendungsszenarien dokumentiert.
Ticket erneuern
Dies ist der Standard-Weg, um ein neues Ticket mit der Standardlaufzeit von 10 Stunden anzufordern oder ein bestehendes zu erneuern.
bash$ kinit
Password for [Kennung]@LINUX.FAU.DE:
bash$ klist
Ticket cache: FILE:/tmp/krb5cc_[UID]_kZe3jz
Default principal: [Kennung]@LINUX.FAU.DE
Valid starting Expires Service principal
05.04.2017 15:33:55 06.04.2017 01:33:55 krbtgt/LINUX.FAU.DE@LINUX.FAU.DE
Ticket mit erweiterter/definierter Laufzeit anfordern
Die Standardlaufzeit von 10 Stunden ist ein eine clientseitige Beschränkung, die mit einem Parameter auf das serverseitige Limit von 24 Stunden angehoben werden kann.
# Ticket mit einer Laufzeit (lifetime) von 24 Stunden anfordern (=maximal mögliche Laufzeit ohne Verlängerung)
bash$ kinit -l 24h
Password for [Kennung]@LINUX.FAU.DE:
bash$ klist
Ticket cache: FILE:/tmp/krb5cc_[UID]_kZe3jz
Default principal: [Kennung]@LINUX.FAU.DE
Valid starting Expires Service principal
05.04.2017 15:38:13 06.04.2017 15:38:13 krbtgt/LINUX.FAU.DE@LINUX.FAU.DE
Verlängerbares Ticket anfordern
Sollte das immer noch nicht ausreichen, kann ein spezielles, verlängerbares Ticket angefordert werden. Dieses kann für maximal 7 Tage ohne Passworteingabe, aber durch Verwendung von krenew, gültig gehalten werden.
# Ticket mit Verlängerungsmöglichkeit (renewable) auf 7 Tage anfordern (=maximal mögliche Verlängerung)
bash$ kinit -r 7d
Password for [Kennung]@LINUX.FAU.DE:
bash$ klist
Ticket cache: FILE:/tmp/krb5cc_[UID]_kZe3jz
Default principal: [Kennung]@LINUX.FAU.DE
05.04.2017 15:40:37 06.04.2017 01:40:37 krbtgt/LINUX.FAU.DE@LINUX.FAU.DE
renew until 12.04.2017 15:40:37
Beachten Sie die letzte Zeile im Beispiel. Diese zeigt an, dass ein verlängerbares Ticket erworben wurde.
Der Einsatz von krenew wird im folgenden Absatz beschrieben.
Automatisierte Verlängerung durchführen (max. 7 Tage Laufzeit)
Eine Möglichkeit zur automatisierten Verlängerung von Tickets ist die Verwendung von krenew.
So kann automatisiert z.B. jede Stunde geprüft werden, ob das aktuelle Ticket bald abläuft und ggf. eine Verlängerung des Tickets beim LINUXKDC angefordert werden.
Voraussetzung hierfür ist die Verwendung eines erneuerbaren (renewable) Tickets. Wie Sie ein solches Ticket anfordern können finden Sie oben in der Dokumentation zum Befehl kinit (siehe oben).
Installation und Anwendung können wie folgt durchgeführt werden.
bash$ sudo apt-get install kstart
...
bash$ klist
Ticket cache: FILE:/tmp/krb5cc_[UID]_kZe3jz
Default principal: [Kennung]@LINUX.FAU.DE
Valid starting Expires Service principal
05.04.2017 12:49:29 05.04.2017 22:49:29 krbtgt/LINUX.FAU.DE@LINUX.FAU.DE
renew until 12.04.2017 12:49:29
bash$ krenew -v -- sh -c './compute_job.sh >> compute_job.log'
krenew: renewing credentials for [Kennung]@LINUX.FAU.DE
Die Zeile renew until 12.04.2017 12:49:29
zeigt an bis wann der Job abgeschlossen sein muss, bzw. wie lange das Ticket maximal verlängert werden kann.
Wichtig!
If a command is given, krenew makes a copy of the ticket cache and
creates a private ticket cache just for that command, thus isolating it
from later destruction of the original ticket cache. This allows
krenew to maintain authentication for a command even if, for example,
the user running the command logs out and OpenSSH destroys their
original ticket cache.
Das bedeutet, dass das Kommando auch z.B. nach Beendigung einer SSH-Session noch über ein gültiges Ticket verfügt.
Allerdings wird dadurch auch verhindert, dass durch ein erneutes Einloggen beziehungsweise einen Aufruf von kinit das „Kommando-Ticket“ verlängert wird.
Nur lokale Ressourcen verwenden (unbegrenzte Laufzeit)
Durch Verwendung lokaler Ressourcen kann die Abhängigkeit von einem gültigen Kerberos Ticket vermieden werden.
In der Praxis bedeutet das normalerweise, dass alle nötigen Daten auf einer lokalen Festplatte vorgehalten werden müssen oder zumindest nicht im Home-Laufwerk oder einem anderen Netzlaufwerk, das Keberos verwendet, abgelegt sein dürfen.
Falls dies praktikabel ist, stellt es die stabilste Variante dar und ermöglicht eine unbegrenzte Laufzeit des Prozesses.
Kerberos Grundkonfiguration
Diese Anleitung beschreibt die vom RRZE empfohlene Grundkonfiguration zur Anbindung eines Ubuntu-Systems an die Kerberos Infrastruktur des RRZE. Die meisten Schritte sind allerdings allgemeingültig uns können für eigene Installationen leicht angepasst werden.
Nach Durchführung aller Schritte wird bei Systemanmeldung automatisch ein Kerberos-Ticket zur Verfügung gestellt und Anmeldungen per SSH an und von dem System sind per Kerberos-Authentifizierung möglich. Außerdem können CIFS und NFSv4 Netzlaufwerke kerberos-authentifiziert eingebunden werden.
# single services# for kerberos login authentication
bash$ sudo DEBIAN_FRONTEND=noninteractive apt-get install krb5-user libpam-krb5
# for kerberized ssh logins (client + server side)
bash$ sudo DEBIAN_FRONTEND=noninteractive apt-get install openssh-server openssh-client
# for kerberos nfsv4 mounts
bash$ sudo DEBIAN_FRONTEND=noninteractive apt-get install nfs-common keyutils
# for kerberized windows cifs mounts
bash$ sudo DEBIAN_FRONTEND=noninteractive apt-get install cifs-utils
# to enable kerberos support via GSSAPI for various software packages (e.g. pidgin)
bash$ sudo DEBIAN_FRONTEND=noninteractive apt-get install libsasl2-modules-gssapi-mit
Kerberos Join (LINUX.FAU.DE) / Download der Keytab
Wird benötigt, wenn NFSv4-Freigaben eingebunden oder Kerberos-authentifizierte Dienste auf dem Host betrieben werden sollen.
Der Kerberos Join ermöglicht eine Anbindung des Clients an die LDAP Infrastruktur des RRZE, sowie den Bezug einer Keytab mit ServicePrincipals, um eigene Dienste mit Kerberos-Authentifizierung anzubieten. Klassischerweise ist das unter Linux z.B. der Host-Principal für per Kerberos authentifizierte SSH Logins auf dem Client.
Der Join (genauer: eine Keytab mit NFS-Principal) wird ebenfalls benötigt, um NFSv4-Freigaben einbinden zu können.
Die entsprechende Anleitung zur Aktivierung von Kerberos für Ihr System finden Sie auf der Seite des rrzelinux Kommandozeilenwerkzeugs unter „Kerberos Join durchführen„.
Konfiguration
Einrichtung der verschiedenen Dienste.
Kerberos
Die Grundkonfiguration für Kerberos an der FAU ist können Sie nach folgendem Beispiel übernehmen.
Bitte beachten Sie die Kommentare und führen Sie ggf. notwendige Anpassungen durch.
Für Ubuntu 16.04 und älter müssen die entsprechend kommentierten Einstellungen deaktiviert werden.
bash$ for i in $(grep -l minimum_uid=1000 /etc/pam.d/* | grep -v -e bak -e old); do echo $i; sudo sed -i -e 's/minimum_uid=1000/minimum_uid=2000/' $i; done
bash$ sudo cp /etc/krb5.conf /etc/krb5.conf_old
bash$ sudo vi /etc/krb5.conf
[libdefaults]default_realm= LINUX.FAU.DE
# START: disable for Ubuntu 16.04 and older
default_ccache_name = FILE:/tmp/krb5cc_%{euid}
# END: disable for Ubuntu 16.04 and older
kdc_timesync= 1
ccache_type= 4
forwardable=trueproxiable=true
# maximum is 24h - but client defaults to 10h
ticket_lifetime = 10h
# START: disable for Ubuntu 16.04 and older
[appdefaults]
forwardable = true
pam = {
ccache = FILE:/tmp/krb5cc_%u
ccache_dir = /tmp
external = sshd
}
# END: disable for Ubuntu 16.04 and older
[realms]
FAUAD.FAU.DE ={kdc= fauad.fau.de:88
auth_to_local= RULE:[1:$1]auth_to_local= DEFAULT
}
LINUX.FAU.DE ={kdc= linuxkdc.rrze.uni-erlangen.de:88
auth_to_local= RULE:[1:$1]auth_to_local= DEFAULT
}
EXCH.FAU.DE ={kdc= exch.fau.de:88
auth_to_local= RULE:[1:$1]auth_to_local= DEFAULT
}
UBAD.FAU.DE ={kdc= ubad.fau.de:88
auth_to_local= RULE:[1:$1]auth_to_local= DEFAULT
}[domain_realm]# Add domain-realm mappings here# Additional mapping are necessary to map hostnames to a kerberos realm other than # the default realm set below# Examples:# some-windows-host.xyz.uni-erlangen.de = FAUAD.FAU.DE# some-linux-host.xyz.uni-erlangen.de = LINUX.FAU.DE# ...
# some usual windows hosts
mordor.rrze.uni-erlangen.de = FAUAD.FAU.DE
moloch.rrze.uni-erlangen.de = FAUAD.FAU.DE
home.rrze.uni-erlangen.de = FAUAD.FAU.DE
projekte.rrze.uni-erlangen.de = FAUAD.FAU.DE
fauprint.rrze.uni-erlangen.de = FAUAD.FAU.DE
fauprint2.rrze.uni-erlangen.de = FAUAD.FAU.DE
wisoprint.wiso.uni-erlangen.de = FAUAD.FAU.DE
wisoprint2.wiso.uni-erlangen.de = FAUAD.FAU.DE
rocky.rrze.uni-erlangen.de = FAUAD.FAU.DE
newton.wiso.uni-erlangen.de = FAUAD.FAU.DE
fausmb.rrze.uni-erlangen.de = FAUAD.FAU.DE
mecke12.rrze.uni-erlangen.de = FAUAD.FAU.DE
godzilla.rrze.uni-erlangen.de = FAUAD.FAU.DE
.exch.fau.de = EXCH.FAU.DE
.ubad.fau.de = UBAD.FAU.DE
# choose what should be the default below# if not specified otherwise - all hosts will be seen as members of the FAUAD.FAU.DE realm by default#.fau.de = FAUAD.FAU.DE#.uni-erlangen.de = FAUAD.FAU.DE# if not specified otherwise - all hosts will be seen as members of the LINUX.FAU.DE realm by default
.fau.de = LINUX.FAU.DE
.uni-erlangen.de = LINUX.FAU.DE
[login]#krb4_convert = true#krb4_get_tickets = false[logging]kdc= SYSLOG:INFO:DAEMON
admin_server= SYSLOG:INFO:DAEMON
default= SYSLOG:INFO:DAEMON
SSH Client
Folgende Einstellungen ermöglichen das kerberos-authentifizierte Einloggen auf anderen Systemen via SSH.
Folgende Einstellungen konfigurieren das Name-Id-Mapping für NFSv4 Netzlaufwerke.
bash$ sudo cp /etc/idmapd.conf /etc/idmapd.conf_old
bash$ sudo vi /etc/idmapd.conf
[General]Verbosity= 0
Pipefs-Directory = /run/rpc_pipefs
# have no fear - we only need fauad.fau.de as single unified namespace!Domain= fauad.fau.de
Local-Realms = LINUX.FAU.DE,FAUAD.FAU.DE
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup
CIFS Client
Folgende Einstellungen ermöglichen das kerberos-authentifizierte Einbinden von CIFS Netzlaufwerken.
Nach der Umstellung auf Kerberos – insbesondere bei Verwendung der NFS/CIFS Funktionalität – ist ein Reboot dringend empfohlen.
Generell können Tests mit falschen oder unvollständigen Konfigurationen dazu führen, dass der Kernel ungültige Informationen cached und dadurch darauffolgende Versuche – sogar mit korrekter Konfiguration – fehlschlagen.
Leider scheint der einzig effektive Weg ein Reboot zu sein, um sicher zu gehen, dass jegliche Caches geleert sind (Stichwort: Kernel keyring).
Test
Um die korrekte Einrichtung zu verifizieren können die hier beschriebenen Tests durchgeführt werden.
bash$ sudo mkdir /mnt/rzlin
bash$ sudo mount -t nfs4 -o minorversion=1,sec=krb5p rrzenfs4.rrze.uni-erlangen.de:/export/linuxhome /mnt/rzlin
bash$ sudo su $USER
bash$ cd /mnt/rrzelinuxhome/$USER
bash$ ls -al
insgesamt 1116
drwx------ 52 [Kennung] fau_user 12288 Nov 17 17:16 .
drwx-----x 6254 root root 483328 Nov 17 15:05 ..
...
bash$ exit
bash$ sudo umount /mnt/rzlin
bash$ sudo rmdir /mnt/rzlin
CIFS
bash$ id
uid=[UID]([KENNUNG])gid=100000(fau_user)Gruppen=100000(fau_user),...
# root werden
bash$ sudo su
bash$ mkdir -p /mnt/rzwin/[KENNUNG]
# WICHTIG: Der Mount-Befehl benötigt root-Rechte aber die Felder [KENNUNG]/[UID] (siehe Ausgabe des "id" Befehls) müssen auf einen unprivilegierten Zugang verweisen, für den ein Home-Verzeichnis tatsächlich existiert.
bash$ mount -t cifs -o user=[KENNUNG],domain=FAUAD,sec=krb5,cruid=[UID],multiuser,noserverino,nodfs,vers=2.1 //home.rrze.uni-erlangen.de/[KENNUNG] /mnt/rzwin/[KENNUNG]
# Anmerkung für Ubuntu 17.10:
# Scheinbar ist hier außerdem die Angabe der SMB Version erforderlich
# Beispiel: -o vers=2.1
bash$ su [KENNUNG]
bash$ cd /mnt/rzwin/[KENNUNG]
bash$ ls -al
...
bash$ exit
bash$ umount /mnt/rzwin/[KENNUNG]
bash$ rmdir /mnt/rzwin/[KENNUNG]
bash$ rmdir /mnt/rzwin
AutoFS
Autofs – oft auch automounter genannt – ermöglicht es nach entsprechender Konfiguration, Einhängevorgänge allein durch den Zugriff auf den entsprechenden Zielpfad im Dateisystem automatisch durchführen zu lassen.
Der Einhängevorgang erfordert keine root-Rechte mehr, da er vom autofs Prozess durchgeführt wird.
Pakete für Ubuntu 14.04/16.04/18.04
bash$ sudo apt-get install autofs
Aufbau
Die folgenden Beispiele setzen voraus, dass die Strukturierung der Home-Laufwerke nach folgendem Aufbau erfolgt.
/home.local/*
Anlage lokaler Homes, manuelle Verwaltung
Hier können je nach Bedarf Home-Verzeichnisse auf dem Server selbst z.B. für lokale Kennungen angelegt werden.
/home/*
Verwaltung durch AutoFS zum Mount von externen Homes
Hier können verschiedene Mount-Points für Nutzer-Homes zur Verfügung gestellt werden, um es beispielsweise den Nutzern zu ermöglichen auf verschiedene Home-Filer (z.B. RRZE-Home und Lehrstuhl-Home) zuzugreifen.
Konfiguration
Im Folgenden wird eine Beispielkonfiguration vorgestellt, die in ähnlicher Form auch auf den Servern des RRZE im Einsatz ist.
Enthalten sind diverse Dateien zur Konfiguration von Einhängepunkten und einige Beispiele für Fileserver, die evtl. nützlich sein könnten.
Bitte beachten Sie, dass nicht alle Einhängepunkte exakt zu übernehmen sind!
Sehr wahrscheinlich werden Sie Anpassungen an Ihre Gegebenheiten vornehmen müssen. Die Dateistruktur sollte nach Möglichkeit jedoch beibehalten werden, um den Support im Fehlerfall zu vereinfachen.
Die Beispielkonfiguration umfasst die folgenden Dateien mit jeweiligem Inhalt.
/etc/auto.master
erster Einsprungpunkt in die Konfiguration der Einhängepunkte
lokale Konfiguration von Einhängepunkten
hier ist der Platz, um weitere Einhängepunkte zu konfigurieren oder Dateien zu referenzieren
# Home mounts
/home /etc/auto.home --ghost
# Wildcard mounts for RRZE windows homes
/home/rzwin /etc/auto.rzwin
# Project mounts
# (optional for respective projects)
#/proj /etc/auto.proj --ghost
# Generic network mounts
# (optional)
#/net /etc/auto.net --ghost
/etc/auto.home
Für das Linux Home unter rrzenfs4.rrze.uni-erlangen.de:/export/linuxhome werden zukünftig nur noch krb5p Verbindungen unterstützt! Bitte passen Sie Ihre Konfiguration ggf. entsprechend an.
Einhängepunkte für diverse Home-Filer unter /home/$prefix
generell nützlich, vor allem wenn Personen Homes an verschiedenen Einrichtungen besitzen
hier können Sie auch Ihren eigenen Home-Filer unter Ihrem Präfix einfügen
kann auf das nötige Minimum reduziert werden
Das Namensschema sieht vor Ihre Homes unter Ihrem offiziellen Präfix – auch Mail/AD-Präfix genannt – zur Verfügung zu stellen, um Namenskollisionen zu vermeiden
# Wildcard mounts for windows homes
# CIFS Windows home filer (rrzefiler.rrze.uni-erlangen.de)
* -fstype=cifs,user=$USER,domain=FAUAD,sec=krb5,cruid=$UID,multiuser,noserverino,vers=2.1 ://home.rrze.uni-erlangen.de/&
/etc/auto.proj
optional (bei Verwendung auch in auto.master aktivieren)
Einhängepunkte für Projekt-Filer
momentan keine öffentlichen Beispiele für Projekt-Filer vorhanden, Sie können hier jedoch eigene Einträge ergänzen
/etc/auto.net
optional (bei Verwendung auch in auto.master aktivieren)
Einhängepunkte für sonstige Netzlaufwerke
momentan keine öffentlichen Beispiele für sonstige Filer vorhanden, Sie können hier jedoch eigene Einträge ergänzen
Dienst neu starten
Nach erfolgter Konfiguration ist der autofs Dienst neu zu starten
Ubuntu 14.04 / Upstart
bash$ sudo service autofs restart
Ubuntu 16.04/18.04 / Systemd
bash$ sudo systemctl restart autofs
Fehlersuche
Bei Problemen können einige Ansätze zur Fehlersuche/-behebung abgearbeitet werden.
Logs
Ein guter Anhaltspunkt bei Problemen mit Einhängepunkten ist immer das syslog.
bash$ less /var/log/syslog
Konfiguration
Mit folgendem Befehl lässt sich die Konfiguration anhand des Inhaltes der obigen Dateien anzeigen.
Es wird nicht die aktive Konfiguration angezeigt, sondern zum Zeitpunkt des Aufrufes aus den Konfigurationsdateien direkt erzeugt
Darüber hinaus sind Anpassungen an den folgenden beiden Dateien nötig.
bash$ sudo vi /etc/default/nfs-common
...
NEED_GSSD=yes
...
bash$ sudo vi /etc/default/nfs-kernel-server
...
NEED_SVCGSSD="yes"
...
Damit ist die Konfiguration von Kerberos bezüglich des NFSv4 Servers abgeschlossen.
Vorbereiten des pseudo-root Verzeichnisses für Exports
Durch Konfiguration eines pseudo-root Verzeichnisses für NFS Exports wird der exportierte Pfad unabhängig vom echten Pfad auf dem Server.
Das erleichtert ggf. einen später notwendigen Umzug der Daten.
Im Gegensatz zu NFSv3 verwendet NFSv4 immer ein pseudo-root! Verwendet man die falschen Pfade auf den Clients kann unter Umständen ein automatisches Fallback auf NFSv3 passieren.
Zur Vorbereitung erstellt man ein Verzeichnis, das alle späteren Exports enthalten soll und fasst dort alle Daten mittels Bind-Mounts zusammen.
bash$ mkdir /export
bash$ mount --bind /some/nested/data/dir /export/sys
...
Die Bind-Mounts müssen in der /etc/fstab eingetragen werden, damit die Exports nach dem nächsten Reboot wieder genauso zur Verfügung gestellt werden können.
Das RRZE empfiehlt nur mittels krb5p verschlüsselte Verbindungen zu verwenden.
Die freizugebenden Verzeichnisse werden wie folgt konfiguriert.
Der erste Eintrag markiert dabei das Basisverzeichnis des pseudo-root Dateisystems durch die Option fsid=0.
bash$ sudo vi /etc/exports
# Pseudo-root für NFSv4
/export 169.254.0.0/255.255.255.128(rw,no_subtree_check,fsid=0,crossmnt)
# Beispiel für Export mit Kerberos-Authentifizierung und Verschlüsselung
/export/krb5_enc 169.254.0.0/255.255.255.128(rw,async,sec=krb5p,no_subtree_check)
# Beispiel für Export mit Kerberos-Authentifizierung und nur Integritätscheck
/export/krb5_int 169.254.0.0/255.255.255.128(rw,async,sec=krb5i,no_subtree_check)
# Beispiel für Export mit Kerberos-Authentifizierung und Verschlüsselung (präferiert) und nur Integritätscheck als Fallback
/export/krb5_enc_or_int 169.254.0.0/255.255.255.128(rw,async,sec=krb5p:krb5i,no_subtree_check)
# Beispiel für Export mit nur Kerberos-Authentifizierung
/export/krb5 169.254.0.0/255.255.255.128(rw,async,sec=krb5,no_subtree_check)
# Beispiel für Export ohne Kerberos-Authentifizierung
/export/sys 169.254.0.0/255.255.255.128(rw,async,sec=sys,no_subtree_check)
...
Mit folgendem Befehl können Sie die exportierten Verzeichnisse anhand der oben vorgenommenen Konfiguration aktualisieren (Re-export).
Der mount Befehl liefert leider oft nicht die besten Fehlermeldungen, was die Diagnose im Fehlerfall erschwert.
Generell wird empfohlen zum Testen immer die -v Option zu setzen, um mehr Informationen über die ausgeführten Aktionen zu bekommen.
Außerdem ist ein explizites Anfordern der NFS Version zB mit -t nfs4 oder -o vers=4 statt dem generischen -t nfs ratsam.
Einbinden von Exports auf dem Client
Beachten Sie die Referenzierung des Mountpunkts relativ zum Pseudo-root des Servers ohne vorangestelltes „/export“!
Beispielaufruf:
bash$ mount -v -t nfs4 server:/sys /mnt/sys
Ein erfolgreicher Mount mit NFSv4.2 sollte in etwa folgende Ausgabe liefern.
Man beachte die Angabe des Exports auf dem Server relativ zum pseudo-root.
bash$ mount -v -t nfs server:/sys /mnt/sys
mount.nfs: timeout set for Tue Nov 6 12:29:36 2018
mount.nfs: trying text-based options 'vers=4.2,addr=131.188.xxx.xxx,clientaddr=10.188.xxx.xxx'
Ein fehlerhafter Mount mit Fallback auf NFSv3 sieht in etwa so aus.
Man beachte die Angabe des Exports auf dem Server als absoluten Pfad, was durch NFSv4 nicht mehr unterstützt wird und nach einem entsprechenden Fehler den Fallback zu NFSv3 auslöst.
bash$ mount -v -t nfs server:/export/sys /mnt/sys
mount.nfs: timeout set for Tue Nov 6 12:29:20 2018
mount.nfs: trying text-based options 'vers=4.2,addr=131.188.xxx.xxx,clientaddr=10.188.xxx.xxx'
mount.nfs: mount(2): No such file or directory
mount.nfs: trying text-based options 'addr=131.188.xxx.xxx'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 131.188.xxx.xxx prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 131.188.xxx.xxx prog 100005 vers 3 prot UDP port 45103
Docker
Der Einsatz von Docker erfreut sich steigender Beliebtheit.
Diese Seite gibt Hilfestellungen und Hinweise zum Betrieb von Docker-Containern an der FAU.
Bitte den verwendeten Adressbereich unbedingt wie unten beschrieben konfigurieren.
Es gibt Netze an der FAU, die mit dem Default-Adressbereich kollidieren!
Docker Bridge
Docker verwendet ein eigenes Subnetz das über die Docker-Bridge docker0 mit dem restlichen Netzwerk kommuniziert.
Standardmäßig verwendet dieses Subnetz den Adressbereich 172.17.0.0/16
Um Kollisionen mit bereits verwendeten Adressbereichen auszuschließen wird empfohlen einen Bereich aus nicht-routbaren LinkLocal Adressen für Docker zu verwenden.
Um den Netzbereich anzupassen sind die folgenden Schritte notwendig.
Ubuntu ab 18.04 (Systemd)
1. Docker-Daemon Konfiguration anpassen
bash$ sudo systemctl edit docker
2. Folgenden Inhalt einfügen
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H unix:// --bip=169.254.254.1/24
# Ende
4. Neustart des Docker-Daemons (ACHTUNG: Startet auch alle Container neu!)
bash$ sudo systemctl restart docker
5. Überprüfen der docker0 IP
bash$ ip address show docker0
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:06:dd:bb:5c brd ff:ff:ff:ff:ff:ff
inet 169.254.254.1/24 scope global docker0
valid_lft forever preferred_lft forever
inet6 fe80::42:6ff:fedd:bb5c/64 scope link
valid_lft forever preferred_lft forever
Das wars 🙂
Startskripte
Docker-Container mit dem Linux Initsystem starten
Ubuntu ab 18.04 (Systemd)
Als Basis für eigene Anpassungen empfehlen wir zum Beispiel folgendes Init-Skript zum automatischen Anlegen und starten eines neuen Containers basierend auf einem existierenden Docker-Image.
Alle Informationen zum Erstellen des Containers sind im Skript bereits enthalten.
So benötigt man für einfache Setups kein zusätzliches Tool, wie docker-compose, um die Konfiguration der Container zu verwalten.
Um auch normalen Benutzern – außer root – den Zugriff auf den Docker-Daemon zu gewähren, kann man diese in die Gruppe docker aufnehmen.
Die folgende Methode fügt eine Benutzerkennung bei der Anmeldung dynamisch zur benötigten lokalen docker Gruppe hinzu und funktioniert deshalb auch mit LDAP-basierten Kennungen und der lokalen docker Gruppe (siehe auch https://help.ubuntu.com/community/LDAPClientAuthentication#Assign_local_groups_to_users).
Sollten Sie einer lokale Kennung verwenden, kann diese natürlich auch direkt der lokalen docker Gruppe hinzugefügt werden.
Sie müssen sich Abmelden und neu Anmelden, damit diese Änderung aktiv wird!
Diese Anleitung beschreibt die Installation des rrzelinux Kommandozeileninterfaces (CLI) für Administratoren nicht vom RRZE verwalteter Rechner.
Das rrzelinux CLI Tool ermöglicht Ihnen beliebige Rechner unterhalb Ihrer DNS Domain in Eigenverantwortung an die RRZE-Infrastruktur (z.B. LDAP/Kerberos) anzubinden. Diese Option ist besonders interessant, falls Sie keine Fremdadministration durch das RRZE wünschen, oder ein nicht vom RRZE unterstütztes System betreiben, das dennoch die Infrastruktur des RRZE nutzen soll.
Vorbereitung
Bitte prüfen Sie die vorbereitenden Schritte bevor Sie versuchen einzelne Teile der Anleitung durchzuführen.
In der Regel müssen diese Voraussetzungen für ein sinnvolles Umsetzen Anleitung erfüllt sein.
Um das rrzelinux CLI Tool zur Verwaltung von Rechnern nutzen zu können, benötigen Sie eine entsprechende Berechtigung als IT-Betreuer für Ihre Einrichtung.
Die Vergabe der Berechtigung muss vom Leiter der entsprechenden Einrichtung im Einrichtungsleitercockpit des IdM unter https://www.idm.fau.de/gadmin/cockpit erfolgen.
Für den Login verwenden Sie – nach entsprechender Freischaltung durch den Einsrichtungsleiter – bitte Ihre IdM-Hauptkennung und Passwort.
Sollten Sie Beratung zum Linux Adminzugang oder dem rrzelinux Tool benötigen, wenden Sie sich gerne an rrze-linux@fau.de, um einen Termin zu vereinbaren.
Präfixe
Die verwendete Rechtestruktur ordnet jedem Rechner ein Präfix zu, dass bei allen Aktionen mit angegeben werden muss.
Ein oder mehrere Präfixe werden wiederum einer Organisationseinheit der FAU zugeordnet.
Sollten Sie noch kein Präfix besitzen, dass zur Verwaltung Ihrer Rechner verwendet werden kann, so müssen Sie dieses ggf. noch beantragen.
Idealerweise beginnt auch der Rechnername mit dem ihm zugeordneten Präfix, gefolgt von einem „-“ als Trenner.
Das ist aber (noch) keine harte Anforderung.
Domains
Die Verwendung einer Domain für Ihre Rechner ist an die Freischaltung dieser Domain für das verwendete Präfix gebunden. Das bedeutet Sie können für ein bestimmtes Präfix nur Domains verwenden, die für dieses explizit freigeschaltet wurden.
Welche Domains für ein Präfix verfügbar sind können Sie zB in der Präfixübersicht des IT-Serviceportals einsehen.
Um eine Domain für ein bestimmtes Präfix freischalten zu lassen, wenden Sie sich bitte an unsere DNS-Admins unter dns@fau.de.
IT-Betreuer
Als IT-Betreuer (siehe https://www.rrze.fau.de/infocenter/rahmenbedingungen/it-beauftragte/) haben Sie Zugriff auf alle Rechner, die einem Präfix zugeordnet sind, das in Ihrem Betreuungsbereich liegt. Der Betreuungsbereich wird aus dem FAU.org Baum ermittelt und erstreckt sich von der betreuten Einrichtung aus hierarchisch nach unten.
rrzelinux
Wichtig
Bitte stellen Sie vor der Benutzung des rrzelinux Tools sicher, dass für Ihren Rechner der vollständige FQDN konfiguriert ist.
RRZE Linux management command line tool (1.0.4)
usage: rrzelinux prefix command fqdn|%.[%|domain] [options]
update: sudo rrzelinux update
description: command line utility to manage RRZE Linux host entries
parameters:
prefix the prefix to use
command see section 'commands' below
fqdn defaults to 'hostname -f' if none specified
%.[%|domain] select/filter for all hosts / all hosts in a specific domain
options see section 'options' below
commands:
create create host entry for LDAP access from a self-administered machine
kerberize create kerberos principals and download keytab for dns name
(use -k to specify principals, default: host,nfs)
join join host (create + kerberize)
leave|remove remove host (and kerberos principals)
info show host information
list list all hosts for the current/specified/all domain(s)
keytab download keytab only
update update this tool to the latest version (needs root)
options:
-h print this help
-v print version info
-u username username with administrative rights for RRZE linux
-p password password
-k specify service principals to generate (default: host,nfs)
-n do not download anything, just make the changes
-c no colors
-d be verbose/debugging
-q be quiet
Update
bash$ sudo rrzelinux update
Update verfügbar:
rrzelinux: New version available: rrzelinux 1.0.4 6713327ed9063f9fa6f38d6f90375ece
Update to latest version now? (y/n) y
rrzelinux: Performing self-update...
Done.
Kein Update verfügbar:
rrzelinux: Already at the latest version (1.0.4).
Kurzanleitungen
Hier finden Sie Hilfestellungen für häufig benötigte Funktionen des rrzelinux Kommandozeilenwerkzeugs.
Hostinformationen abrufen
Sollten Sie das LDAP-Passwort Ihres Hosts vergessen haben, so können Sie wie folgt die Informationen erneut erhalten:
bash$ rrzelinux [PRÄFIX] info
Username: [Benutzer mit Rechten für das gewählte Präfix]
Password: *****
Mit Ausnahme des Hostnamens sollte die Ausgabe in etwa so aussehen:
rrzelinux: Host infos for test.rrze.uni-erlangen.de were gathered successfully (id=906)
key value
================= ====================================================================
hostname test
domain rrze.uni-erlangen.de
owner rrze
description Remotely created host entry (by rrze)
group ZS-Server
config UNMANAGED
ldap LDAP
binddn cn=test.rrze.uni-erlangen.de,ou=host,ou=profile,ou=linux,dc=rrze,dc=uni-erlangen,dc=de
password [Passwort]
krb realm -
krb services -
updated 2016-11-25 15:51:39.346
created 2016-11-25 15:51:39.14
Kerberos Join durchführen
Um per Kerberos authentifizierte Dienste Anbieten zu können muss Ihr System entsprechende Service-Principals vom LINUXKDC abrufen.
Hierfür müssen Sie Ihr System in der Rechnerverwaltung des Linux-Teams anlegen (create) und die Kerberos Funktionalität aktivieren (kerberize). Beides in einem Schritt erledigt der der join-Befehl.
bash$ rrzelinux [PRÄFIX] join
Username: [Benutzer mit Rechten für das gewählte Präfix]
Password: *****
rrzelinux: Host test.rrze.uni-erlangen.de was joined successfully (id=905)
rrzelinux: Saved keytab to: /tmp/krb5.keytab
rrzelinux: LDAP password is: [Passwort]
Die erzeugte Keytab muss abschließend noch an den richtigen Platz verschoben werden.
Das LDAP Passwort kann für eine Anbindung an den zentralen LDAP Server des RRZE verwendet werden, wird aber für Kerberos zunächst nicht benötigt.
Mehr Informationen zur LDAP Anbindung erhalten Sie auf der Seite zur SSSD Konfiguration.
Kerberos Konfiguration nachträglich hinzufügen
Existiert der entsprechende Host bereits (angelegt z. B. durch create) und soll jetzt für Kerberos konfiguriert werden kann dies wie folgt auch nachträglich geschehen.
bash$ rrzelinux [PRÄFIX] kerberize
Username: [Benutzer mit Rechten für das gewählte Präfix]Password: *****
Kerberos Keytab erneut abrufen
Sollten Sie Ihre Keytab gelöscht haben, so können Sie diese wie folgt erneut erhalten.
Bitte beachten Sie, das der Host zum erneuten abrufen der Keytab bereits durch ein erfolgreiches join oder create/kerberize Kommando entsprechend für Kerberos konfiguriert sein muss.
bash$ rrzelinux [PRÄFIX] keytab
Username: [Benutzer mit Rechten für das gewählte Präfix]Password: *****
rrzelinux: Got keytab(s) of 1 entries for test.rrze.uni-erlangen.de
rrzelinux:
rrzelinux: Kerberos keytab information
rrzelinux: ---------------------------
rrzelinux: Saved keytab to temporary location: /tmp/rrzelinux_krb5_keytab.AlD2sns1b
rrzelinux: Install in system with:
rrzelinux: sudo mv -bv /tmp/rrzelinux_krb5_keytab.AlD2sns1b /etc/krb5.keytab && sudo chown root:root /etc/krb5.keytab
Diese Anleitung beschreibt das Anlegen des Hosteintrags zum Zugriff auf die RRZE LDAP-Server für einen selbstverwalteten Rechner und die Installation und Konfiguration des SSSD zur Benutzerauthentifizierung unter Ubuntu.
Sicherheit
Bitte beachten Sie, dass nach erfolgreicher Durchführung der unten beschriebenen Schritte ersteinmal alle Benutzer der FAU Zugriff auf den entsprechenden Host haben.
Es ist deshalb dringend empfohlen den Benutzerkreis durch geeignete Maßnahmen weiter einzuschränken, zB durch die Verwendung von sssd-simple oder pam_access.
Vorbereitung
Bitte prüfen Sie die vorbereitenden Schritte bevor Sie versuchen einzelne Teile der Anleitung durchzuführen.
In der Regel müssen diese Voraussetzungen für ein sinnvolles Umsetzen Anleitung der erfüllt sein.
FAU-CA Zertifikat einbinden
Die LDAP-Server des RRZE erlauben nur SSL verschlüsselten Zugriff via LDAPS (636) oder STARTTLS (389). Damit der Zugriff funktioniert müssen Sie das Zertifikat der Zertifizierungsstelle der FAU (FAU-CA) einbinden.
Folgen Sie dafür den unter FAU-CA Zertifikat einbinden beschriebenen Schritte bevor Sie diese Anleitung fortsetzen.
rrzelinux CLI Tool
Falls Sie kein Betreuungsangebot des RRZE gebucht haben (Serverhousing oder -hosting) wird im Verlauf der Installation wird das rrzelinux CLI Tool benötigt, um den Host-Eintrag Ihres Systems zu erzeugen.
Bitte führen Sie in diesem Fall im Vorfeld die Installation wie unter Installation des rrzelinux CLI Tools beschrieben durch.
Pakete
Folgender Pakete für Ubuntu 14.04/16.04/18.04/20.04 müssen installiert werden:
Linux Hosteintrag erzeugen (entfällt für Housing/Hosting-Kunden)
Für den Zugriff auf die zentralen LDAP Server des RRZE muss ein rechnerspezifischer Host-Eintrag mit Passwort erzeugt werden.
Die Zugangsdaten dürfen nur auf dem damit verbundenen Rechner und nur zur Durchführung der Nutzerauthentifizierung verwendet werden!
Housing oder Hosting Kunden können diesen Schritt überspringen. Der Hosteintrag wird durch unsere Mitarbeiter angelegt und die Zugangsdaten an Sie übermittelt.
Benötigen Sie Zugriff auf unseren LDAP Server zu anderen Zwecken, kontaktieren Sie uns bitte per Mail an rrze-linux@fau.de.
Wir werden Ihr Anliegen prüfen und ggf. für Ihren Einsatzzweck einen separaten Zugang einrichten.
Bei Missbrauch des Zugangs behalten wir uns vor diesen ohne Vorwarnung zu sperren.
Initiale Einrichtung
bash$ rrzelinux [PRÄFIX] create
Username: [Benutzer mit "create"-Rechten]
Password: *****
Mit Ausnahme des Hostnamens sollte die Ausgabe in etwa so aussehen:
rrzelinux: Host test.rrze.uni-erlangen.de was created successfully (id=906)
rrzelinux: LDAP bind DN is: cn=test.rrze.uni-erlangen.de,ou=host,ou=profile,ou=linux,dc=rrze,dc=uni-erlangen,dc=de
rrzelinux: LDAP password is: [systemgeneriertes Passwort]
Der LDAP Bind-DN und Passwort kann für eine Anbindung an den zentralen LDAP Server des RRZE verwendet werden.
LDAP Passwort vergessen
Sollten Sie das LDAP-Passwort Ihres Hosts vergessen haben, so können Sie wie folgt die Informationen erneut erhalten:
bash$ rrzelinux [PRÄFIX] info
Username: [Benutzer mit "info"-Rechten]
Password: *****
Mit Ausnahme des Hostnamens sollte die Ausgabe in etwa so aussehen:
rrzelinux: Host infos for test.rrze.uni-erlangen.de were gathered successfully (id=906)
key value
================= ====================================================================
hostname test
domain rrze.uni-erlangen.de
owner rrze
description Remotely created host entry (by rrze)
group ZS-Server
config UNMANAGED
ldap LDAP
binddn cn=test.rrze.uni-erlangen.de,ou=host,ou=profile,ou=linux,dc=rrze,dc=uni-erlangen,dc=de
password [systemgeneriertes Passwort]
krb realm -
krb services -
updated 2016-11-25 15:51:39.346
created 2016-11-25 15:51:39.14
SSSD Konfiguration
Zur Konfiguration des SSSD gehen Sie wie folgt vor:
bash$ cd /etc/sssd
bash$ sudo cp sssd.conf sssd.conf_old
bash$ sudo vi sssd.conf
Der Inhalt der Datei /etc/sssd/sssd.conf könnte in etwa so aussehen (RRZE-Standard Konfiguration):
[sssd]
debug_level = 3
config_file_version = 2
services = nss,pam
domains = LINUXLDAP
[nss]
debug_level = 3
filter_users = root
filter_groups = root
[pam]
debug_level = 3
filter_users = root
filter_groups = root
[domain/LINUXLDAP]
debug_level = 3
# optional: use this to override the configured per-user home from the ldap
#override_homedir = /home.local/%u
# With this as false, a simple "getent passwd" for testing won't work. You must do getent passwd user@domain.com
enumerate = false
cache_credentials = true
# cache cleanup operation removes cached entries that were not used for a while - unneccessary
ldap_purge_cache_timeout = 0
# makes all groups appear as empty (getent group), thus downloading only information about the group objects themselves and not their members
# this drastically improves performance with large ldap groups!
ignore_group_members = True
id_provider = ldap
auth_provider = ldap
ldap_uri = ldap://linuxldap.rrze.uni-erlangen.de
ldap_search_base = ou=linux,dc=rrze,dc=uni-erlangen,dc=de
ldap_id_use_start_tls = true
ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt
# This parameter requires that the ldap server presents a completely validated certificate chain. If you're testing or don't care, use 'allow' or 'never'.
# you need to install and trust the FAU-CA certificate for this to work!
ldap_tls_reqcert = demand
#ldap_tls_reqcert = never
# Bind credentials
ldap_default_bind_dn = [siehe Ausgabe des rrzelinux CLI Tool]
ldap_default_authtok = [siehe Ausgabe des rrzelinux CLI Tool]
ldap_user_search_base = ou=people,ou=linux,dc=rrze,dc=uni-erlangen,dc=de
ldap_group_search_base = ou=group,ou=linux,dc=rrze,dc=uni-erlangen,dc=de
bash$ sudo chmod 700 sssd.conf
Die gegebenen Konfiguration stellt die Empfehlung des RRZE dar.
Sie können die Konfiguration jedoch – falls nötig – an Ihren Anwendungsfall anpassen.
Weiteren Informationen zu den verschiedenen Optionen erhalten Sie auf der sssd.conf Manpage.
Achten Sie darauf die mit „[ ]“ gekennzeichneten Passagen durch die entsprechenden Daten aus dem rrzelinux Tool zu ersetzen.
Restart der Dienste
Damit die vorgenommene Konfiguration aktiv wird müssen die betroffenen Dienste neu gestartet werden.
Ubuntu 14.04
bash$ sudo service sssd restart
Ubuntu 16.04/18.04/20.04
bash$ sudo systemctl restart sssd.service
NSSWITCH Anpassen
Die Name Service Switch (NSS) Konfiguration bestimmt verschiedene Quellen zur Namensauflösung.
Um den SSSD zur Namensauflösung für die zur Authentifizierung benötigten Daten zu konfigurieren müssen einige Anpassungen vorgenommen werden:
bash$ cd /etc
bash$ sudo cp nsswitch.conf nsswitch.conf_old
bash$ sudo vi nsswitch.conf
Der Inhalt der /etc/nsswitch.conf sollte dann für die betreffenden Datenbanken so aussehen:
Nachdem alle Schritte durchgeführt wurden kann die Konfiguration noch auf korrekte Funktion überprüft werden.
Benutzer- und Gruppenauflösung
Dieser Test stellt sicher, dass die LDAP-Anbindung funktioniert und Benutzer- und Gruppeninformationen abgerufen werden können.
Statt der beispielhaft verwendeten Kennung „yc14omec“ können Sie auch Ihre eigene Kennung verwenden.
bash$ id yc14omec
uid=52014(yc14omec) gid=100000(fau_user) Gruppen=100000(fau_user)
Der Test ist erfolgreich, wenn die Ausgabe das Mapping auf die uidNumber und die Gruppenmitgliedschaften korrekt anzeigt.
Performante Gruppenauflösung
Dieser Test überprüft beziehungsweise demonstriert den Effekt der Konfigurationsoption ignore_group_members = true. Bei Abruf einer Gruppe werden aus Performanzgründen standardmäßig keine Mitglieder geliefert.
Dieses Verhalten ist erwünscht, da es sonst aufgrund der hohen Anzahl an Gruppenmitgliedern bei manchen Gruppen zu erheblichen Verzögerungen beim Einloggen kommen kann.
bash$ getent group rrze_linux
fau_user:*:100000:
Der Test ist erfolgreich, wenn keine Mitglieder der Gruppe angezeigt werden.
Fehlerbehebung
Bei Problemen mit der Gruppenauflösung oder generell „seltsamen“ Verhalten des SSSD kann zur Behebung versucht werden den Cache zu löschen.
Die sanfte Variante (funktioniert manchmal):
bash$ sudo sss_cache -E
Die harte Variante (funktioniert meistens):
# Ubuntu 14.04/16.04
bash$ sudo su
bash$ service sssd stop && rm /var/lib/sss/db/* && service sssd start
bash$ exit
# Ubuntu 18.04/20.04
bash$ sudo su
bash$ systemctl stop sssd && rm /var/lib/sss/db/* && systemctl start sssd
bash$ exit
FAU-CA Zertifikat einbinden
Diese Anleitung beschreibt die Installation der CA Zertifikatskette für die FAU in einem Ubuntu System, so dass das System in Zukunft allen Zertifikaten, die von der CA der FAU ausgestellt wurden vertraut.
Vorbereitung
Bitte prüfen Sie die vorbereitenden Schritte, bevor Sie versuchen einzelne Teile der Anleitung durchzuführen.
In der Regel müssen diese Voraussetzungen für ein sinnvolles Umsetzen der Anleitung erfüllt sein.
Pakete
Folgender Pakete für Ubuntu ab 14.04 müssen installiert werden:
Java verwendet eigenen eigenen Truststore in dem vertrauenswürdige Zertifikate abgelegt werden.
Um Java Anwendungen auch von der Validität der FAU Zertifikate zu überzeugen können diese wie folgt auch dort eingebunden werden.
Ubuntu ab 14.04
Die folgenden Befehle importieren exemplarisch das alte und das neue CA Zertifikat in den OpenJDK 8 Truststore.
Der Pfad zum Truststore kann ggf. je nach verwendeter Java Version und Implementierung abweichen und muss ggf. angepasst werden.
Das Standard-Passwort für diesen Truststore ist tatsächlich „changeit“ und muss genauso eingegeben werden.
Der Test prüft ob nach Aktualisierung der Liste der vertrauenswürdigen CA-Zertifikaten auch das CA Zertifikat der FAU enthalten ist.
System
bash$ grep "USERTrust RSA Certification Authority" /etc/ssl/certs/ca-certificates.crt
subject=C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
Der Test ist erfolgreich, wenn die jeweils angegebene Zeichenkette gefunden wird.
