Key Management Server (KMS)

Diese Anleitung ist für FAU Beschäftigte, die ein Dienstgerät mit

  1. Microsoft Windows 11 Enterprise und
  2. Office Pro Plus 2021 oder höher

nutzen oder administrieren.

Die Aktivierung von Windows Enterprise und Office Pro Plus 2021 (oder höher) läuft nach einem Zeitraum von 180 Tagen ab. Um dies zu verhindern, muss ein regelmäßiger Kontakt zum Key Management Server (KMS) des RRZE aufrechterhalten werden.

Eine erfolgreiche erneute Aktivierung über das FAU-LAN ist nicht immer gewährleistet. Auch wenn ein Dienstgerät hauptsächlich über WLAN verbunden ist, wird empfohlen, vor längeren Dienstreisen, anderen Abwesenheiten oder während des Home Offices eine manuelle Aktivierung durchzuführen. Eine detaillierte Anleitung hierzu steht auf dieser Seite zur Verfügung.

Für die manuelle Aktivierung sind keine Administratorrechte erforderlich. Die Aktivierung kann auch dann durchgeführt werden, wenn das Gerät das KMS Autodiscovery-Verfahren nutzt.

Schnellstart für Zielgruppen

Die Aktivierung von Windows Enterprise und Office Pro Plus 2021 (oder höher) läuft nach 180 Tagen ab. Vorher muss eine Verbindung zum Key Management Server (KMS) des RRZE hergestellt werden.

  1. Gerät mit dem FAU-Hochschulnetz verbinden (LAN oder VPN)
  2. Windows und Office sollten sich automatisch reaktiveren

 Wenn die automatische Aktivierung fehlschlägt

  • Gerät mit dem FAU-Hochschulnetz verbinden (LAN oder VPN)
  • Eingabeaufforderung (cmd) öffnen und folgende Befehle ausführen

slmgr -ato [Enter]

Windows(R), Enterprise edition … wird aktiviert … Das Produkt wurde erfolgreich aktiviert.

c: [Enter]

cd C:\Program Files\Microsoft Office\Office16\ [Enter]

cscript ospp.vbs /act [Enter]

Installed product key detected – attempting to activate the following product: … LICENSE NAME: Office … VOLUMECLIENT channel … <Product activation successful>


  • Windows und Office sind für weitere 180 Tage nutzbar.

Wichtige Informationen

Für den Betrieb von Windows ist eine direkte TCP/IP-Verbindung (Ethernet, kabelgebunden) zum KMS-Server im Hochschulnetz notwendig.
Der KMS-Server ist via WLAN nicht erreichbar. Für Geräte ohne Ethernet-Schnittstelle müssen Sie einen entsprechenden Ethernet-Adapter (mit)beschaffen.

Dieser Dienst läuft auf dem KMS-Server des RRZE
kms.rrze.uni-erlangen.de
über den TCP-Port 1688.

Zugeteilte IPv4-Netzbereiche, Änderungen und zusätzliche (private) (Sub)Netze müssen zur Freischaltung des KMS durch die RRZE-Kontaktpersonen unter Angabe der Kundennummer an software@fau.de mitgeteilt werden.

Windows Enterprise und Office Pro Plus aktivieren

Mitglieder der AD-Domäne FAUAD finden den KMS-Eintrag automatisch über die AD-integrierten DNS-Dienste. Dabei spielt die Konfiguration des primären DNS-Suffixes keine Rolle.

Auf diesem Bild ist das Fenster der Windows Systemsteuerung mit den jeweiligen Einstellungen geöffnet.
KMS Autodiscovery am Beispiel von Windows 10

Alternativ zur AD-Variante kann der DNS-Suffix des Computers explizit auf uni-erlangen.de eingestellt werden. Der KMS-Dienst wird automatisch gefunden und kontaktiert.

Auf FAU-Geräten kann folgende Batchdatei genutzt werden. Bei Verwendung des Standard-Installationsschemas von Microsoft werden alle Kombinationen von Microsoft Windows 7 / 8.1 / 10 Enterprise und Microsoft Office Pro Plus 2010 / 2013 / 2016 / 2019 aktiviert.

Die Datei muss initial mit Run As Administrator bzw. Ausführen als Administrator gestartet werden, wenn der KMS-Server fest eingetragen werden soll.

:: Speichern Sie diesen Text mit der Endung .bat ab:. Zum Beispiel
:: FAU-KMS-Win+MSO_v4.bat
:: Mit dieser Batchdatei können sie auf Ihrem FAU-Dienstrechner die an der FAU verwendeten
:: Volumenlizenzen von Microsoft Windows und Office aktivieren, wenn Sie sich im FAU-LAN befinden.
::
:: Regionales Rechenzentrum Erlangen (RRZE)
:: Autor: Thomas Reinfelder, rrze-software@fau.de
:: Version 4 vom 16.01.2025

@ECHO Off
Echo MICROSOFT KMS-AKTIVIERUNG von Echo WINDOWS ENTERRISE / EDUCATION und Echo OFFICE PRO PLUS zur Nutzung auf Dienstrechner der FAU
Echo =====================================
Echo Bitte die Meldungen beachten ob die Aktivierung erfolgreich war.
Echo =====================================
Echo Mögliche Fehlerquellen
Echo ===
Echo Die Aktivierung ist nur aus dem LAN = Ethernet = KABEL (!!!!) der FAU möglich.
Echo --
Echo Falls Sie ein neues / weiteres Lehrstuhl-Netz (insbesondere private Netze!) erhalten haben, muss die Kontaktperson dies unter Angabe der KP-Kennung an software@fau.de melden damit wir den KMS-Server entsprechend freischalten.
Echo --
Echo Im Fehlerfall bitte Datum / Uhrzeit / Zeitzone / Sommer-/Winterzeit überprüfen
Echo --
Echo Falls die Aktivierung fehlschlägt bitte die Batchdatei einmalig via rechte Maustaste "Ausführen als Admin" / "Run as admin" starten.
Echo ===
Echo Um fortzufahren
pause


:: Auf erhöhten Rechten prüfen. Falls nicht, wird  nicht versucht den
:: KMS-Server einzutragen, da dies nur einen Fehler produzieren würde.
whoami /groups | find "S-1-16-12288" > nul 
if not errorlevel 1 goto WindowsKMSeintragen
goto WindowsAktivieren

:WindowsKMSeintragen
slmgr -skms kms.rrze.uni-erlangen.de
goto WindowsAktivieren

:WindowsAktivieren
slmgr -ato


:: In Office Pfad wechseln
:: Hier wird einfach nur stupide geprüft, in welchem Verzeichnis Office installiert ist... 
:: Funktioniert für Office 2016 Pro Plus und neuer in 32/64bit unter Windows 32/64bit
::
:: Sofern vom Microsoft Standard abweichenden Installationspfade verwendet werden bitte anpassen
::
if exist "C:\Program Files (x86)\Microsoft Office\Office16\OSPP.VBS" pushd "C:\Program Files (x86)\Microsoft Office\Office16\"
if exist "C:\Program Files\Microsoft Office\Office16\OSPP.VBS" pushd "C:\Program Files\Microsoft Office\Office16\"
:: KMS Server eintragen

:: Prüfen auf Admin-Rechte
whoami /groups | find "S-1-16-12288" > nul 
if not errorlevel 1 goto OfficeKMSeintragen
goto OfficeAktivieren

:OfficeKMSeintragen
cscript ospp.vbs /sethst:kms.rrze.uni-erlangen.de
goto OfficeAktivieren

:OfficeAktivieren
cscript ospp.vbs /act

pause

Windows und Office müssen separat aktiviert werden.

Aktivierung von Office Pro Plus per KMS
Aktivierung von Office Pro Plus per KMS
Aktivierung von Windows Enterprise per KMS
Aktivierung von Windows Enterprise per KMS

  1. Eingabeaufforderung mit Run As Administrator bzw. Ausführen als Administrator starten
  2. slmgr -skms kms.rrze.uni-erlangen.de [Enter]
  3. Warten auf Ergebnisdialogbox
    „Der Schlüsselverwaltungsdienst-Computername wurde erfolgreich auf kms.rrze.uni-erlangen.de festgelegt“
  4. slmgr -ato
  5. Im Erfolgsfall erscheint die Ergebnisdialogbox
    „Windows(R) …. wird aktiviert… Das Produkt wurde erfolgreich aktiviert.“

Installationspfad ermitteln

Allgemein:
 C:\Windows Programmordner\Microsoft Office\Office 2016

MSO 2021 in 64bit auf einem 64bit Windows:

C:\Program Files\Microsoft Office\Office16\

In diesem Verzeichnis muss die Datei „ospp.vbs“ vorhanden sein.

Windows Programmordner ermitteln
Windows 32bit Windows 64bit
Office 32bit C:\Program Files\ C:\Program Files (x86)\
Office 64bit C:\Program Files\

Microsoft Office 2016 / 2019 / 2021  = Office16

KMS Server eintragen & Aktvierung durchführen

  • Eingabeaufforderung mit Run As Administrator bzw. Ausführen als Administrator starten
  • Ins Office Verzeichnis wechseln
  • cscript ospp.vbs /sethst:kms.rrze.uni-erlangen.de [Enter]
  • cscript ospp.vbs /act [Enter]

Aktivierung erzwingen

  • Eingabeaufforderung starten
  • Ins Office Verzeichnis wechseln
  • cscript ospp.vbs /act [Enter]

Restlaufzeit der Aktivierung anzeigen

  • Eingabeaufforderung starten
  • Ins Office Verzeichnis wechseln
  • cscript ospp.vbs /dstatus [Enter]

„REMAINING GRACE: xxx days (yyy minute(s) before expiring).“

Fehlersuche

Sie müssen die Ihnen zugeteilten IPv4-Netzbereiche bei der Software-Bestellung mit angeben, damit wir den KMS-Server freischalten. Änderungen und zusätzliche (private) (Sub)Netze müssen uns von der Kontaktperson der Einrichtung unter Angabe der Kundennummer an die Mailadresse software@fau.de mitgeteilt werden.

Vom Softwarelizenzierungsdienst wurde gemeldet, dass der Computer nicht aktiviert werden konnte. Der Schlüsselverwaltungsdienst (Key Management Service, KMS) ist nicht verfügbar.

Zu prüfen sind folgende Einstellungen des Geräts:

  • Datum
  • Uhrzeit
  • Sommer/Winterzeit
  • Zeitzone

Start / Ausführen / CMD (Eingabeaufforderung)

telnet kms.rrze.uni-erlangen.de 1688

Der KMS sollte mit einer leerer Ausgabe antworten. Wird die Verbindung nicht aufgebaut oder sofort geschlossen, besteht ein Verbindungsproblem zum KMS-Server.

C:\>nslookup -type=srv _vlmcs._tcp.fauad.fau.de
Server:  dns1.rrze.uni-erlangen.de
Address:  131.188.0.10

Non-authoritative answer:
_vlmcs._tcp.fauad.fau.de     SRV service location:
          priority       = 0
          weight         = 0
          port           = 1688
          svr hostname   = kms.rrze.uni-erlangen.de

fauad.fau.de            nameserver = faudc1.fauad.fau.de
fauad.fau.de            nameserver = faudc2.fauad.fau.de
kms.rrze.uni-erlangen.de        internet address = 131.188.13.36
faudc1.fauad.fau.de     internet address = 10.188.78.10
faudc2.fauad.fau.de     internet address = 10.188.78.11

Bekommt der Vista-Client keine entsprechende Antwort zurück, so ist entweder kein RRZE-Nameserver eingetragen oder der RRZE-Nameserver kann nicht erreicht werden.
überprüfen Sie Ihre IP- und DNS-Konfiguration.

C:\>nslookup -type=srv _vlmcs._tcp
Server:  dns1.rrze.uni-erlangen.de
Address:  131.188.0.10

Non-authoritative answer:
_vlmcs._tcp.fauad.fau.de     SRV service location:
          priority       = 0
          weight         = 0
          port           = 1688
          svr hostname   = kms.rrze.uni-erlangen.de

fauad.fau.de            nameserver = faudc1.fauad.fau.de
fauad.fau.de            nameserver = faudc2.faauad.fau.de
kms.rrze.uni-erlangen.de        internet address = 131.188.13.36
faudc1.fauad.fau.de     internet address = 10.188.78.10
faudc2.fauad.fau.de     internet address = 10.188.78.11

Klappt der vorherige Test mit dem fqdn, dieser Test schlägt aber fehl, so müssen Sie noch die DNS-Such-Suffixe in der IP-Konfiguration korrigieren. uni-erlangen.de bzw. fau.de muss in der Suchliste enthalten sein.

Exchange-Postfach in Outlook einrichten

Exchange-Postfach in Outlook einrichten

Wie kann ich ein Exchange-Postfach in Outlook einrichten?

Diese Anleitung richtet sich ausschließlich an Inhaber eines Exchange-Postfachs. Ein Exchange-Postfach kann im IdM unter Anfragen/Aufgaben beantragt werden, wobei die Voraussetzung dafür ein Beschäftigungsverhältnis mit der FAU ist. Nutzer eines FAUMail-Postfachs können den Zugriff darauf per IMAP-Protokoll einrichten. Weitere Informationen dazu finden Sie unter Adressen der Mailserver im Überblick.

Vom RRZE unterstützte Outlook-Versionen: Version 2019 und höher.

Was benötigen Sie für die Konfiguration von Outlook unter Windows:

  • Exchange-Benutzerkennung aus IdM
  • Kennwort der Exchange-Benutzerkennung

In der Regel ist die IdM-Benutzerkennung auch die Exchange-Benutzerkennung. Es gibt aber auch Ausnahmen. Sollten Sie sich nicht sicher sein, so fragen Sie ihren EDV-Betreuer vor Ort.

In dieser Dokumentation wird Outlook 2019 für Max Mustermann mit der Exchange-Benutzerkennung ex56hgaf eingerichtet.

Wichtig: Ein evtl. vorhandener GroupWise-Client muss vor der Installation von Outlook deinstalliert werden.

Starten Sie Outlook wie gewohnt und folgen Sie jetzt einfach den Anweisungen, wie in den folgenden Bildern beschrieben.

Im Feld Ihr Name tragen Sie ihren Vor- und Nachnamen ein.
Als E-Mail-Adresse verwenden Sie Ihre E-Mail-Adresse unter @fau.de.

 

Bei diesem Schritt ist es wichtig, dass Sie den vorgeschlagenen Benutzernamen nicht verwenden, sondern den Punkt Anderes Konto verwenden auswählen.

Tragen Sie als Benutzername fauad\<Exchange-Benutzerkennung> ein. Sollte hier die FAU-Adresse angezeigt werden, wählen Sie den Punkt Anderes Konto verwenden weiter unten aus.
In unserem Beispiel lautet die Exchange-Benutzerkennung von Max Mustermann ex56hgaf. Also trägt er fauad\ex56hgaf ein.

Anschließend wieder das dazugehörige Kennwort.

Ob Sie die Anmeldedaten speichern, liegt in Ihrem Ermessen. Am besten informieren Sie sich über mögliche Risiken bei Ihrem EDV-Betreuer vor Ort.

Nachdem Sie Fertig stellen ausgewählt haben, ist Ihr Exchange-Postfach in Outlook vollständig eingerichtet.

 

Manchmal erscheint die nachstehend dargestellte Meldung. Hier empfehlen wir, den Zugriff auf diese Adressen zuzulassen und diese Antwort zu speichern, indem Sie das Häkchen bei Zukünftig nicht mehr zu dieser Website fragen setzen.

Das Bild zeigt das Dialogfenster "Microsoft Outlook". Sie sollen "Zukünftig nicht mehr zu dieser Website fragen" aktivieren und auf "Zulassen" klicken.

Über diesen Service wird die initiale Einrichtung des Exchange-Postfachs durchgeführt und einige selbstverständliche Angaben bei der Einrichtung dem Benutzer abgenommen. Ebenso werden darüber weitere Postfächer, auf die Sie inzwischen Zugriffsrechte erhalten haben, automatisch verbunden. Sollten Sie die Antwort nicht speichern, werden Sie erneut gefragt, sobald Outlook automatisch eine Anfrage an den Autodiscover-Service stellt.

Manche Outlook-Clients beziehen die Konfiguration vom https://autodiscover.fau.de/autodiscover/autodiscover.xml und manche vom https://groupware.fau.de/autodiscover/autodiscover.xml. Beide Adressen sind gültig und vollkommen gleichwertig.

Weitere Informationen zu Exchange und Outlook finden Sie unter http://www.rrze.uni-erlangen.de/dienste/e-mail/postfaecher/exchange.shtml

Software-Server LSD (dienstliche Nutzung)

Das RRZE verteilt lizenzpflichtige Software zur dienstlichen Nutzung über das Kommunikationsnetz der FAU via Webserver LSD (Licensed Software Distribution) – zugangsbeschränkt auf RRZE-Kontaktpersonen.

Technische Voraussetzungen

Der Download-Rechner muss per LAN oder VPN (nicht WLAN) mit dem Hochschulnetz verbunden sein

Software-Server

https://lsd.rrze.fau.de/

Login

Nur RRZE-Kontaktpersonen können sich mit Ihrer KP-Kennung anmelden. Die KP-Kennung hat die Form

  • ????00kp
  • ????00k2

Beachten Sie die Informationen zur Passwortänderung.

IBM SPSS

Produkte

Der Campusvertrag FAU + Region für Studierende und Beschäftigte umfasst

SPSS (macOS, Windows) inklusive Amos (nur Windows)

  • Beschäftigte
    • Einzelplatz für Beschäftigte (Home Use)
    • Netzwerk für Beschäftigte und PC-Pools
  • Studierende
    • Einzelplatz für Studierende
    • Netzwerk LV für Studierende

Nutzergruppen

Beschäftigte wenden sich an

  • FAU: die RRZE-Kontaktperson / IT-Admin der Einrichtung.
  • Region: das eigene Hochschulrechenzentrum / den IT-Admin der Einrichtung.
  • Es müssen kostenpflichtige Lizenzen im RRZE-Kundenportal gemäß RRZE-Software-Preisliste bestellt werden.

Studierende

  • können die Netzwerk-Lizenz kostenlos nutzen.
  • Die kostenpflichtige Einzelplatzlizenz muss nur bei Offline-Betrieb im Feld erworben werden, oder wenn in Gegenden mit instabiler Internetverbindung gearbeitet wird.

Laufzeit und Preis

Einzelplatz für Studierende inklusive Amos:

  • EUR 60,00 pro Lizenzperiode (Fixpreis)
  • Die Lizenz ist gültig vom Tag der Bereitstellung des Lizenzkeys bis zum Ablauf der Lizenzperiode am 30. September. Kürzere Laufzeiten sind nicht möglich.
  • Lizenzkosten werden für jedes Lizenzjahr neu festgelegt.
  • Jeder Lizenzkey kann nur einmal vergeben werden. Verbrauchte Lizenzkeys können nicht ersetzt werden.

Download

erfolgt über die StudiSoft.de Auftragsverfolgung.

  • Installationsdateien sind direkt nach Bestellung in der StudiSoft Auftragsverfolgung zu finden.
  • Netzwerk LV für Studierende: Lizenzserverdaten sind direkt nach Bestellung in der StudiSoft Auftragsverfolgung zu finden.
  • Einzelplatz für Studierende inklusive Amos: Lizenzkey und Installationsdateien sind nach Zahlung der Lizenzgebühr spätestens nach fünf (5) Arbeitstagen in der StudiSoft Auftragsverfolgung zu finden. Die Information über die Bereitstellung erfolgt an die E-Mail-Adresse der Hochschule.

Hilfe und Support

Für fachlichen Support und Anwendungsfragen zu IBM-SPSS-Software sind die reichhaltigen Ressourcen des Herstellers IBM empfehlenswert. IBM SPSS Produkt-Support mit zahlreichen Dokumentationen und Ressourcen zur jeweils aktuellen Version ist ebenfalls verfügbar.
https://www.ibm.com/mysupport/

Häufig gestellte Fragen

IBM SPSS

Aktivieren von SPSS Einzelplatz und Amos

Bei  betreuten Geräten (Dienstgeräte) der FAU kontaktieren Sie ihr Betreungszentrum (IZ*) oder IT-Admins der Einrichtung.

Regionalpartner-Hochschulen wenden sich an ihr eigenes Rechenzentrum.

Für Studierende und die Home Use-Nutzung durch Beschäftigte stehen die Installer in der StudiSoft Auftragsverfolgung bereit.

Vor der Installation alle anderen / ältern SPSS Installationen und Demoversionen deinstallieren.

SPSS aktivieren

Studierende erhalten den  Aktivierungsschlüssel in der StudiSoft Auftragsverfolgung.

Für Home Use wenden sich  Beschäftigte an die  RRZE-Kontaktperson ihrer Einrichtung.

Um SPSS zu aktivieren, benötigen Sie eine Internetverbindung.

  1. SPSS  installieren und starten
  2. „Lizenzassistenten starten“
  3. „Lizenz für berechtigte Benutzer“ (=Einzelplatzlizenz) wählen und „Weiter“
  4. Activation Key eingeben und „Weiter“.

Amos aktivieren

Alle älteren Versionen und Demoversionen deinstallieren.

  1. SPSS installieren und aktivieren
  2. AMOS installieren und ebenso aktivieren
Aktivieren von SPSS Netzwerk und Amos
  1. SPSS installieren
  2. VPN-Verbindung zum Hochschulnetz aufbauen
  3. SPSS starten
  4. „Lizenzassistenten starten“
  5. „Lizenz für gleichzeitige Benutzer“ (=Netzwerklizenz) wählen
  6. Lizenzserver eintragen und „Weiter“
  7. Abschließend wird der Lizenzstatus angezeigt.
    Mit „Weiter“ Lizenzassistenten beenden

Amos aktivieren

Alle älteren Versionen und Demoversionen deinstallieren.

  1. SPSS installieren und aktivieren
  2. AMOS installieren und ebenso aktivieren
Dokumentationen SPSS und Amos
Hilfe und Support für SPSS

Für fachlichen Support und Anwendungsfragen zu IBM-SPSS-Software sind die reichhaltigen Ressourcen des Herstellers IBM empfehlenswert. IBM SPSS Produkt-Support mit zahlreichen Dokumentationen und Ressourcen zur jeweils aktuellen Version ist ebenfalls verfügbar.
https://www.ibm.com/mysupport/

Für Fragen, die nicht mit den Herstellerseiten gelöst werden können und den Download bzw. die Installation von IBM-SPSS-Software sowie technischen Support betreffen, ist eine Anfrage unter Verwendung der Hochschul-E-Mail-Adresse mit detaillierter Fehlerbeschreibung an den Support des Hochschulrechenzentrums zu senden.

RRZE-Lizenzbereiche FAU und Region

Im Rahmen des RRZE-Regionalkonzepts werden folgende Hochschulen versorgt:

  • Evangelische Hochschule Nürnberg
  • Friedrich-Alexander-Universität Erlangen-Nürnberg
  • Hochschule Coburg
  • Hochschule Hof
  • Technische Hochschule Nürnberg Georg Simon Ohm
  • Technische Hochschule Würzburg-Schweinfurt
  • Technische Universität Nürnberg
  • Universität Bamberg
  • Universität Bayreuth
  • [weitere Teilnehmer möglich]
SPSS Netzwerk: Lizenzserver nicht erreichbar (Studierende)

Die Nutzung von SPSS-Netzwerk auf Privatrechnern von Studierenden ist nur bei aktiver Verbindung ins Hochschulnetz möglich, d.h. das Gerät muss per VPN mit dem Hochschulnetz verbunden sein.

  • VPN-Verbindung aufgebaut?
    whatsmyip.fau.de
  • Ist in der lokalen Firewall der UDP-Port 5093 für den Lizenzserver freigeschaltet?
SPSS Netzwerk: Probleme mit der Lizenzautorisierung

Wenn Sie SPSS öffnen, kommt nur die normale Anmeldung und Sie sollen ein IBM-Benutzerkonto erstellen?

  • ALLE vorhandenen SPSS (Demo)-Versionen über die Windows-Systemsteuerung deinstallieren, sonst können Sie SPSS später nicht über den Lizenzserver nutzen.
  • Anschließend SPSS erneut installieren
    • Beschäftigte: Es müssen kostenpflichtige Lizenzen im RRZE-Kundenportal gemäß RRZE-Software-Preisliste bestellt werden. Lizenzserverdaten und Installationsdateien sind bei der RRZE-Kontaktperson / IT-Admin der Einrichtung erhältlich.
    • Studierende: Lizenzserverdaten und Installationsdateien sind in der StudiSoft Auftragsverfolgung zu finden.
Systemvoraussetzungen SPSS und Amos

Die technischen Systemvoraussetzungen für IBM SPSS und Amos sind auf den Produktseiten des Herstellers IBM nachzulesen:
https://www.ibm.com/software/reports/compatibility/clarity/index.html

Versionen: Welche IBM SPSS-Versionen stehen zur Verfügung?

Dem RRZE liegen i.d.R. Lizenzkeys für die aktuelle Version, sowie max. zwei Vorgängerversionen vor. Ältere SPSS-Versionen werden vom Hersteller nicht (oder nur zeitlich befristet) unterstützt und werden deshalb vom RRZE nicht zum Download bereit gestellt.

In CIP-Pools und auf Dienstgeräten der Hochschule können bei Bedarf ältere Versionen zur Verfügung gestellt werden. Kontakt: software@fau.de

Studierende erhalten die Software nur in der aktuellen Version zum Download.

Die verfügbaren (unterstützten) Versionen von IBM SPSS sind auf der RRZE-Webseite veröffentlicht.

Stand: 19.09.2025

VPN

eduVPN

eduVPN ist die neue einheitliche VPN-Lösung für alle Nutzer. Hier finden Sie den Link zum Download des Clients und unsere Anleitung. Rechner die zentral vom RRZE verwaltet werden, haben den Client bereits vorinstalliert oder müssen ihn über die jeweilige Softwareverteilung beziehen. Kontaktieren Sie hierzu ggf. Ihren lokalen IT-Betreuer.

Zum Verbinden müssen Sie einmalig im Client nach der „FAU“ suchen und unter „Zugang zum Institut“ auf „FAU Friedrich-Alexander-Universität Erlangen-Nürnberg“ klicken. Danach werden Sie zur Authentifizierung auf eine Portalseite umgeleitet, dort geben Sie Ihre IdM-Kennung und Ihr IdM-Passwort (oder falls Sie die Passwortsynchronisation im IdM deaktiviert haben Ihr VPN-Passwort) und ggf. den 2. Faktor ein. Der Client erstellt dann eine VPN-Sitzung, die Sie eine Woche lang ohne erneute Authentifizierung nutzen können.

Hier finden Sie den Download für die gängigen Betriebssysteme: https://eduvpn.org (nicht für WinSV oder FAUmac Self Service, bitte nur von dort holen).

Sie können gleichzeitig nur eine aktive Sitzung verwenden, der zuletzt verbundene Client „gewinnt“. Bereits verbundene Clients zeigen dies leider nicht gesondert an, sondern leiten einfach keine Daten mehr weiter (Client ist „Verbunden“ und grün, aber „alles hängt“). Es muss dann einmalig der Schieberegler aus- und wieder eingeschaltet werden.

Unter https://eduvpn.fau.de/vpn-user-portal/account können Sie nach dem Login mit Ihrer jeweiligen Kennung die aktuell autorisierten Clients sehen und bei Problemen diese widerrufen. Danach müssen Sie sich im Client neu anmelden. Achtung auch hier: Ein noch aktiver Client bekommt vom Widerruf nichts mit. Er bleibt „Verbunden“ und grün, leitet aber keine Daten mehr durch den Tunnel.

Mitarbeiter können im IdM-Portal unter „Einstellungen & Anträge -> Allgemeine Einstellungen -> Virtual Private Network (VPN)“ eine zusätzliche VPN-Kennung beantragen um gleichzeitig mit einem weiteren Gerät eine Verbindung aufbauen zu können. Dies ist z.B. auf Dienstreisen interessant für Laptop und Smartphone, o.ä.

Eine bebilderte PDF-Anleitung steht zum Download zur Verfügung:

Installationsanleitung Installation Instructions

 

Kerberos und WebSSO

Diese Funktionalität im WebSSO Dienst wurde abgeschaltet.

Die Anleitung wird nur noch zu Dokumentationszwecken erhalten.

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
  • Bestätigen Sie die Sicherheitswarnung
  • Suchen Sie nach negotiate
  • Passen Sie die folgende Einträge an
network.negotiate-auth.delegation-uris = .sso.uni-erlangen.de,.sso.fau.de
network.negotiate-auth.trusted-uris = .sso.uni-erlangen.de,.sso.fau.de

So sollte es am Ende aussehen.

Konfiguration von Firefox für WebSSO via Kerberos
Konfiguration von Firefox für WebSSO via Kerberos

Chromium

Zur Konfiguration von Chromium gehen Sie bitte wie folgt vor.

Diese Einstellung wirkt systemweit für alle Benutzer!

bash$ sudo vi /etc/chromium-browser/default
...
CHROMIUM_FLAGS="--auth-server-whitelist=.sso.uni-erlangen.de,.sso.fau.de --auth-negotiate-delegate-whitelist=.sso.uni-erlangen.de,.sso.fau.de"
..

Google Chrome

Zur Konfiguration von Google Chrome gehen Sie bitte wie folgt vor.

Diese Einstellung wirkt systemweit für alle Benutzer!

bash$ sudo mkdir -m 755 -p /etc/opt/chrome/policies/managed
bash$ sudo vi /etc/opt/chrome/policies/managed/kerberos.json 
{ 
     "AuthServerWhitelist": "*.sso.uni-erlangen.de,*.sso.fau.de", 
     "AuthNegotiateDelegateWhitelist": "*.sso.uni-erlangen.de,*.sso.fau.de" 
}
bash$ sudo chmod o+rx /etc/opt/chrome/policies/managed/kerberos.json

 

 

Kerberos und langlaufende Prozesse

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.

Verlängerte Ticketlaufzeit anfordern (max. 24 Stunden Laufzeit)

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.

(Auszug aus der Manpage zu krenew)

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.

Pakete für Ubuntu 20.04 und höher

# i-want-it-all one-liner
bash$ sudo DEBIAN_FRONTEND=noninteractive apt-get install krb5-user libsasl2-modules-gssapi-mit libpam-krb5 nfs-common keyutils cifs-utils openssh-server openssh-client
# 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.

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
    kdc_timesync = 1
    ccache_type = 4
    forwardable = true
    proxiable = true

    # maximum is 24h - but client defaults to 10h
    ticket_lifetime = 10h


[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.

bash$ sudo cp /etc/ssh/ssh_config /etc/ssh/ssh_config_old
bash$ sudo vi /etc/ssh/ssh_config
...
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes
GSSAPITrustDns yes 
...

SSH Server

Folgende Einstellungen ermöglichen das kerberos-authentifizierte Einloggen  von anderen Systemen via SSH.

bash$ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config_old
bash$ sudo vi /etc/ssh/sshd_config
...
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
...

NFS Client

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.

bash$ sudo cp /etc/request-key.conf /etc/request-key.conf_old
bash$ sudo vi /etc/request-key.conf
...
create  cifs.spnego     *       *               /usr/sbin/cifs.upcall -t %k
...
bash$ sudo cp /etc/request-key.d/cifs.spnego.conf /etc/request-key.d/cifs.spnego.conf_old
bash$ sudo vi /etc/request-key.d/cifs.spnego.conf

create  cifs.spnego     *       *               /usr/sbin/cifs.upcall -t %k

Generic Security Api (GSS)

Stellen Sie sicher der der gssd gestartet ist:

bash$ ps aux | grep gssd
root 1760 0.8 0.0 43796 3852 ? Ss Nov15 112:24 /usr/sbin/rpc.gssd

Sollte das nicht der Fall sein , so starten Sie den gssd mittels

# Ubuntu 20.04 und höher
bash$ sudo systemctl start rpc-gssd

Restart/Reboot

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.

Kerberos

 

bash$ kinit [Kennung]
bash$ klist

Ticket cache: FILE:/tmp/krb5cc_[UID]_qdIQWB
Default principal: [Kennung]@LINUX.FAU.DE

Valid starting       Expires              Service principal
17.11.2016 16:07:22  18.11.2016 16:07:22  krbtgt/LINUX.FAU.DE@LINUX.FAU.DE

SSH Client

bash$ ssh dialog.rrze.uni-erlangen.de

# login success

bash$ klist

Ticket cache: FILE:/tmp/krb5cc_[UID]_fNDrEQQxAx
Default principal: [Kennung]@LINUX.FAU.DE

Valid starting       Expires              Service principal
17.11.2016 17:16:44  18.11.2016 16:07:22  krbtgt/LINUX.FAU.DE@LINUX.FAU.DE

NFS

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 20.04 und höher

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

# Home mounts

# Archiv
archiv alexandria.rrze.uni-erlangen.de:/archiv/archiv

# NFSv4 RRZE linuxhome
rzlin -fstype=nfs4,minorversion=1,sec=krb5p rrzenfs4.rrze.uni-erlangen.de:/export/linuxhome
rzleg -fstype=nfs4,minorversion=1,sec=sys rrzenfs4.rrze.uni-erlangen.de:/export/linuxhome.sys

# CIFS RRZE windowshome
# see auto.rzwin

/etc/auto.rzwin

# 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 20.04 und höher / 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

bash$ sudo automount -m 
autofs dump map information
===========================

global options: none configured
Mount point: /home

source(s):

  instance type(s): file 
  map: /etc/auto.home

  rzlin | -fstype=nfs4,minorversion=1,sec=krb5p rrzenfs4.rrze.uni-erlangen.de:/export/linuxhome
  campus | faunfs.rrze.uni-erlangen.de:/samfs_shome/campus
  archive | alexandria.rrze.uni-erlangen.de:/archiv/archiv
  studhome | faunfs.rrze.uni-erlangen.de:/samfs_shome/campus
  rzleg | -fstype=nfs4,minorversion=1,sec=sys rrzenfs4.rrze.uni-erlangen.de:/export/linuxhome.sys
  rrze | faunfs.rrze.uni-erlangen.de:/samfs_mhome/rrze
  archiv | alexandria.rrze.uni-erlangen.de:/archiv/archiv


Mount point: /home/rzwin

source(s):

  instance type(s): file 
  map: /etc/auto.rrzewindowshome

  * | -fstype=cifs,user=$USER,domain=FAUAD,sec=krb5,cruid=$UID,multiuser,noserverino ://home.rrze.uni-erlangen.de/&

...

 

NFSv4 Server

Beschreibt die Einrichtung eines NFSv4 Fileservers unter Ubuntu.

Siehe auch das offizielle Ubuntu NFSv4Howto für weitere Infos.

Pakete für Ubuntu 20.04 und höher

bash$ sudo apt-get install nfs-kernel-server

Konfiguration

Beschreibt die weitere Konfiguration des NFSv4 Servers.

Kerberos

Ihr Server muss für Kerberos konfiguriert sein!
Für Hilfe bei der Konfiguration von Kerberos folgen Sie bitte der Anleitung zur Anbindung Ihres Client/Servers an die RRZE-Infrastruktur.

Für den Betrieb mit Kerberos muss auch ein entsprechender Service-Principal für NFS vorhanden sein.
Prüfen Sie dies bitte mit folgendem Befehl.

bash$ sudo klist -kte
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   ...
   2 nfs/[IHR SERVER]@LINUX.FAU.DE (aes256-cts-hmac-sha1-96) 
   2 nfs/[IHR SERVER]@LINUX.FAU.DE (aes128-cts-hmac-sha1-96) 
   2 nfs/[IHR SERVER]@LINUX.FAU.DE (des3-cbc-sha1) 
   2 nfs/[IHR SERVER]@LINUX.FAU.DE (arcfour-hmac)

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.

bash$ cat /etc/fstab
....
/some/nested/data/dir /export/sys none bind
...

Exportierte Verzeichnisse

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).

bash$ sudo exportfs -rv
exporting 169.254.0.0/255.255.255.128:/export/krb5_enc
exporting 169.254.0.0/255.255.255.128:/export/krb5_int
exporting 169.254.0.0/255.255.255.128:/export/krb5
exporting 169.254.0.0/255.255.255.128:/export/sys

Nach erfolgreicher Aktualisierung (oder auch jederzeit zur Überprüfung) können Sie die aktuell aktiven exportierten Verzeichnisse wie folgt abfragen.

bash$ sudo exportfs -v
/export/krb5_enc 169.254.0.0/255.255.255.128(rw,async,sec=krb5p,no_subtree_check)
/export/krb5_int 169.254.0.0/255.255.255.128(rw,async,sec=krb5i,no_subtree_check)
/export/krb5 169.254.0.0/255.255.255.128(rw,async,sec=krb5,no_subtree_check)
/export/sys 169.254.0.0/255.255.255.128(rw,async,sec=sys,no_subtree_check)

Test

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