
Der XML Export von OTP Tokens in der Sophos Firewall ist nur für lokale Benutzer möglich. Tokens von Benutzern aus externen Authentifizierungsquellen wie ActiveDirectory oder LDAP sind bei dem Export nicht enthalten. In dieser Anleitung wird ein Weg gezeigt, wie es trotzdem geht.
Einleitung
Wenn man Konfigurationen von einer Sophos Firewall auf eine andere manuell transferieren muss, wird man kleine Einschränkungen diesbezüglich feststellen. Zum Beispiel sind im XML Export nur die OTP Tokens von lokal in der Firewall angelegten Benutzern enthalten. Warum genau dies von Sophos hier ausgeschlossen wird, ist mir nicht ganz klar. Zumal die Tokens bei einer Wiederherstellung eines vollständigen Backups enthalten sind.
Bei dem Wechsel der Firewall werden die meisten Admins den Backup-Weg nehmen und sind hiervon nicht betroffen. Wer aber lieber ausgewählte Konfigurationen übertragen will, oder von einem 1U/2U Modell auf ein kleines Desktop Modell wechselt, wird auf dieses Problem treffen. Letzteres ist weiterhin von Sophos nicht in jeder Konstellation unterstützt zum jetzigen Stand und SFOS 21. Ich will aber nicht unerwähnt lassen, dass seit spätestens SFOS 20.0.2 ein Umweg laut der Kompatibilitäts-Matrix gehen sollte: 1US/1UL/2U --> virtuelle Appliance --> XGS 88.
Der hier aufgezeigte Weg ist also nicht in allen Fällen notwendig! Beim manuellen Weg aber immer.
Was wird benötigt?
Für den Vorgang benötigt ihr:
- Shell Zugang zur alten Firewall
- Den Storage Master Key der alten Firewall für den Import
- Ein wenig Shell Erfahrung
Wie funktioniert der Lösungsansatz?
Der Ansatz, den ich erarbeitet habe, basiert auf temporäre Veränderungen an den Benutzern in der Datenbank. Diese Änderungen werden im Nachgang wieder komplett rückgängig gemacht.
Generell wird in der Datenbank bei den Benutzern im Feld "authserverid
" der Benutzer der zuletzt verwendete Authentifizierungsserver hinterlegt. Der Wert "1" bedeutet "lokale Datenbank" der Firewall. Andere IDs entsprechen den IDs aus den zusätzlich konfigurierten Authentifizierungsservern.
Diese ID wird durch einen Befehl angepasst auf "1". Der Firewall wird also vorgetäuscht, dass es sich um einen lokalen Benutzer handelt. Und genau dann funktioniert auch der XML-Export aller OTP-Token.
Nach erfolgreichem Export wird die ID wieder auf die vorher gesetzte ID zurückgesetzt und die Tokens können auf einer neuen Firewall eingespielt werden. 😀
Lest bitte alle Anweisungen und Anmerkungen bis zum Ende, um Probleme oder Fragen zu vermeiden.
Umsetzung
Auslesen der nötigen Authentifizierungsserver IDs
Meldet euch in der advanced Shell an und gebt den folgenden Befehl ein, um die IDs der Authentifizierungsserver angezeigt zu bekommen.
psql -U pgroot -d corporate -c "select authservername,authserverid from tbladsauthserver;" -x
Die Ausgabe sieht wie im folgenden Screenshot dargestellt aus. Je nach Menge der Server, ist die Liste länger, oder enthält wie im Screenshot nur einen Eintrag. Notiert euch die ID(s) für welche der Export gemacht werden soll. In den meisten Fällen sollten das alle aufgelisteten sein.

Laufzeitvariable setzen
Die ID(s) speichert ihr jetzt in einer Laufzeitvariable. Dies wird für die weiteren Befehle benötigt.
Passt die ID(s) in dem folgenden Codefenster entsprechend eurer ID(s) an. Ein erneutes Abschicken mit anderen Werten, überschreibt den Wert der Variable - falls ihr die ID(s) noch mal ändern wollt.
# Eine ID
# single ID
authserverids="3"
# Mehrere IDs
# Multiple IDs
authserverids="3,4,5"
Auflisten der jetzt exportierbaren Token (optional)
Wenn ihr euch die Token auflisten lassen wollte welche im Nachgang exportierbar sind müsst ihr diesen Befehl in die Shell eingeben. Seht es als Kontrolle der IDs in der "authserverids" Variable.
if echo "$authserverids" | grep -q ','; then operator="IN (${authserverids})"; else operator="= $authserverids"; fi; psql -U pgroot -d corporate -c "SELECT o.tokenid, o.active, o.userid, u.username, o.comment FROM tblotp o INNER JOIN tbluser u ON o.userid = u.userid WHERE u.authserverid $operator;"
Die Ausgabe sieht dann wie folgt aus. Dabei wird die "tokenid" nur als eindeutiger Identifier mit angezeigt. Die anderen Werte sind selbstredend.

Ist die Anzeige für euch passend, kann mit der nötigen Anpassung fortgefahren werden.
ID auf lokalen Server setzen
Im Folgenden wird die Authentifizierungsquelle der Benutzer auf "lokal" umgestellt. Dabei wird in der Beschreibung der Benutzer auch ein "(-=ID=-)" angefügt, um die Einträge auch in der GUI prüfen zu können. Zusätzlich dient dieser Wert dazu die Änderungen wieder Rückgängig machen zu können. "ID" wird dabei entsprechend der zuletzt gesetzten Server ID angepasst.
IFS=','; for id in $authserverids; do echo "Processing authserverid: $id"; psql -U pgroot -d corporate -c "UPDATE tbluser SET authserverid = 1, description = CONCAT(COALESCE(description, ''), ' (-=$id=-)') WHERE authserverid = $id;"; done
In der Ausgabe kann man sehen wie viele Einträge pro ID angepasst wurden - sprich ob auch was passiert ist.

Im WebAdmin kann geprüft werden, welcher Authentifizierungsserver vorher bei dem Benutzer gesetzt war. Dazu einfach den Benutzer öffnen. Der Wert steht in der Beschreibung: (-=ID=-)

Export der Token
Jetzt kann ein Export der OTP-Token auf gewohnte Weise vorgenommen werden .

Änderungen an der Datenbank rückgängig machen
Jetzt können die Änderungen an der Datenbank wieder rückgängig gemacht werden. Das temporär angefügte "(-=ID=-)" wird auch wieder entfernt.
IFS=','; for id in $authserverids; do echo "Processing ID: $id"; psql -U pgroot -d corporate -c "UPDATE tbluser SET authserverid = $id, description = TRIM(REPLACE(description, ' (-=$id=-)', '')) WHERE description LIKE '%(-=$id=-)%';"; done
Jetzt kann mit dem Import der Token weiter gemacht werden.
Lest dazu bitte noch weiter, da ich hier auch noch interessante und wichtige Hinweise gebe.
Import der Token
Die vorher exportierte XML Datei kann in eine neue Firewall importiert werden. Bitte beachtet dabei aber noch die folgenden Hinweise:
Auch Token der lokalen Datenbank sind enthalten
Der Export enthält unter Umständen mehr Token als euch lieb ist. Es wurden nämlich nicht nur die Token passend zu den externen Authentifizierungsservern exportiert, sondern auch die der lokalen Datenbank. Ist das nicht gewünscht, kann die in der TAR-Datei enthaltene XML-Datei bearbeitet werden. Dazu einfach alle nicht gewünschten <OTPTokens>...</OTPTokens>
Blöcke entfernen. Zum Packen in die TAR-Datei bitte den Punkt "Bearbeitete XML wieder in TAR Datei packen" beachten. Denn nur die TAR-Datei kann importiert werden!
Import der Token zu (noch) nichtexistierenden Benutzern
Die Token sind in der XML einem Benutzernamen zugewiesen. Existiert der Benutzername nicht vor dem Import wird der Token nicht importiert. Dazu gibt es zwei Lösungsansätze:
- Benutzerzuweiseung entfernen
In der XML den Wert<user>Benutzername</user>
auf einen leeren Wert<user></user>
setzen und nach dem Import den Token später im WebAdmin zuweisen in der MFA-Konfiguration. Zum Packen in die TAR-Datei bitte den Punkt "Bearbeitete XML wieder in TAR Datei packen" beachten. Denn nur die TAR-Datei kann importiert werden! - Den Benutzer vorher anlegen
Hier gibt es auch einen Workaround der gut funktioniert ohne das sich der Benutzer tatsächlich anmelden muss. Legt einfach einen Benutzer in der Firewall lokal an. Achtet dabei auf den korrekten Benutzernamen. Mail und Anzeigename werden später automatisch korrigiert. Setzt ein kryptisches Passwort für den Benutzer. Dieses ist später nicht mehr gültig. Der Token kann zu dem Zeitpunkt importiert werden und wird korrekt zugeordnet.
Wenn sich der Benutzer nachher über den externen Authentifizierungsserver anmeldet, wird der Benutzer in einen externen konvertiert. Mail und Anzeigename wird dabei entsprechend der Quelle angepasst. Das vorhin definierte Passwort ist ab hier nicht mehr gültig.
Bearbeitete XML wieder in TAR Datei packen
Beim erneuten Packen der Daten in das TAR-Archiv, müssen alle Dateien, die vorher mit drin waren, auch wieder unbedingt mit rein. Ansonsten schlägt der Import fehl. In das Archiv muss also:
- Entities.xml
- propertyfile
- hashFile.json
Import in neue Firewall
Zum Import sei noch erwähnt, dass ihr den Storage Master Key der alten Firewall eingeben müsst. Ansonsten schlägt der Import fehl.
Hi,
danke für das Tutorial. Hat mir bei der Migration sehr geholfen.
Gruß, Peter
Gerne 🙂