Sophos Firewall Google Workspace OIDC einrichten

Mit SFOS 23.0 kann man Google Workspace als OpenID Connect (OIDC)-Identitätsanbieter für WebAdmin, Captive Portal, VPN Portal sowie Remote Access IPsec und SSL VPN einrichten. Google prüft die Identität; die Firewall ruft zusätzlich die Gruppenmitgliedschaften ab und wendet ihre eigenen Benutzer-, VPN- und Administratorrechte an. Eine erfolgreiche Google-Anmeldung allein gibt deshalb noch keinen Administratorzugang oder Zugriff auf ein internes Netz.

Schnellweg: Einen Google-OAuth-Webclient und ein delegiertes Servicekonto vorbereiten, unter Authentication > Servers einen OpenID Connect-Server mit IdP vendor: Google Workspace erstellen, die dort angezeigten Callback-URLs bei Google hinterlegen, Gruppen importieren und nur die benötigten Dienste unter Authentication > Services umstellen. Danach mit einem Pilotkonto Anmeldung, Rechte und Logs prüfen. Der getestete lokale Notfallzugang bleibt erhalten.

Diese Anleitung beschreibt die SFOS-23-Konfiguration, nicht eine Zusage zu einem bestimmten freigegebenen Firmwarebuild. Vor einem Update gilt die eigene Firmware- und Backup-Planung. Chromebook SSO und Google Directory Sync für Sophos Fusion sind andere Integrationen und ersetzen diesen Firewall-OIDC-Server nicht.

Voraussetzungen und Sicherheitsgrenzen

Zuständigkeiten und bisherige Konfiguration sichern

Erforderlich sind ein Google-Cloud-Projekt, ein Google-Workspace-Konto mit Super Admin-Zugriff für die Einrichtung und ein Firewall-Administrator. Cloud Console verwaltet OAuth-Client, APIs und Servicekonto; Google Admin Console verwaltet Benutzer, Gruppen und Domain-wide delegation.

Vor dem Pilot werden ein Konfigurationsbackup und ein getesteter lokaler Recovery-Zugang vorbereitet. Zusätzlich notiert man die bisherigen Authentifizierungsserver und ihre Reihenfolge je Dienst, Portal-Hostnamen, Device-Access-Freigaben, Gruppen- und VPN-Zuweisungen sowie bestehende Admin-Profile. Eine offene Volladmin-Sitzung bleibt während der Änderung verfügbar; sie ist wegen möglicher Timeouts kein Ersatz für den zweiten Zugang.

Für jede betroffene lokale Identität hält man vor der ersten Pilotanmeldung unter Authentication > Users fest, ob das Konto bereits existiert, sowie seinen bisherigen User type, das zugewiesene Profile und den Kontostatus. Diese Einzelkontenaufnahme gehört zum Prior State: Eine spätere Änderung des IdP-Mappings oder der Google-Rolle setzt bestehende lokale Administratorkonten nicht automatisch zurück.

Für die Rechteplanung gelten weiterhin persönliche Administratoren und Device-Access-Profile. Google-SSO ersetzt weder Least Privilege noch die Beschränkung der Managementquellen.

Einen einheitlichen Hostnamen verwenden

Der Portalname muss zu einer registrierbaren Domain mit öffentlicher TLD gehören. Ein einzelner Name wie firewall oder eine lokale Domain wie firewall.local ist für Google-OAuth-Redirects ungeeignet. Man verwendet denselben FQDN für Portalzugriff, Redirect-URIs und automatische Portalweiterleitungen. DNS-Auflösung und ein zum Namen passendes vertrauenswürdiges HTTPS-Zertifikat werden aus den tatsächlich verwendeten Clientnetzen geprüft.

fw.example.com dient hier nur als Dokumentationsmuster und wird durch den eigenen gültigen FQDN ersetzt. Es ist keine fertige Redirect-URI. Callback-Pfad und Dienstport werden später unverändert aus Show URLs übernommen, nicht aus einem Beispiel zusammengesetzt. Für diesen Ablauf wird auch bei manueller Eingabe ein FQDN verwendet, keine IP-Adresse.

Grenzen vor der Umstellung prüfen

Für jeden Authentifizierungsdienst kann nur ein OIDC-IdP-Server ausgewählt werden. Eine bereits vorhandene Entra-Zuweisung wird deshalb nicht nebenbei ergänzt, sondern bewusst ersetzt oder unverändert belassen.
Für dieselbe Domain können Benutzer nicht gleichzeitig über Active Directory und Google Workspace synchronisiert werden. Vorhandene Benutzer und Gruppen brauchen passende Google-Objekte; nicht zuordenbare Altobjekte werden weiterhin manuell verwaltet.
Firewall-eigene MFA wird für Google-OIDC nicht verwendet. Die MFA-Anforderung wird bei Google konfiguriert und im Pilot tatsächlich geprüft. Lokale Notfallkonten behalten ihren eigenen Schutz.
Im HA-Cluster unterstützt Google-SSO derzeit keine WebAdmin-Anmeldung am Auxiliary-Gerät. Dafür bleibt ein unabhängiger lokaler Managementweg notwendig.
Für Google-SSO mit Sophos Connect sind Windows und Clientversion 2.4 oder neuer vorgesehen. Die macOS-Entra-Unterstützung ist keine Google-Workspace-Freigabe.

Nur wenn Context-Aware Access (CAA) eingesetzt werden soll: Vor dem Pilot prüft man für jeden vorgesehenen Benutzer eine CAA-unterstützte Lizenz/Edition und für die konkrete Anwendung und den Anmeldeablauf die Unterstützung sowie die tatsächliche Zuweisung der gewünschten Policy zur Anwendung und Benutzergruppe/Organisationseinheit. Benutzer mit anderen Editionen unterliegen der CAA-Policy auch dann nicht, wenn dieselbe Gruppe oder Organisationseinheit adressiert wird; Endpoint Verification allein belegt keine CAA-Berechtigung. CAA ist optional und keine Premium-Lizenzvoraussetzung für gewöhnliches Google-OIDC. Google-SAML-Dokumentation belegt keine Unterstützung des Sophos-OIDC-Ablaufs. Vor der Freigabe weist man die gewünschte Wirkung mit frischen positiven und negativen Anmeldetests für die konkrete Anwendung, Benutzer und Bedingungen nach; fehlende Unterstützung oder ein unerwartet erfolgreicher Negativtest blockiert die Freigabe des CAA-geschützten Ablaufs.

Google Workspace vorbereiten

OAuth-Webclient erstellen

In Google Cloud Console > APIs & Services > Credentials das richtige Projekt auswählen. Falls Google zunächst die Konfiguration des OAuth-Zustimmungsbildschirms verlangt, diese für die eigene Organisation und den genehmigten Nutzerkreis abschliessen; keine allgemeine externe Freigabe nur für den Test erstellen.
Create credentials > OAuth client ID öffnen und Application type: Web application auswählen.
Einen nachvollziehbaren Namen vergeben, etwa SFOS-Google-SSO-Pilot, und den Client erstellen.
Client ID und Client secret sofort in einem freigegebenen Secret-Tresor sichern. Das Secret wird nicht in Screenshots, Tickets oder die Change-Dokumentation kopiert.

Die OAuth-Client-ID identifiziert die Firewall bei der Anmeldung. Sie ist nicht die numerische ID des Servicekontos, die später für die Delegation benötigt wird. Die Redirect-URIs werden erst ergänzt, sobald die Firewall sie erzeugt hat.

Servicekonto und Gruppenabfrage einrichten

Die Anmeldung und die Gruppenabfrage verwenden unterschiedliche Zugänge: Der OAuth-Client dient dem interaktiven Login; das Servicekonto erlaubt der Firewall, Google-Directory-Informationen abzurufen. Google liefert Gruppenmitgliedschaften nicht einfach als Teil der normalen OIDC-Anmeldeantwort.

Unter Google Cloud Console > IAM & admin > Service accounts > Create service account ein dediziertes Konto für diese Integration erstellen, beispielsweise sfos-directory-reader.
Keine pauschalen Owner- oder Editor-Rollen als vermeintliche Voraussetzung vergeben. Zusätzliche IAM-Rechte werden nur für eine nachgewiesene Aufgabe genehmigt.
In den Details des Servicekontos die numerische Unique ID notieren.
Unter Keys > Add key > Create new key den Typ JSON wählen. Den heruntergeladenen privaten Schlüssel geschützt für den späteren Upload auf die Firewall bereitstellen und unkontrollierte Downloadkopien vermeiden.
Unter APIs & Services > Library die Admin SDK API suchen und mit Enable aktivieren.

⚠️ Wenn Service account key creation is disabled erscheint, wird die Einrichtung angehalten. Eine Organisationsrichtlinie wird nicht organisationsweit abgeschaltet, um diese Anleitung fortzusetzen. Der Google-Sicherheitsverantwortliche muss eine begrenzte, dokumentierte Ausnahme genehmigen oder die Integration bleibt blockiert. Die hier beschriebene Sophos-Konfiguration benötigt eine JSON-Schlüsseldatei; eine andere Authentifizierungsart wird nicht als ungeprüfter Ersatz behauptet.

Domain-wide delegation begrenzen

Als autorisierter Super Admin Google Admin Console > Security > Access and data control > API controls öffnen.
Unter Domain-wide delegation > Manage domain wide delegation > Add new die Unique ID des Servicekontos als Client ID eintragen, nicht die OAuth-Webclient-ID.
In OAuth scopes (comma-delimited) die beiden benötigten Lesescopes eintragen:

https://www.googleapis.com/auth/admin.directory.group.readonly,https://www.googleapis.com/auth/admin.directory.group.member.readonly

Soll auch WebAdmin über Google authentifiziert werden, zusätzlich diesen Scope aufnehmen:

https://www.googleapis.com/auth/admin.directory.rolemanagement.readonly

Die Delegation mit Authorize speichern und ID sowie vollständige Scopeliste kontrollieren.

Die Scope-URLs sind feste API-Bezeichner, keine Beispielwerte. Ist Multi-party approval aktiv, muss ein weiterer Super Admin die Delegation genehmigen. Änderungen können bis zu 24 Stunden benötigen; in dieser Zeit wird nicht vorschnell eine zweite Delegation mit breiteren Rechten angelegt. Domain-wide delegation erlaubt stellvertretenden Zugriff im Workspace-Mandanten und ist daher trotz Leserechten eine sicherheitsrelevante Freigabe. Servicekonto, Schlüssel-ID, delegiertes Administratorkonto, Zweck und Reviewtermin erhalten einen benannten Owner.

Separate Firewall-Admin-Gruppen vorbereiten

Für den übersichtlichen Einstieg empfiehlt sich Gruppenmapping. Unter Google Admin Console > Directory > Groups eine Gruppe ausschliesslich für Firewall-Administratoren erstellen und nur die Pilotadministratoren hinzufügen. Beispielsweise kann eine Gruppe SFOS-NOC-ReadOnly einem zuvor geprüften Read-only-Profil zugeordnet werden. Name und Gruppenadresse sind eigene Organisationswerte; eine normale Mitarbeiter- oder VPN-Gruppe erhält keine WebAdmin-Rechte.

Alternativ kann man unter Account > Admin roles benutzerdefinierte oder vordefinierte Google-Admin-Rollen zuweisen und im Firewall-Server Roles verwenden. Benutzerdefinierte Rollen werden mit dem exakten Rollennamen zugeordnet; vordefinierte Rollen benötigen ihren speziellen IdP-Wert, nicht einfach die sichtbare Bezeichnung. Ein bestätigtes Beispiel ist Groups admin → _GROUPS_ADMIN_ROLE. Google-Admin-Rollen können zugleich Rechte in Google Admin Console geben. Sie werden deshalb nicht allein als bequemes Firewall-Label vergeben; eine dedizierte Gruppe ist meist die engere Wahl.

OIDC-Server auf der Firewall konfigurieren

Client, Redirects und Endpoints

Den WebAdmin über den geplanten FQDN öffnen und Authentication > Servers > Add aufrufen.
Server type: OpenID Connect, einen eindeutigen Server name und IdP vendor: Google Workspace auswählen.
Client ID und Client secret des OAuth-Webclients eintragen.
Unter Redirect URIs Use firewall URL auswählen. Die Firewall verwendet den Hostnamen aus der aktuellen WebAdmin-URL. Alternativ mit Enter manually den geprüften eigenen FQDN eintragen.
Show URLs öffnen und die vollständigen URLs für Web admin console, Captive portal beziehungsweise VPN portal and remote access der tatsächlich geplanten Dienste kopieren.
Die automatisch gesetzte Issuer URL https://accounts.google.com belassen und Discover/Reset endpoint URLs verwenden. Authorization URL, Token URL, Logout URL, JWKS URL und User info URL werden über Discovery befüllt, nicht geraten.

Identität, Fallback und Admin-Rechte

Unter User attributes unterstützen Display name und Username die Werte name oder email; der dokumentierte Standard ist jeweils name. Email address ist mit email vorbelegt. Die Entscheidung wird vor dem ersten Pilotlogin getroffen: email kann die Zuordnung zu einer eindeutigen Workspace-Anmeldeadresse vereinfachen, muss aber zu bestehenden Firewall-Identitäten passen. Attributwerte werden nicht später beiläufig geändert, weil dadurch andere Kontozuordnungen entstehen können.

Für reine VPN- oder Captive-Portal-Nutzung bleibt IdP authentication for firewall administrators ausgeschaltet. Für WebAdmin wird die Option bewusst eingeschaltet und jede Zuordnung mit IdP attribute, exaktem IdP value und Device access profile angelegt. Gruppen- oder Rollenwerte werden aus der eigenen Google-Konfiguration übernommen, nicht aus dem Beispielnamen geraten.

Die Firewall prüft Mappingregeln von oben nach unten und verwendet das erste passende Profil. Ein Benutzer in mehreren Admin-Gruppen muss deshalb ausdrücklich getestet werden. Ohne passende Admin-Zuordnung erhält die Identität keinen WebAdmin-Zugang und kann als normaler Benutzer angelegt werden.

Unter Fallback group eine bewusst eingeschränkte Benutzergruppe wählen. Existiert die Google-Gruppe nicht auf der Firewall, wird diese Fallbackgruppe verwendet. Auch wenn der Server unter Firewall authentication methods ausgewählt ist, ersetzt Default group diese OIDC-Fallbackzuweisung nicht. Eine breit berechtigte VPN-Gruppe ist kein sicherer Auffangbehälter.

Servicekonto prüfen und Hostnamen angleichen

Unter Service account credentials > Email address die Adresse des Google-Workspace-Super-Administrators eintragen, der für diesen Zugriff vorgesehen ist. Hier gehört nicht die E-Mail-Adresse des Servicekontos hinein.
Unter JSON private key > Browse die geschützte JSON-Schlüsseldatei des dedizierten Servicekontos auswählen.
Test connection ausführen. Der Test prüft Netzwerkverbindung und Anwendungsberechtigungen. Er beweist noch keine korrekte Benutzeranmeldung oder Admin-Zuordnung.
Mit Save speichern.
Über Go to Admin and user settings unter When redirecting users to the captive portal or other interactive pages den identischen Portal-FQDN festlegen: Use the firewall’s configured hostname oder Use a different hostname passend zur eigenen Konfiguration. Mit Apply speichern.
In Google Cloud Console > APIs & Services > Credentials den OAuth-Webclient öffnen und unter Authorized redirect URIs > Add URI jede zuvor kopierte vollständige Callback-URL eintragen. Mit Save speichern und Zeichen für Zeichen vergleichen.

Gruppen, Dienste und VPN freigeben

Gruppen importieren und Policies zuweisen

Unter Authentication > Servers den Assistant for importing groups des Google-Servers öffnen. Man kann alle Gruppen oder gezielt Gruppen anhand von Display name und Mail importieren. Für den Pilot wird nur der benötigte Nutzerkreis gewählt. Im Assistenten können Surfing quota, Access time, Network traffic und Traffic shaping für alle oder einzelne Gruppen zugewiesen werden.

Firewall und Google müssen zeitlich synchron sein, sonst kann schon der Gruppenimport scheitern. Nach dem Import die Gruppennamen und vorgesehenen Policies kontrollieren. Für IPsec oder SSL VPN müssen die neuen Gruppen zusätzlich in die betreffenden VPN-Policies aufgenommen werden. Ein erfolgreicher Import ist noch keine VPN-Berechtigung.

Authentifizierung pro Dienst umstellen

Unter Authentication > Services den Google-Server nur bei den benötigten Methoden auswählen:

Administrator authentication methods: WebAdmin.
Firewall authentication methods: Captive Portal.
VPN portal authentication methods: VPN Portal.
VPN (IPsec/dial-in/L2TP/PPTP) authentication methods: Remote Access IPsec; die Listenbezeichnung ist keine OIDC-Freigabe für jedes darin genannte Legacy-Protokoll.
SSL VPN authentication methods: Remote Access SSL VPN.

Den Server für den gewählten Dienst an den Anfang der Liste ziehen und je Dienst Apply verwenden. Reihenfolge und lokaler Fallback werden gegen den zuvor dokumentierten Zustand geprüft; Local wird für persönliche lokale Administratoren nicht nebenbei entfernt. Nicht benötigte Dienste bleiben unverändert.

Sophos Connect und Erreichbarkeit

Google-SSO verwendet den VPN-Portal-Port auch für die Remote-Access-Kommunikation. Für diesen Einsatz muss unter Administration > Device access > Local service ACL der VPN-Portal-Zugriff aus WAN erlaubt sein. Dabei werden erlaubte Quellen und die tatsächlich benötigte Erreichbarkeit bewusst geplant; WebAdmin wird dafür nicht im WAN geöffnet. Die Begrenzung beschreibt Device Access und Local Service ACL.

Mit einer Provisioning-Datei müssen IPsec, SSL VPN und VPN Portal denselben Google-Server verwenden. Der Wert gateway entspricht dem FQDN, mit dem die Redirects erzeugt wurden. Ohne Provisioning-Datei müssen SSL VPN und VPN Portal ebenfalls denselben Server verwenden; IPsec kann einen anderen Google-Server nutzen. An vorhandenen VPN-Dateien wird deshalb nicht blind nur ein Authentifizierungsfeld geändert.

Nach Einrichtung oder Änderung der Google-Konfiguration müssen Windows-Benutzer ihre Konfigurationsdatei erneut in Sophos Connect 2.4 oder neuer importieren. Erst dann wird eine frische Verbindung getestet. Auf gemeinsam genutzten Endpoints ist für nachfolgende Benutzer ein erneuter SSO-Login zu erzwingen; eine bestehende Google-Sitzung darf nicht unbemerkt die nächste Person anmelden.

Optional: Captive Portal sicher verwenden

Für die entsprechende benutzerbasierte Firewallregel sind Match known users und Use web authentication for unknown users erforderlich. Unter Authentication > Web authentication > Captive portal behavior für diesen Portalablauf Show web page after sign-in aktivieren, In new browser window wählen und Use insecure HTTP instead of HTTPS deaktivieren. Mit Apply speichern; OIDC unterstützt diesen unsicheren HTTP-Modus nicht.

Benutzer lassen das Captive-Portal-Fenster für die explizite Abmeldung offen. Inaktivität oder das Schliessen eines Tabs beendet die Google-SSO-Sitzung hier nicht wie bei anderen Portalmethoden. Nach der Abmeldung bleibt die Google-Abmeldeseite sichtbar. Credential login mit Benutzername und Passwort ist kein Ersatz für diesen tokenbasierten Google-OIDC-Ablauf.

Anmeldung und Berechtigungen abnehmen

Die Abnahme trennt Verbindung, Identität und Autorisierung. Alle Tests werden mit Zeitpunkt, Konto, Dienst, Clientversion und erwartetem Ergebnis protokolliert, ohne Secrets oder Tokens mitzuschreiben.

Test connection und gezielten Gruppenimport erfolgreich abschliessen. Danach ein privates Browserfenster über den vorgesehenen FQDN öffnen.
Einen Pilotadministrator über Google anmelden und die erwartete MFA-Anforderung kontrollieren. Unter Authentication > Users müssen Identität, Administratorstatus und zugewiesenes Profil stimmen.
Benötigte Menüs positiv prüfen und einen gesperrten Bereich negativ prüfen. Ein Read-only-Konto darf keine Änderung speichern. Ein normales VPN-Konto darf sich nicht am WebAdmin anmelden.
Ein Konto mit mehreren Mappingtreffern prüfen. Das Profil muss zur dokumentierten ersten passenden Regel gehören, nicht zur vermeintlich stärksten Rolle.
Separat am VPN Portal anmelden und mit der neu importierten Sophos-Connect-Konfiguration einen IPsec- beziehungsweise SSL-VPN-Tunnel aufbauen. Eine genehmigte interne Ressource muss erreichbar sein; eine nicht freigegebene Ressource muss gesperrt bleiben.
Abmelden und mit einer neuen Sitzung erneut prüfen. Google-Login, Portalzugang und VPN-Tunnel sind getrennte Erfolgskriterien.
Im Log viewer > Admin die WebAdmin-Ereignisse und im Log viewer > Authentication Captive-Portal-, VPN-Portal-, IPsec- und SSL-VPN-Anmeldungen korrelieren. Für weitergehende Analyse steht in der Advanced Shell oauth_sso_svc.log zur Verfügung; Debug- oder Neustartbefehle werden dafür nicht vorausgesetzt.
Den unabhängigen lokalen Recovery-Zugang erneut prüfen, bevor weitere Nutzer migriert werden.

Admin-Konten werden nur bei erfolgreicher WebAdmin-Anmeldung erstellt oder aktualisiert. Ein VPN- oder Captive-Portal-Login synchronisiert keine Administratorrolle. Google-Rollenänderungen werden daher mit einer neuen WebAdmin-Anmeldung abgenommen, nicht anhand eines erfolgreichen Tunnels.

Fehler gezielt eingrenzen

Google meldet redirect_uri_mismatch

Die betroffene vollständige URL aus Show URLs mit Authorized redirect URIs des tatsächlich verwendeten OAuth-Clients vergleichen: Schema, FQDN, Port und Pfad müssen exakt passen. Danach prüfen, ob der Browser denselben Hostnamen verwendet und die automatische Portalweiterleitung auf diesen Namen zeigt. Nach der Korrektur eine frische Anmeldung testen; weder Wildcard-Redirects noch ein Wechsel auf IP sind die Lösung.

Test connection oder Gruppenimport scheitert

Zuerst Systemzeit und Netzwerkverbindung prüfen. Danach Admin SDK API, gültige JSON-Schlüsseldatei, korrektes delegiertes Super-Admin-Konto sowie Domain-wide delegation mit der numerischen Servicekonto-ID und den erforderlichen Scopes vergleichen. Bei fehlenden Gruppen zusätzlich den Importfilter Display name/Mail kontrollieren. Ein Fehler wird nicht durch pauschale Cloud-Owner-Rechte oder zusätzliche Schreibscopes behandelt.

Gruppenmitgliedschaft beziehungsweise Rollenzuweisung bei Google, IdP authentication for firewall administrators, exakten IdP value, Mappingreihenfolge und lokales Device access profile kontrollieren. Danach eine neue WebAdmin-Anmeldung ausführen und Log viewer > Admin prüfen. Eine vorherige VPN-Anmeldung beweist weder das Mapping noch die Aktualisierung des Administrators.

Portal funktioniert, Tunnel oder interne Ressource nicht

Windows- und Sophos-Connect-Version, neu importierte Konfigurationsdatei, VPN-Portal-Erreichbarkeit und die Serverzuordnung pro Dienst prüfen. Danach Gruppenmitgliedschaft in den VPN-Policies und die Regeln für die Zielressource kontrollieren. Log viewer > Authentication zeigt die Anmeldung; ein erfolgreicher Authentifizierungseintrag allein beweist keinen erlaubten Datenverkehr.

Context-Aware Access oder erneute Anmeldung wirkt anders als erwartet

Gerätebasierte Google-CAA-Bedingungen benötigen einen unterstützten Browserablauf und tatsächlich verfügbare Endpoint-Verifikationsdaten. Für den beschriebenen Prüfweg wird Google Chrome mit Endpoint Verification verwendet. Ein erfolgreicher Sophos-Connect-Login wird nicht als Nachweis betrachtet, dass jede gerätebasierte CAA-Bedingung ausgewertet wurde.

CAA wird bei der Authentifizierung ausgewertet und beendet keine bereits aktive Firewall-Sitzung. Auch Googles Reauthentifizierungsintervall erzwingt keine erneute Anmeldung einer aktiven Firewall-VPN-Sitzung. Man prüft eine neue Authentifizierung nach kontrolliertem Abmelden beziehungsweise Trennen; bestehende Sitzungen müssen beim Offboarding separat behandelt werden.

Betrieb, Offboarding und Rückweg

Eine Änderung an Gruppen oder Rollen wird mit frischer Anmeldung und Positiv-/Negativtest geprüft. Beim Entfernen einer Person aus der Administration reicht die Google-Rollenänderung allein nicht: SFOS wandelt ein vorhandenes Administratorkonto nicht automatisch in einen normalen Benutzer zurück. Nach Prüfung der Abhängigkeiten und mit einem anderen funktionierenden Administrator muss das betreffende Administratorkonto auf der Firewall gelöscht werden. Bei der nächsten normalen Anmeldung kann die Firewall den Benutzer neu erstellen. Aktive WebAdmin- und VPN-Sitzungen werden separat kontrolliert und beendet; ein Gruppenentzug ist kein nachgewiesener sofortiger Session-Widerruf.

Für OAuth-Secret und Servicekonto-Schlüssel werden Owner, sicherer Speicher, Review und Rotation festgelegt. Bei einer geplanten Rotation bleibt der alte Schlüssel nur so lange verfügbar, wie der dokumentierte Rückweg es erfordert. Die neuen Credentials werden zuerst mit Test connection, Gruppenabruf und frischer Anmeldung geprüft, bevor alte Credentials widerrufen werden. Eine Kompromittierung wird dagegen nach dem eigenen Incident-Prozess behandelt, nicht zugunsten eines bequemen Rollbacks verlängert.

Bei einem fehlgeschlagenen Pilot wird aus der offenen Volladmin-Sitzung oder dem lokalen Recovery-Zugang die exakt notierte vorherige Dienstzuordnung und Serverreihenfolge wiederhergestellt. Ebenso werden geänderte Portal-Hostnamen, Device Access, Gruppen-/VPN-Policies und Admin-Mappings auf ihren jeweiligen Prior State zurückgesetzt. Danach lokale Admin-Anmeldung und der bisherige VPN-Weg in neuen Sitzungen testen.

Zusätzlich gleicht man über den unabhängig verfügbaren Volladmin-Zugang jedes betroffene Konto unter Authentication > Users mit der Einzelkontenaufnahme ab. Bei bereits vorhandenen Konten stellt man den bisherigen User type, das zugewiesene Profile und den Kontostatus ausdrücklich wieder her; falls dafür ein Löschen und Neuerstellen nötig ist, prüft man zuvor alle Abhängigkeiten und sichert die bisherigen Zuweisungen. Nur im Pilot neu erzeugte Admin-/Benutzerobjekte entfernt man nach Prüfung ihrer Gruppen-, VPN-, Policy- und sonstigen Abhängigkeiten. Ein zurückgesetztes Server-Mapping oder eine entfernte Google-Rolle ersetzt diese Kontobereinigung nicht und beendet keine bestehende Sitzung. Aktive WebAdmin-, Portal- und VPN-Sitzungen werden deshalb separat geprüft und beendet. Abschliessend weist man in frischen Sitzungen den bisherigen lokalen Admin- und VPN-Zugang sowie die Ablehnung einer nicht mehr berechtigten Pilotidentität nach; bei wiederhergestellten Bestandskonten prüft man die ursprünglichen Rechte und die Ablehnung der nur im Pilot gewährten Zusatzrechte.

Erst wenn der Rückweg funktioniert und keine anderen Dienste abhängen, werden die nur für den Pilot erzeugten Redirect-URIs, Delegationsfreigaben und Credentials kontrolliert entfernt. Geteilte Clients oder Servicekonten werden nicht ohne Abhängigkeitsprüfung gelöscht. Ein vollständiges Konfigurationsbackup wird nur im genehmigten Recovery-Fenster eingespielt, weil es auch unabhängige Firewall-Änderungen zurücksetzen kann.