Sophos Firewall: eDirectory vor SFOS 23 migrieren

SFOS 23.0 unterstützt den nativen eDirectory-Authentifizierungsserver nicht mehr. Bleibt eine native eDirectory-Serverkonfiguration auf der Firewall bestehen, schlägt das Firmware-Upgrade auf SFOS 23.0 oder neuer fehl. Vor dem Upgrade muss daher ein unterstützter Authentifizierungsserver funktionieren und die native eDirectory-Server- und SSO-Konfiguration vollständig entfernt sein.

In SFOS 22.0 MR2 funktioniert eDirectory noch. Diese Zeit sollte man für einen kontrollierten Parallelbetrieb nutzen: neue Quelle hinzufügen, Benutzer und Gruppen mit echten Konten prüfen, die Authentifizierungsdienste kontrolliert umstellen und eDirectory erst löschen, wenn der Rückweg nicht mehr benötigt wird. Gekoppelte Entra-ID-SSO-Dienste werden dabei gemeinsam behandelt. Der MR2-Überblick ordnet die übrigen Änderungen dieser Version ein.

Kurzablauf

Alle eDirectory-Abhängigkeiten in Servern, Gruppen, Diensten, Regeln, VPN und SSO erfassen.
Ein aktuelles Backup, einen lokalen Administrator und einen dokumentierten Konsolenzugang vorbereiten.
Als Ziel je nach Einsatz generisches LDAP, Active Directory, RADIUS oder Microsoft Entra ID SSO wählen.
Den neuen Authentifizierungsserver parallel anlegen und Verbindung, Benutzer sowie Gruppen prüfen.
Gruppen und Policies bewusst auf die neue Quelle abbilden.
Unter Authentication > Services die Dienste kontrolliert umstellen und mit echten Konten testen; gekoppelte Entra-ID-SSO-Dienste gemeinsam behandeln.
Erst nach der vollständigen Abnahme alle nativen eDirectory-Server- und SSO-Konfigurationen löschen, erneut sichern und das SFOS-23-Upgrade starten.

Das ist bewusst kein Wechsel mit einem einzigen Schalter. Die Firewall verwendet Authentifizierungsserver pro Dienst und in einer festgelegten Reihenfolge. Zudem hängen Berechtigungen häufig an Gruppen, die nach dem Wechsel zwar gleich heissen können, aber nicht automatisch dieselbe Zuordnung und Wirkung besitzen.

Was heute an eDirectory hängt

Vor der ersten Änderung muss klar sein, wo eDirectory tatsächlich verwendet wird. Mindestens diese Bereiche gehören in die Inventur:

Unter Authentication > Servers stehen die eDirectory-Server und gegebenenfalls mehrere Verzeichnisziele.
Unter Authentication > Services ist pro Dienst festgelegt, welche Server in welcher Reihenfolge abgefragt werden.
Unter Authentication > Groups können Gruppenrichtlinien, Default Group und Gruppenreihenfolge die effektiven Rechte eines Benutzers bestimmen. Bei Active Directory kommen Main Group und weitere Mitgliedschaften hinzu.
Firewall-Regeln, Web- und Application-Policies sowie Traffic-Shaping können Benutzer oder Gruppen referenzieren.
VPN Portal, SSL VPN, Remote Access IPsec, User Portal und Captive Portal besitzen eigene Anmelde- und Berechtigungspfade.
MFA und administrative Anmeldungen können von Gruppen und Authentifizierungsreihenfolge abhängen.
Benutzerbasierte Reports und transparente Benutzererkennung benötigen weiterhin eine verlässliche Zuordnung zwischen Benutzer und Verbindung.

Ein Screenshot der heutigen Server-, Service- und Gruppenreihenfolge ist dabei oft hilfreicher als eine reine Namensliste. Ergänzend sollte man zu jeder wichtigen Gruppe mindestens einen positiven und einen negativen Testbenutzer notieren. So lässt sich später nicht nur prüfen, wer Zugang erhält, sondern auch, wer korrekt abgewiesen wird.

Passende Zielmethode wählen

Es gibt keinen universellen 1:1-Ersatz für jede eDirectory-Umgebung. Ein Unternehmen kann das bestehende Verzeichnis per LDAP weiterverwenden, Identitäten in ein anderes Verzeichnis migrieren oder je nach Dienst mehrere Authentifizierungsmethoden kombinieren.

Bestehendes eDirectory über generisches LDAP

Wenn das eDirectory selbst bestehen bleibt, kann Sophos Firewall es über den unterstützten Servertyp LDAP server für Benutzeranmeldungen abfragen. Dieser Weg verändert nicht automatisch den Verzeichnisbaum, verlangt aber eine neue LDAP-Konfiguration mit passender Base DN, Login- und Gruppenattributen.

Wichtig ist die Grenze: Natives eDirectory-SSO steht ab SFOS 23 nicht mehr zur Verfügung. Der generische LDAP-Server übernimmt die Anmeldeprüfung, aber nicht die transparente Benutzererkennung. Benutzer, die zuvor automatisch erkannt wurden, benötigen deshalb einen neuen SSO- oder Anmeldeablauf. Die vollständige Feldbeschreibung steht unter Generischen LDAP-Server mit Sophos Firewall verbinden.

Active Directory

Active Directory passt, wenn die Benutzer bereits in einer Windows-Domäne vorhanden sind oder bewusst dorthin migriert werden. Dann müssen Gruppen importiert, Main Group und Policies neu geprüft und eine gewünschte transparente Benutzererkennung separat aufgebaut werden. Active Directory mit Sophos Firewall verbinden erklärt LDAPS, Gruppenimport und die Diensttests.

STAS meldet Windows-Domänenanmeldungen transparent an die Firewall; es wandelt die bisherige eDirectory-SSO-Konfiguration jedoch nicht um. Wer diesen Identitätsweg benötigt, plant ihn mit STAS für Sophos Firewall als separate Migration.

RADIUS

RADIUS eignet sich, wenn bereits ein zentraler Authentifizierungsdienst oder ein MFA-Gateway vorhanden ist. Der RADIUS-Server muss der Firewall die für den jeweiligen Dienst benötigten Informationen liefern; ein Verzeichnisgruppenmodell wird dadurch nicht automatisch übernommen. Die MFA-Methode muss zum Dienst passen: Das VPN Portal unterstützt beispielsweise kein challenge-basiertes RADIUS-MFA. Shared Secret, Gruppenattribut, Timeouts und weitere Grenzen werden in Sophos Firewall RADIUS-Server einrichten behandelt.

Microsoft Entra ID SSO

Microsoft Entra ID SSO kann für dokumentierte Portal-, Administrator- und Remote-Access-Szenarien sinnvoll sein. Es ist jedoch kein allgemeiner Ersatz für jede Benutzername-Passwort-Abfrage und keine transparente LAN-Benutzererkennung. Bei Remote Access müssen zusammengehörende Dienste koordiniert werden: VPN Portal und SSL VPN verwenden denselben Entra-Server; bei einer Provisioning-Datei gilt dies zusätzlich für IPsec. Redirect URIs, Gruppen, Conditional Access und die unterstützten Dienste sind unter Microsoft Entra ID SSO für Sophos Connect und VPN Portal beschrieben.

Die Zielarchitektur darf gemischt sein. Beispielsweise kann LDAP vorerst Benutzer aus dem bestehenden eDirectory authentifizieren, während Remote Access später gezielt auf RADIUS oder Entra ID SSO umgestellt wird. Entscheidend ist, dass jeder verwendete Dienst einen getesteten Zielpfad besitzt, bevor eDirectory gelöscht wird.

Vor der ersten Änderung absichern

Vor dem Cutover sollten folgende Punkte bereitstehen:

Ein aktuelles, verschlüsseltes Sophos-Firewall-Backup.
Ein lokaler Administrator, dessen Anmeldung nicht von eDirectory oder der neuen externen Quelle abhängt. Unter Authentication > Services muss Local bei den Administrator authentication methods weiterhin ausgewählt sein.
Ein dokumentierter Konsolen- oder anderer Notfallzugang zur Firewall.
Screenshots oder eine schriftliche Inventur der Server-, Service- und Gruppenreihenfolge.
Mindestens ein Testkonto pro wichtiger Gruppe sowie ein Konto, das keinen Zugriff erhalten darf.
Ein Wartungsfenster, ein verantwortlicher Entscheider und ein klares Rückfallkriterium.

Den WebAdmin-Zugang stellt man zuletzt um. Vorher wird geprüft, dass Local weiterhin ausgewählt ist und die lokale Anmeldung in einem privaten Browserfenster funktioniert. Damit bleibt ein unabhängiger Zugang erhalten, falls die neue externe Authentifizierung oder ihre Gruppenauflösung nicht wie erwartet funktioniert.

Zielserver parallel aufbauen

Der neue Server wird zuerst zusätzlich angelegt. Während des initialen Serveraufbaus bleibt die bestehende eDirectory-Auswahl unverändert; erst für den Pilottest wird genau eine kontrollierbare Authentifizierungsmethode geändert.

Beispiel: eDirectory als generischen LDAP-Server anbinden

Unter Authentication > Servers > Add könnte eine Pilotkonfiguration beispielsweise so aussehen:

Server type: LDAP server
Server name: EDIR-LDAP-PILOT
Server IP/domain: edir01.example.net
Version: 3
Connection security: SSL/TLS
Port: 636
Bind DN: cn=sfos-bind,ou=service,o=Example
Base DN: ou=users,o=Example
Authentication attribute: zum Beispiel uid, nach Prüfung des Benutzerobjekts
Group name attribute: zum Beispiel groupMembership, nach Prüfung des Benutzerobjekts
Validate server certificate: aktiviert, nachdem die ausstellende CA auf der Firewall als vertrauenswürdig eingerichtet wurde

edir01.example.net, Bind DN und Base DN sind Beispielwerte und müssen zum eigenen Verzeichnisbaum passen. Bei aktivierter Zertifikatsvalidierung muss der konfigurierte FQDN zum Serverzertifikat passen und für die Firewall auflösbar sein. Das Bind-Konto benötigt nur Leserechte auf den benötigten Verzeichnisbereich.

Welche Login- und Gruppenattribute passen, bestimmt das reale Benutzerobjekt. In einer eDirectory-Umgebung können beispielsweise cn oder uid für die Anmeldung und groupMembership für Gruppen relevant sein. Das sind Prüfkandidaten und keine universellen Vorgaben.

Von einem Linux-Administrationssystem lässt sich ein Benutzerobjekt read-only prüfen:

LDAPTLS_CACERT='/secure/path/edir-ca.pem' \
ldapsearch -LLL -x \
  -H 'ldaps://edir01.example.net:636' \
  -D 'cn=sfos-bind,ou=service,o=Example' -W \
  -b 'ou=users,o=Example' -s sub \
  '(|(cn=max.muster)(uid=max.muster))' \
  dn objectClass cn uid mail groupMembership

Der Befehl gehört nicht in die Advanced Shell der Sophos Firewall. -W fragt das Bind-Passwort interaktiv ab, damit es nicht in der Shell-History steht. Der Pfad bei LDAPTLS_CACERT, der FQDN, die DNs, der Filter und die angeforderten Attribute müssen an die eigene Umgebung angepasst werden. Vertraut der lokale OpenLDAP-Client der CA bereits über seinen Trust Store oder ldap.conf, kann LDAPTLS_CACERT entfallen. Andernfalls verweist die Variable auf ein lesbares PEM-CA-Bundle.

Eine mögliche Ausgabe könnte so aussehen:

dn: cn=Max Muster,ou=users,o=Example
cn: Max Muster
uid: max.muster
mail: max.muster@example.net
groupMembership: cn=VPN-Mitarbeitende,ou=groups,o=Example

Das ist ein Lesebeispiel, kein versprochenes eDirectory-Schema. Fehlt groupMembership oder liefert das Verzeichnis andere Werte, wird das tatsächliche Attribut ermittelt und die Firewall-Konfiguration daran angepasst. Danach werden Test connection, ein echter Benutzerlogin und die resultierende Gruppe separat geprüft.

Gruppen und Policies neu abbilden

Ein erfolgreicher Login reicht nicht, wenn der Benutzer danach in der falschen Gruppe landet. Angenommen, die bisherige Gruppe VPN-Mitarbeitende darf SSL VPN verwenden und erreicht über eine Benutzerregel interne Anwendungen. Nach dem Wechsel müssen mindestens diese Fragen beantwortet werden:

Erscheint der Testbenutzer unter Authentication > Users mit der erwarteten wirksamen Gruppe? Bei Active Directory werden Main Group und weitere Mitgliedschaften getrennt geprüft.
Ist die neue Gruppe unter Authentication > Groups vorhanden und richtig eingeordnet?
Verweist die SSL-VPN- oder IPsec-Konfiguration auf die neue wirksame Gruppe?
Trifft der Benutzer weiterhin die vorgesehene Firewall-Regel und nicht eine allgemeinere Regel?
Greift die gewünschte MFA-Richtlinie weiterhin?

Gleiche sichtbare Gruppennamen aus zwei Quellen garantieren weder dieselbe Mitgliedschaft noch dieselbe wirksame Gruppenpriorität. Bei Active Directory können Gruppenreihenfolge und Main Group VPN, MFA und andere Richtlinien beeinflussen. Die Grundlagen dazu stehen unter MFA für Sophos Firewall aktivieren.

Dienst für Dienst umstellen

Unter Authentication > Services werden Authentifizierungsserver dienstbezogen ausgewählt. Deshalb wird nicht alles gleichzeitig umgestellt. Gekoppelte Entra-ID-SSO-Dienste werden jedoch als zusammengehörender Pfad geplant und gemeinsam abgenommen.

Zuerst einen kontrollierbaren Dienst und einen Pilotbenutzer wählen.
Den neuen Server für diesen Dienst auswählen und seine Position in der Serverreihenfolge bewusst festlegen.
Die Änderung anwenden und einen korrekten sowie einen absichtlich falschen Login testen.
Benutzer, Gruppe, Logeintrag und die tatsächlich getroffene Policy kontrollieren.
Erst danach den nächsten Dienst umstellen.

Man beginnt mit einem bewusst gewählten, gut kontrollierbaren Pilotdienst. Danach folgen die tatsächlich genutzten Bereiche wie Firewall authentication methods, User portal authentication methods, VPN portal authentication methods, SSL VPN authentication methods und Remote Access IPsec. Bei Entra ID SSO werden die oben beschriebenen gekoppelten Remote-Access-Dienste koordiniert umgestellt. Die Administrator authentication methods folgen wegen des Lockout-Risikos zuletzt. Welche Portale getrennt funktionieren und erreichbar sein müssen, erklärt die Übersicht der Sophos-Firewall-Portale.

Wenn derselbe Benutzername auf dem alten und neuen Server existiert, kann die Serverreihenfolge ein fehlerhaftes Gruppenmapping verdecken. Für einen kontrollierten Test kann man beim gewählten Pilotdienst vorübergehend nur den neuen Server auswählen. Danach zeigen der reale Login und Authentication > Users, ob die neue Quelle den Benutzer mit der erwarteten Gruppe liefert.

Mit echten Verbindungen abnehmen

Test connection bestätigt Erreichbarkeit und Zugangsdaten des Servers. Die Prüfung endet aber erst, wenn der reale Dienst und die daran gebundene Berechtigung funktionieren.

Für jede relevante Gruppe sollte die Abnahme mindestens zeigen:

Ein berechtigter Benutzer kann sich am vorgesehenen Portal oder VPN-Dienst anmelden.
Ein nicht berechtigter Benutzer wird abgewiesen oder erhält nur die vorgesehene eingeschränkte Policy.
Unter Authentication > Users stimmen Benutzer und Gruppe.
Der Log Viewer zeigt ein nachvollziehbares Authentifizierungsereignis.
Firewall-, Web- und VPN-Policies treffen die erwartete Regel.
Interne Ziele sind über den vorgesehenen Trafficpfad erreichbar.
MFA und administrative Rollen verhalten sich wie geplant.

Mit Firewall Rule Testing und Log Viewer lässt sich prüfen, welche Rule ID für einen Benutzer und seinen Traffic greift. Transparente Benutzererkennung beziehungsweise SSO wird separat getestet; ein erfolgreicher LDAP-Login bestätigt diesen Pfad nicht.

Rückweg während der Pilotphase

Solange die Firewall noch SFOS 22.0 MR2 verwendet und eDirectory nicht gelöscht wurde, bleibt die alte Konfiguration als kontrollierter Rückweg erhalten. Scheitert ein Pilot, werden alle dafür geänderten Werte zurückgesetzt: Serverauswahl und Reihenfolge unter Authentication > Services, Default Group und Gruppenreihenfolge sowie betroffene VPN-Mitglieder, MFA- und Policy-Referenzen. Anschliessend werden Login, Gruppe und Policy erneut geprüft.

Das Backup schützt die Firewall-Konfiguration, ist aber keine automatische Identitätsmigration. Backup und Konfigurationsimport konvertieren oder migrieren die enthaltene eDirectory-Konfiguration nicht. Ein solches Backup ist daher kein funktionierender eDirectory-Rückweg nach dem Upgrade.

eDirectory entfernen und SFOS 23 freigeben

eDirectory wird erst nach einem vorab definierten Beobachtungszeitraum entfernt. In dieser Zeit müssen jeder produktiv genutzte Anmeldeweg, jede wichtige Gruppe, die verwendeten VPN-Verbindungen und die administrativen Abläufe unter realistischen Bedingungen mindestens einmal fehlerfrei über die neue Quelle funktioniert haben; ungeklärte Authentifizierungs-, Gruppen- oder Policy-Fehler verhindern die Löschfreigabe.

Zum Abschluss:

Prüfen, dass eDirectory in keiner Authentifizierungsmethode mehr ausgewählt ist.
Gruppen-, VPN-, Policy-, MFA-, Administrator- und SSO-Abhängigkeiten nochmals mit der Inventur vergleichen.
Alle nativen eDirectory-Server- und eDirectory-SSO-Konfigurationen von der Firewall löschen. Ein neu angelegter generischer LDAP server, der dasselbe Verzeichnis abfragt, bleibt bestehen.
Unter Authentication > Servers, Authentication > Services und in der Inventur verifizieren, dass keine native eDirectory-Konfiguration oder Abhängigkeit übrig ist.
Ein neues verschlüsseltes Backup der bereinigten Konfiguration erstellen.
Die allgemeine Anleitung Sophos Firewall Firmware Update: Vorbereitung und Best Practices sowie die aktuellen SFOS-23-Release-, Upgrade- und Known-Issue-Hinweise prüfen. Erst danach das Upgrade starten.

Der Upgradefehler bei vorhandener nativer eDirectory-Serverkonfiguration und die notwendige Entfernung vor SFOS 23 sind durch Sophos bestätigt. Vor dem produktiven Upgrade werden zusätzlich die endgültigen SFOS-23-Release-, Upgrade- und Known-Issue-Hinweise auf weitere Details geprüft.

Typische Stolperstellen

Test connection ist erfolgreich, der Benutzer landet aber in der falschen Gruppe: Base DN, Login- und Gruppenattribut am realen Benutzerobjekt sowie Gruppenreihenfolge prüfen.
Der Pilot scheint zu funktionieren, könnte aber noch eDirectory verwenden: Beim kontrollierten Pilotdienst vorübergehend nur den neuen Server auswählen und danach Benutzer, Gruppe und Policy prüfen.
User Portal funktioniert, VPN aber nicht: Die Authentifizierungsmethode und Berechtigungsgruppe für jeden Portal- und VPN-Dienst separat prüfen.
LDAP-Anmeldung funktioniert, transparente Erkennung aber nicht: Natives eDirectory-SSO steht ab SFOS 23 nicht mehr zur Verfügung. Generisches LDAP prüft die Anmeldung, übernimmt aber keine transparente Benutzererkennung.
Nach dem Gruppenwechsel trifft eine andere Firewall-Regel: Wirksame Gruppe, Gruppenreihenfolge und direkte Benutzer- oder Gruppenreferenzen in den Policies vergleichen. Bei Active Directory zusätzlich Main Group und weitere Mitgliedschaften prüfen.
Das Backup wird als späterer eDirectory-Rückweg eingeplant: Auf SFOS 23 wird die enthaltene eDirectory-Konfiguration nicht migriert; der Rückweg muss vor dem Upgrade funktionieren.