Wie in Teil 1 beschrieben, basiert die integrierte MFA-Lösung von IBM i auf einem temporär gültigen Schlüssel, einem Time-based one-time Password (TOTP), welches im Benutzerprofil gespeichert und wie das Passwort geschützt ist. Der TOTP-Schlüssel wird zusammen mit der Systemzeit verwendet, um einen TOTP-Wert zu erzeugen. und wird als zusätzlicher Faktor bei der Authentifizierung verwendet.

Die IBM i-Implementierung basiert auf RFC 6238 -TOTP: Time-Based One-Time Password Algorithm, so dass jede kompatible Client-Anwendung wie eine PC-Anwendung, Smartphone- bzw. Smartwatch-App oder ein physischer Token, der standardkonform ist, verwendet werden kann.

Die Client-Anwendung zeigt, nachdem sie mit dem TOTP-Schlüssel konfiguriert wurde, TOTP-Werte basierend auf dem TOTP-Schlüssel und der aktuellen Zeit auf dem Gerät an.

Der Benutzer gibt den TOTP-Wert als zusätzlichen Anmeldefaktor bei der Authentifizierung ein. Das Betriebssystem validiert dann gleichzeitig Benutzer-ID, Passwort und TOTP-Wert, wodurch es eine Multi-Faktor-Authentifizierung ist.

Damit gibt es seitens des Administrators, wie in Teil 1 beschrieben, einiges vorzubereiten:

Einstellung der Sicherheitsstufe 40 oder 50 und setzen des Password Levels auf 4.
Systemweite Aktivierung von MFA mit CHGSECA oder über den Navigator for i.
TLS für die Netzwerkverbindungen einrichten

Erst danach können User TOTP Keys erzeugen. Statt mit dem Navigator for i kann dies auch über die Befehlszeile mittels CHGTOTPKEY erfolgen. Nur ist die Übernahme des Keys bei weitem nicht so komfortabel wie mit einem QR Code.

Da manche Anwendungen auf zwischengespeicherte Passwörter angewiesen sind, können sie nicht mit einer kurzen Lebensdauer eines TOTP-Tokens funktionieren. Um diese auch zu unterstützen. wurde das TOTP Zeitintervall konzipiert, welches ebenfalls im Benutzerprofil eingestellt werden kann.

Die Einstellung *NONE entspricht 0 Sekunden, und somit erfordert jede passwortbasierte Authentifizierung einen gültigen TOTP-Token. Sowas kann mit Anwendungen, die zwischengespeicherte Passwörter verwenden, nicht funktionieren. Andere dagegen können für jede Verbindung zum System zu einer erneuten Anmeldung auffordern, was nicht sehr praktikabel wäre.

Ein TOTP Intervall > 0 bietet hier die Lösung. Mit einer passwortbasierten Authentifizierung mit dem TOTP-Token beginnt das Timeout-Intervall. Nachfolgende passwortbasierte Authentifizierungen erfordern nur noch ein Passwort, bis das Intervall ablaufen ist. Einstellbar sind 1 bis 720 Minuten.

Einstellungen bzgl. MFA, die Länge des TOTP Intervalls sowie die Restgültigkeitsdauer eines TOTP können über DSPUSRPRF abgefragt werden.

So können ACS und der Navigator innerhalb von Minuten hunderte einzelne Host-Server-Verbindungen herstellen, was ohne ein zwischengespeichertes Passwort problematisch werden würde. D. h aber auch, dass das TOTP Intervall für die Nutzung des Navigators for i auch gesetzt sein muss!
Sollte dieser Wert auf “*NONE*, also 0 Sekunden, stehen, erfolgt selbst bei gültiger Eingabe von User, Passwort und TOTP eine Fehlermeldung:

“NAV_300064: Authentication successful. The user’s MFA interval is *NONE and Navigator has not been configured to use TLS. You must turn on TLS for all users, increase your MFA interval, or remove MFA authentication from your profile to login”

Um sich also erfolgreich authentifizieren zu können, muss das TOTP Intervall größer 0 sein und die Verbindung verschlüsselt über SSL/TLS erfolgen

https://<hostname oder IP>:2003/Navigator.

Neue Benutzerprofile

Das System stellt viele Benutzerprofile für das Betriebssystem bereit, an denen Benutzer auch Änderungen vornehmen können. Zusammen mit MFA könnte dies zu Problemen führen. Daher wurden vier neue Profile eingeführt, die diese Probleme lösen:

QPGMR_NC
QSECOFR_NC
QSYSOPR_NC
QUSER_NC

Diese Profile haben die gleichen Privilegien wie ihre Gegenstücke, nur dass sie ohne Passwörter und mit Namen ausgeliefert werden, die auf _NC enden, was darauf hindeutet, dass sie nicht veränderbar sind.

Diese Profile werden vom Betriebssystem und von Anwendungen verwendet. Viele Systemschnittstellen werden aktualisiert, um diese neuen Profile zu verwenden.

Host Connection Server

In einer typischen Konfiguration benötigt jeder Hostserver eine separate Authentifizierung. Wenn MFA aktiv ist und das Benutzerprofil einen zusätzlichen Authentifizierungsfaktor benötigt, muss dieser Faktor während des Authentifizierungsprozesses angegeben werden.

IBM i 7.6 führt daher den Host Connection Server (HCS) als Frontend zu den bekannten Host-Servern ein und ermöglicht so persistente TOTP/MFA-authentifizierte Verbindungen. Der HCS erfordert TLS und verwendet Port 9480. (Somit auch der Navigator for i! ?)

Der Host-Connection-Server unterstützt eine einzelne Authentifizierung, sodass die authentifizierte Sitzung bei der Einrichtung neuer Verbindungen zu anderen Host-Servern wiederverwendet werden kann.

ACS 1.1.9.7, Navigator for i, DCM und andere IBM Client-Anwendungen wurden auf HCS aktualisiert und funktionieren daher auch mit Benutzerprofilen ohne explizite Angabe eines TOTP Intervalls.

Insbesondere für ODBC oder JDBC Verbindungen ist dies hilfreich, da wahrscheinlich die jeweiligen Treiber nicht für MFA ausgelegt sind. ein größeres TOTP Intervall zu wählen und sich einmalig mit seinem TOTP, beispielsweise am Morgen über ACS, mit seinem zusätzlichen Faktor zu authentifizieren.

Manchmal gibt es auch Anwendungen, die etwas unter einem anderen Benutzerprofil auszuführen, nur basierend auf der Berechtigung aufrufenden Benutzerprofil – was eigentlich im Widerspruch zu den MFA-Prinzipien steht. Die IBM i integrierte MFA-TOTP-Implementierung erlaubt prinzipiell diese Passwortumgehung. Mit der Sicherheitsfunktion “Run under a user without authentication” QIBM_RUN_UNDER_USER_NO_AUTH kann dies verhindert werden.

Der Standardzugriff auf die Funktion ist für alle Benutzer *ALLOWED und kann nicht in *DENIED geändert werden. Wenn ein Benutzerprofil als *DENIED zur Liste hinzugefügt wird, schlagen solche Operationen mit diesem Zielbenutzerprofil fehl.

Diese Funktions-ID ist einzigartig, da sie nicht das Benutzerprofil auf die *DENIED-Liste setzt, dessen Aktionen dann eingeschränkt werden, sondern andere Benutzerprofile, die daran gehindert sind, dieses Benutzerprofil als Ziel zu verwenden. Dies schützt die Integrität der vom Benutzer auf der Liste ausgeführten Aktionen, indem verhindert wird, dass ein anderer Benutzer mit *ALLOBJ-Sonderbefugnis als diese Person ausgeführt wird.

MFA für ssh

Für Anwendungen, wie ssh und sftp, die kein traditionelles Signon-Display besitzen, bietet IBM i 7.6 bietet eine Lösung durch Anhängen des TOTP zum eigentlichen Passwort, wobei zwischen dem Passwort und dem TOTP ein Doppelpunkt (:) als Trennzeichen benutzt wird.

Beispiel: myAmazingPa$$w0rd:358538

Dies war auch bis ACS 1.1.9.10 für den Aufruf des Open Package Management notwendig.

Neuerdings öffnet sich jetzt ein separates Eingabefenster und fordert zur Eingabe des TOTP auf, falls man vergessen hat, den TOTP anzuhängen.

Der “Trick” über das TOTP Intervall funktionier aber auch hier.

MFA für SST/DST

Bisher gab es für die Systemservice-Tools (SST) und dedizierte Service-Tools (DST) Umgebung keine MFA-Lösungen von Drittanbietern, da es keine Exit Point Unterstützung gibt, noch Authentifizierungsmethoden wie bei Kerberos in dieser Umgebung nicht funktionieren

Wenn MFA eingesetzt wird, sollten privilegierte SST/DST-Nutzer dazu verpflichtet werden, mehrere Authentifizierungsfaktoren bereitzustellen

IBM i 7.6. unterstützt nun für SST/DST die nun eine MFA-TOTP-Key Implementierung, die nicht mit der MFA-Unterstützung des Betriebssystems verbunden ist. Ein SST-Administrator kann MFA für SST aktivieren, ohne es im Betriebssystem zu aktivieren zu müssen.

Das Aussehen, die Konfiguration und die Benutzung ähneln dem des Betriebssystems, allerdings erlaubt SST nicht, eine TOTP Intervall festzulegen. Es ist jedes Mal die Eingabe eines TOTP erforderlich, wenn auch ein Passwort benötigt wird.

Zum Test habe ich mir eine User MFA4SST eingerichtet, Benutzerklasse *USER und einem Passwort, welches nach der Einrichtung auf *NONE gesetzt werden kann. Mit dem User und Passwort kann ich mir leicht einen TOTP Key mit dem Navigator for i erzeugen und auch den TOTP in meiner OTP App einrichten, wie in Teil 1 beschrieben. ABER bitte nicht nur den QR Code scannen, sondern sich auf den TOTP Key merken! (Ich habe z.B. Notepad genommen und diesen zusammen mit dem Recovery Key in eine Textdatei kopiert.)

Mit meinem SST User habe ich mich in SST angemeldet und über Menüpunkt 8 “Work with Service Tools Server Security and Devices” und 5 “Work with service tools security options” das Attribut “Additional sign-on factor enabled” auf “1” gesetzt und damit MFA für SST/DST generell eingerichtet. Alternativ kann dies auch über CHGSSTSECA CHGADLSGN(*YES) erfolgen.

Nach einem erneuten Anmelden erscheint dann auch das Feld für den zusätzlichen Faktor in der Anmeldemaske.

Da mein Benutzer nicht für MFA eingerichtet wurde, reicht nach wie vor der Benutzername und das Passwort aus, um mich erneut anzumelden. Wie gewohnt erstelle ich nun mir einen neuen SST User MFA4SST zusammen mit einem SST-Passwort. Als “linked profile” habe ich natürlich MFA4SST gewählt. Klar bekommt er auch ein paar Rechte, was aber für unser Vorhaben nicht relevant ist.

Mit diesem neuen User MFA4SST kann man sich in SST nun anmelden, und über den Menüpunkt 8 “Work with Service Tools Server Security and Devices” und 1 “Work with Service Tools User Ids” sowie der Auswahl 8 “Change TOTP key” einen TOTP Key einrichten. In der nachfolgenden Anzeige können wir nun den vorher gespeicherten Key hinterlegen.

Danach erfolgt eine Prüfung, ob dieser User MFA4SST sich auch wirklich mit einem zusätzlichen TOTP anmelden kann.

Anschließend kann MFA4SST auch sein User ID Attribute mit Auswahl 6 so ändern, dass künftig auch der TOTP bei einer Anmeldung an SST eingegeben werden muss.

Das schließt die Einrichtung für MFA4SST für eine Anmeldung ab. Wenn man will, kann man für den IBM i User MFA4SST das Passwort auf *NONE setzen.

Zum Einsatz von „third party“ Produkten zur MFA Authentifizierung bietet IBM i 7.6 den Exit Point QIBM_QSY_AUTH, auf den hier nicht weiter eingegangen wird. Damit verbunden gibt es die Einstellung *REGFAC als Authentifizierungsmethode im Benutzerprofil.

Da es Anwendungen gibt, die zusammen mit MFA nicht betrieben werden können, sollte man (wie immer) den Einsatz vorher ausgiebig testen.

Für weitere Details gehen Sie bitte auf : https://www.ibm.com/docs/en/i/7.6.0?topic=mfa-overview

Der Autor Ralf Reetmeyer schreibt regelmäßig für den MIDRANGE Deep Dive.

Ralf Reetmeyer ist Geschäftsführer der UBR Reetmeyer GmbH.