Konfigurera Google Workspace OIDC på Sophos Firewall

Med SFOS 23.0 kan Google Workspace konfigureras som identitetsleverantör för OpenID Connect (OIDC) för WebAdmin, Captive Portal, VPN Portal samt Remote Access IPsec och SSL VPN. Google verifierar identiteten; brandväggen hämtar dessutom gruppmedlemskap och tillämpar sina egna användar-, VPN- och administratörsbehörigheter. En lyckad Google-inloggning ger därför inte i sig administratörsåtkomst eller åtkomst till ett internt nätverk.

Snabbväg: Förbered en Google OAuth-webbklient och ett delegerat tjänstekonto, skapa en OpenID Connect-server med IdP vendor: Google Workspace under Authentication > Servers, registrera de callback-URL:er som visas där hos Google, importera grupper och ändra endast de tjänster som behövs under Authentication > Services. Kontrollera därefter inloggning, behörigheter och loggar med ett pilotkonto. Den testade lokala nödåtkomsten behålls.

Den här guiden beskriver konfigurationen i SFOS 23 och är inte ett löfte om någon viss godkänd firmwareversion. Inför en uppdatering gäller den egna planeringen för firmware och säkerhetskopiering. Chromebook SSO och Google Directory Sync för Sophos Fusion är andra integrationer och ersätter inte denna OIDC-server på brandväggen.

Förutsättningar och säkerhetsgränser

Säkra ansvarsfördelningen och den befintliga konfigurationen

Det krävs ett Google Cloud-projekt, ett Google Workspace-konto med Super Admin-åtkomst för konfigurationen samt en brandväggsadministratör. Cloud Console hanterar OAuth-klienten, API:er och tjänstekontot; Google Admin Console hanterar användare, grupper och domänomfattande delegering.

Inför piloten förbereds en konfigurationsbackup och en testad lokal återställningsåtkomst. Dokumentera dessutom de befintliga autentiseringsservrarna och deras ordning för varje tjänst, portalernas värdnamn, tillåten åtkomst i Device Access, grupp- och VPN-tilldelningar samt befintliga administratörsprofiler. En session med fullständiga administratörsbehörigheter hålls öppen under ändringen; på grund av möjliga tidsgränser ersätter den inte den andra åtkomstvägen.

För varje berörd lokal identitet dokumenteras före den första pilotinloggningen under Authentication > Users om kontot redan finns, dess tidigare User type, tilldelade Profile och kontostatus. Denna dokumentation för varje enskilt konto ingår i det dokumenterade tidigare tillståndet: en senare ändring av IdP-mappningen eller Google-rollen återställer inte automatiskt befintliga lokala administratörskonton.

För behörighetsplaneringen gäller fortfarande personliga administratörer och Device Access-profiler. Google SSO ersätter varken principen om minsta möjliga behörighet eller begränsningen av vilka källor som får åtkomst till administrationen.

Använd ett enhetligt värdnamn

Portalnamnet måste tillhöra en registrerbar domän med en offentlig toppdomän. Ett enskilt namn som firewall eller en lokal domän som firewall.local är olämpligt för Google OAuth-omdirigeringar. Använd samma FQDN för portalåtkomst, omdirigerings-URI:er och automatiska portalomdirigeringar. Kontrollera DNS-upplösningen och ett betrott HTTPS-certifikat som matchar namnet från de klientnätverk som faktiskt används.

fw.example.com används här endast som dokumentationsexempel och ersätts med det egna giltiga FQDN:et. Det är inte en färdig omdirigerings-URI. Callback-sökväg och tjänsteport hämtas senare oförändrade från Show URLs och sätts inte ihop utifrån ett exempel. För detta förfarande används ett FQDN även vid manuell inmatning, inte en IP-adress.

Kontrollera begränsningarna före omställningen

Endast en OIDC-IdP-server kan väljas för varje autentiseringstjänst. En befintlig Entra-tilldelning kompletteras därför inte bara, utan ersätts medvetet eller lämnas oförändrad.
Användare för samma domän kan inte synkroniseras via både Active Directory och Google Workspace samtidigt. Befintliga användare och grupper behöver motsvarande Google-objekt; äldre objekt som inte kan matchas hanteras även fortsättningsvis manuellt.
Brandväggens egen MFA används inte för Google OIDC. MFA-kravet konfigureras hos Google och kontrolleras i praktiken under piloten. Lokala nödkonton behåller sitt eget skydd.
I ett HA-kluster stöder Google SSO för närvarande inte WebAdmin-inloggning på den sekundära enheten. För detta måste en oberoende lokal administrationsväg finnas kvar.
För Google SSO med Sophos Connect förutsätts Windows och klientversion 2.4 eller senare. Stödet för Entra på macOS innebär inte att Google Workspace stöds.

Endast om Context-Aware Access (CAA) ska användas: Före piloten kontrolleras att varje avsedd användare har en licens eller utgåva som stöder CAA, att den konkreta applikationen och inloggningsflödet stöds samt att den önskade policyn faktiskt är tilldelad applikationen och användargruppen eller organisationsenheten. Användare med andra utgåvor omfattas inte av CAA-policyn, även om samma grupp eller organisationsenhet anges; Endpoint Verification i sig bevisar inte att användaren har rätt att använda CAA. CAA är valfritt och innebär inget krav på premiumlicens för vanlig Google OIDC. Googles SAML-dokumentation bevisar inte att Sophos OIDC-flöde stöds. Före godkännandet verifieras den önskade effekten med nya positiva och negativa inloggningstester för den konkreta applikationen, användarna och villkoren. Om stöd saknas eller ett negativt test oväntat lyckas får det CAA-skyddade flödet inte godkännas.

Förbered Google Workspace

Skapa en OAuth-webbklient

Välj rätt projekt i Google Cloud Console > APIs & Services > Credentials. Om Google först kräver att skärmen för OAuth-samtycke konfigureras, slutför detta för den egna organisationen och den godkända användarkretsen; skapa inte ett allmänt externt godkännande enbart för testet.
Öppna Create credentials > OAuth client ID och välj Application type: Web application.
Ange ett tydligt namn, till exempel SFOS-Google-SSO-Pilot, och skapa klienten.
Spara genast Client ID och Client secret i ett godkänt valv för hemligheter. Hemligheten ska inte kopieras till skärmbilder, ärenden eller ändringsdokumentationen.

OAuth-klient-ID:t identifierar brandväggen vid inloggningen. Det är inte tjänstekontots numeriska ID, som senare behövs för delegeringen. Omdirigerings-URI:erna läggs till först när brandväggen har genererat dem.

Konfigurera tjänstekontot och hämtningen av grupper

Inloggningen och hämtningen av grupper använder olika autentiseringsuppgifter: OAuth-klienten används för interaktiv inloggning; tjänstekontot gör det möjligt för brandväggen att hämta information från Google Directory. Google skickar inte automatiskt gruppmedlemskap som en del av det vanliga OIDC-inloggningssvaret.

Skapa ett dedikerat konto för denna integration under Google Cloud Console > IAM & admin > Service accounts > Create service account, till exempel sfos-directory-reader.
Tilldela inte generella Owner- eller Editor-roller som en förmodad förutsättning. Ytterligare IAM-behörigheter godkänns endast för ett verifierat behov.
Notera det numeriska Unique ID i tjänstekontots detaljer.
Välj typen JSON under Keys > Add key > Create new key. Förvara den hämtade privata nyckeln skyddat inför den senare uppladdningen till brandväggen och undvik okontrollerade kopior i nedladdningsmappar.
Sök efter Admin SDK API under APIs & Services > Library och aktivera det med Enable.

⚠️ Om Service account key creation is disabled visas avbryts konfigurationen. En organisationspolicy ska inte stängas av för hela organisationen för att fortsätta med denna guide. Den säkerhetsansvariga för Google måste godkänna ett begränsat, dokumenterat undantag, annars förblir integrationen blockerad. Den Sophos-konfiguration som beskrivs här kräver en JSON-nyckelfil; ingen annan autentiseringsmetod anges som en oprövad ersättning.

Begränsa domänomfattande delegering

Öppna Google Admin Console > Security > Access and data control > API controls som behörig Super Admin.
Under Domain-wide delegation > Manage domain wide delegation > Add new anger du tjänstekontots Unique ID som Client ID, inte OAuth-webbklientens ID.
Ange de två nödvändiga läsbehörigheterna i OAuth scopes (comma-delimited):

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

Om även WebAdmin ska autentiseras via Google lägger du dessutom till denna behörighet:

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

Spara delegeringen med Authorize och kontrollera ID:t samt hela listan över behörigheter.

Dessa scope-URL:er är fasta API-identifierare, inte exempelvärden. Om Multi-party approval är aktivt måste ytterligare en Super Admin godkänna delegeringen. Ändringar kan ta upp till 24 timmar; under denna tid ska inte en andra delegering med bredare behörigheter skapas i förtid. Domänomfattande delegering tillåter åtkomst på någon annans vägnar i Workspace-miljön och är därför ett säkerhetsrelevant godkännande även med enbart läsbehörigheter. Tjänstekontot, nyckel-ID:t, det delegerade administratörskontot, syftet och granskningsdatumet ska ha en namngiven ansvarig.

Förbered separata grupper för brandväggsadministratörer

Gruppmappning rekommenderas för en överskådlig start. Skapa en grupp enbart för brandväggsadministratörer under Google Admin Console > Directory > Groups och lägg endast till pilotadministratörerna. En grupp som exempelvis SFOS-NOC-ReadOnly kan tilldelas en tidigare kontrollerad skrivskyddad profil. Namn och gruppadress är organisationens egna värden; en vanlig personal- eller VPN-grupp ska inte få WebAdmin-behörigheter.

Alternativt kan du tilldela anpassade eller fördefinierade Google-administratörsroller under Account > Admin roles och använda Roles i brandväggens serverkonfiguration. Anpassade roller mappas med det exakta rollnamnet; fördefinierade roller kräver sitt särskilda IdP-värde, inte bara det namn som visas. Ett bekräftat exempel är Groups admin → _GROUPS_ADMIN_ROLE. Google-administratörsroller kan samtidigt ge behörigheter i Google Admin Console. De tilldelas därför inte enbart som en praktisk etikett för brandväggen; en dedikerad grupp är oftast det mer avgränsade valet.

Konfigurera OIDC-servern på brandväggen

Klient, omdirigeringar och slutpunkter

Öppna WebAdmin via det planerade FQDN:et och gå till Authentication > Servers > Add.
Välj Server type: OpenID Connect, ett unikt Server name och IdP vendor: Google Workspace.
Ange OAuth-webbklientens Client ID och Client secret.
Välj Use firewall URL under Redirect URIs. Brandväggen använder värdnamnet från den aktuella WebAdmin-URL:en. Ange alternativt det egna verifierade FQDN:et med Enter manually.
Öppna Show URLs och kopiera de fullständiga URL:erna för Web admin console, Captive portal respektive VPN portal and remote access för de tjänster som faktiskt planeras.
Behåll den automatiskt inställda Issuer URL https://accounts.google.com och använd Discover/Reset endpoint URLs. Authorization URL, Token URL, Logout URL, JWKS URL och User info URL fylls i via Discovery och ska inte gissas.

Identitet, fallback och administratörsbehörigheter

Under User attributes stöder Display name och Username värdena name eller email; den dokumenterade standardinställningen är name för båda. Email address är förinställt till email. Beslutet fattas före den första pilotinloggningen: email kan förenkla kopplingen till en unik Workspace-inloggningsadress, men måste passa befintliga identiteter på brandväggen. Attributvärden ändras inte senare utan eftertanke, eftersom det kan leda till andra kontokopplingar.

För användning enbart med VPN eller Captive Portal lämnas IdP authentication for firewall administrators avstängt. För WebAdmin aktiveras alternativet medvetet och varje mappning skapas med IdP attribute, exakt IdP value och Device access profile. Grupp- eller rollvärden hämtas från den egna Google-konfigurationen och gissas inte utifrån exempelnamnet.

Brandväggen kontrollerar mappningsregler uppifrån och ned och använder den första matchande profilen. En användare i flera administratörsgrupper måste därför testas särskilt. Utan en matchande administratörsmappning får identiteten ingen WebAdmin-åtkomst och kan skapas som en vanlig användare.

Välj en medvetet begränsad användargrupp under Fallback group. Om Google-gruppen inte finns på brandväggen används denna fallbackgrupp. Även om servern är vald under Firewall authentication methods ersätter Default group inte denna OIDC-fallbacktilldelning. En VPN-grupp med omfattande behörigheter är inte en säker uppsamlingsgrupp.

Kontrollera tjänstekontot och samordna värdnamnen

Ange adressen till den Google Workspace-superadministratör som är avsedd för denna åtkomst under Service account credentials > Email address. Här ska inte tjänstekontots e-postadress anges.
Välj det dedikerade tjänstekontots skyddade JSON-nyckelfil under JSON private key > Browse.
Kör Test connection. Testet kontrollerar nätverksanslutningen och applikationsbehörigheterna. Det bevisar ännu inte att användarinloggningen eller administratörsmappningen är korrekt.
Spara med Save.
Via Go to Admin and user settings anger du samma portal-FQDN under When redirecting users to the captive portal or other interactive pages: Use the firewall’s configured hostname eller Use a different hostname, beroende på den egna konfigurationen. Spara med Apply.
Öppna OAuth-webbklienten i Google Cloud Console > APIs & Services > Credentials och ange varje tidigare kopierad fullständig callback-URL under Authorized redirect URIs > Add URI. Spara med Save och jämför tecken för tecken.

Aktivera grupper, tjänster och VPN

Importera grupper och tilldela policyer

Öppna Google-serverns Assistant for importing groups under Authentication > Servers. Du kan importera alla grupper eller välja grupper utifrån Display name och Mail. För piloten väljs endast den användarkrets som behövs. I guiden kan Surfing quota, Access time, Network traffic och Traffic shaping tilldelas alla eller enskilda grupper.

Brandväggen och Google måste vara tidssynkroniserade, annars kan redan gruppimporten misslyckas. Kontrollera gruppnamnen och de avsedda policyerna efter importen. För IPsec eller SSL VPN måste de nya grupperna dessutom läggas till i de aktuella VPN-policyerna. En lyckad import innebär ännu inte VPN-behörighet.

Ändra autentisering per tjänst

Välj Google-servern endast för de metoder som behövs under Authentication > Services:

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; listans beteckning innebär inte OIDC-stöd för varje äldre protokoll som nämns där.
SSL VPN authentication methods: Remote Access SSL VPN.

Dra servern till början av listan för den valda tjänsten och använd Apply för varje tjänst. Kontrollera ordningen och den lokala fallbacken mot det tidigare dokumenterade tillståndet; Local ska inte tas bort oavsiktligt för personliga lokala administratörer. Tjänster som inte behövs lämnas oförändrade.

Sophos Connect och åtkomlighet

Google SSO använder VPN-portalporten även för fjärråtkomstkommunikation. För denna användning måste åtkomst till VPN-portalen från WAN tillåtas under Administration > Device access > Local service ACL. Tillåtna källor och den åtkomlighet som faktiskt behövs planeras medvetet; WebAdmin öppnas inte mot WAN för detta. Begränsningen beskrivs i Device Access och Local Service ACL.

Med en provisioneringsfil måste IPsec, SSL VPN och VPN Portal använda samma Google-server. Värdet gateway motsvarar det FQDN som användes för att generera omdirigeringarna. Utan provisioneringsfil måste SSL VPN och VPN Portal också använda samma server; IPsec kan använda en annan Google-server. Därför ska man inte blint ändra enbart ett autentiseringsfält i befintliga VPN-filer.

Efter att Google-konfigurationen har upprättats eller ändrats måste Windows-användare importera sin konfigurationsfil på nytt i Sophos Connect 2.4 eller senare. Först därefter testas en ny anslutning. På delade klientenheter måste en ny SSO-inloggning krävas för efterföljande användare; en befintlig Google-session får inte obemärkt logga in nästa person.

Valfritt: använd Captive Portal säkert

För den aktuella användarbaserade brandväggsregeln krävs Match known users och Use web authentication for unknown users. Under Authentication > Web authentication > Captive portal behavior aktiveras Show web page after sign-in, In new browser window väljs och Use insecure HTTP instead of HTTPS inaktiveras för detta portalflöde. Spara med Apply; OIDC stöder inte detta osäkra HTTP-läge.

Användarna lämnar Captive Portal-fönstret öppet för uttrycklig utloggning. Inaktivitet eller stängning av en flik avslutar inte Google SSO-sessionen här på samma sätt som med andra portalmetoder. Efter utloggningen förblir Googles utloggningssida synlig. Credential login med användarnamn och lösenord ersätter inte detta tokenbaserade Google OIDC-förfarande.

Verifiera inloggning och behörigheter

Verifieringen skiljer mellan anslutning, identitet och auktorisering. Alla tester dokumenteras med tidpunkt, konto, tjänst, klientversion och förväntat resultat, utan att hemligheter eller token registreras.

Slutför Test connection och en riktad gruppimport med lyckat resultat. Öppna därefter ett privat webbläsarfönster via det avsedda FQDN:et.
Logga in en pilotadministratör via Google och kontrollera det förväntade MFA-kravet. Under Authentication > Users måste identitet, administratörsstatus och tilldelad profil vara korrekta.
Kontrollera att nödvändiga menyer är tillgängliga och att ett spärrat område inte är tillgängligt. Ett skrivskyddat konto får inte kunna spara en ändring. Ett vanligt VPN-konto får inte kunna logga in i WebAdmin.
Kontrollera ett konto med flera matchande mappningar. Profilen måste tillhöra den dokumenterade första matchande regeln, inte den roll som antas vara starkast.
Logga in separat i VPN Portal och upprätta en IPsec- respektive SSL VPN-tunnel med den nyligen importerade Sophos Connect-konfigurationen. En godkänd intern resurs måste vara åtkomlig; en resurs som inte är godkänd måste förbli spärrad.
Logga ut och kontrollera på nytt med en ny session. Google-inloggning, portalåtkomst och VPN-tunnel är separata framgångskriterier.
Korrelera WebAdmin-händelserna i Log viewer > Admin med Captive Portal-, VPN Portal-, IPsec- och SSL VPN-inloggningarna i Log viewer > Authentication. För vidare analys finns oauth_sso_svc.log tillgänglig i Advanced Shell; felsöknings- eller omstartskommandon förutsätts inte för detta.
Kontrollera den oberoende lokala återställningsåtkomsten igen innan fler användare migreras.

Administratörskonton skapas eller uppdateras endast vid en lyckad WebAdmin-inloggning. En VPN- eller Captive Portal-inloggning synkroniserar ingen administratörsroll. Ändringar av Google-roller verifieras därför med en ny WebAdmin-inloggning, inte utifrån en fungerande tunnel.

Avgränsa fel systematiskt

Google rapporterar redirect_uri_mismatch

Jämför den berörda fullständiga URL:en från Show URLs med Authorized redirect URIs för den OAuth-klient som faktiskt används: schema, FQDN, port och sökväg måste stämma exakt. Kontrollera därefter att webbläsaren använder samma värdnamn och att den automatiska portalomdirigeringen pekar på detta namn. Testa en ny inloggning efter korrigeringen; varken omdirigeringar med jokertecken eller byte till IP-adress är lösningen.

Test connection eller gruppimporten misslyckas

Kontrollera först systemtid och nätverksanslutning. Kontrollera därefter Admin SDK API, en giltig JSON-nyckelfil, rätt delegerat Super Admin-konto samt Domain-wide delegation med tjänstekontots numeriska ID och de nödvändiga behörigheterna. Om grupper saknas kontrolleras även importfiltret Display name/Mail. Ett fel åtgärdas inte med generella Cloud Owner-behörigheter eller ytterligare skrivbehörigheter.

Google-inloggningen fungerar, men WebAdmin nekar åtkomst

Kontrollera gruppmedlemskapet respektive rolltilldelningen hos Google, IdP authentication for firewall administrators, exakt IdP value, mappningsordningen och den lokala Device access profile. Gör därefter en ny WebAdmin-inloggning och kontrollera Log viewer > Admin. En tidigare VPN-inloggning bevisar varken mappningen eller att administratören har uppdaterats.

Portalen fungerar, men inte tunneln eller den interna resursen

Kontrollera Windows- och Sophos Connect-versionen, den nyligen importerade konfigurationsfilen, VPN-portalens åtkomlighet och servertilldelningen för varje tjänst. Kontrollera därefter gruppmedlemskapet i VPN-policyerna och reglerna för målresursen. Log viewer > Authentication visar inloggningen; en lyckad autentiseringspost bevisar inte i sig att datatrafik tillåts.

Context-Aware Access eller ny inloggning fungerar annorlunda än väntat

Enhetsbaserade Google CAA-villkor kräver ett webbläsarflöde som stöds och att verifieringsdata för klientenheten faktiskt är tillgängliga. För det beskrivna kontrollförfarandet används Google Chrome med Endpoint Verification. En lyckad Sophos Connect-inloggning betraktas inte som bevis för att varje enhetsbaserat CAA-villkor har utvärderats.

CAA utvärderas vid autentiseringen och avslutar inte en redan aktiv brandväggssession. Inte heller Googles intervall för återautentisering tvingar fram en ny inloggning för en aktiv VPN-session på brandväggen. Kontrollera en ny autentisering efter kontrollerad utloggning respektive frånkoppling; befintliga sessioner måste hanteras separat när en användares åtkomst avvecklas.

Drift, avveckling av åtkomst och återställning

En ändring av grupper eller roller kontrolleras med en ny inloggning och positiva och negativa tester. När en person tas bort från administrationen räcker inte enbart ändringen av Google-rollen: SFOS omvandlar inte automatiskt ett befintligt administratörskonto tillbaka till en vanlig användare. Efter kontroll av beroenden och med en annan fungerande administratör måste det berörda administratörskontot tas bort från brandväggen. Vid nästa vanliga inloggning kan brandväggen skapa användaren på nytt. Aktiva WebAdmin- och VPN-sessioner kontrolleras och avslutas separat; ett indraget gruppmedlemskap innebär inte att sessioner bevisligen återkallas omedelbart.

För OAuth-hemligheten och tjänstekontots nyckel fastställs ansvarig, säker lagring, granskning och rotation. Vid en planerad rotation hålls den gamla nyckeln tillgänglig endast så länge som den dokumenterade återställningsvägen kräver. De nya autentiseringsuppgifterna kontrolleras först med Test connection, grupphämtning och en ny inloggning innan de gamla autentiseringsuppgifterna återkallas. En kompromettering hanteras däremot enligt den egna incidentprocessen och förlängs inte för att möjliggöra en bekväm återställning.

Om piloten misslyckas återställs den exakt dokumenterade tidigare tjänstetilldelningen och serverordningen från den öppna sessionen med fullständiga administratörsbehörigheter eller via den lokala återställningsåtkomsten. Ändrade portalvärdnamn, Device Access, grupp-/VPN-policyer och administratörsmappningar återställs också till sina respektive tidigare tillstånd. Testa därefter lokal administratörsinloggning och den tidigare VPN-vägen i nya sessioner.

Dessutom jämförs varje berört konto under Authentication > Users med den tidigare dokumentationen för det enskilda kontot via den oberoende tillgängliga åtkomstvägen med fullständiga administratörsbehörigheter. För befintliga konton återställs uttryckligen tidigare User type, tilldelad Profile och kontostatus. Om detta kräver att ett konto tas bort och skapas på nytt kontrolleras först alla beroenden och de tidigare tilldelningarna säkras. Endast administratörs- och användarobjekt som skapades under piloten tas bort, efter kontroll av deras grupp-, VPN-, policy- och övriga beroenden. En återställd servermappning eller en borttagen Google-roll ersätter inte denna kontorensning och avslutar ingen befintlig session. Aktiva WebAdmin-, portal- och VPN-sessioner kontrolleras och avslutas därför separat. Slutligen verifieras i nya sessioner att den tidigare lokala administratörsåtkomsten och VPN-åtkomsten fungerar och att en pilotidentitet som inte längre är behörig nekas åtkomst. För återställda befintliga konton kontrolleras att de ursprungliga behörigheterna finns kvar och att de ytterligare behörigheter som endast beviljades under piloten inte längre medger åtkomst.

Först när återställningsvägen fungerar och inga andra tjänster är beroende av dem tas de omdirigerings-URI:er, delegeringsgodkännanden och autentiseringsuppgifter som skapades enbart för piloten bort under kontrollerade former. Delade klienter eller tjänstekonton tas inte bort utan kontroll av beroenden. En fullständig konfigurationsbackup återläses endast inom det godkända återställningsfönstret, eftersom den även kan återställa andra, oberoende ändringar på brandväggen.