Configurare Google Workspace OIDC su Sophos Firewall

Con SFOS 23.0 è possibile configurare Google Workspace come provider di identità OpenID Connect (OIDC) per WebAdmin, Captive Portal, VPN Portal e per l’accesso remoto IPsec e SSL VPN. Google verifica l’identità; il firewall recupera inoltre le appartenenze ai gruppi e applica i propri permessi per utenti, VPN e amministratori. Un accesso a Google riuscito, quindi, non concede di per sé l’accesso amministrativo o a una rete interna.

Procedura rapida: preparare un client web OAuth di Google e un account di servizio delegato, creare in Authentication > Servers un server OpenID Connect con IdP vendor: Google Workspace, registrare in Google gli URL di callback visualizzati, importare i gruppi e modificare solo i servizi necessari in Authentication > Services. Successivamente, verificare accesso, permessi e log con un account pilota. L’accesso locale di emergenza già testato deve essere mantenuto.

Questa guida descrive la configurazione di SFOS 23, ma non garantisce il supporto di una specifica build firmware approvata. Prima di un aggiornamento, attenersi alla propria pianificazione di firmware e backup. Chromebook SSO e Google Directory Sync per Sophos Fusion sono integrazioni diverse e non sostituiscono questo server OIDC del firewall.

Prerequisiti e limiti di sicurezza

Definire le responsabilità e salvaguardare la configurazione esistente

Sono necessari un progetto Google Cloud, un account Google Workspace con accesso Super Admin per la configurazione e un amministratore del firewall. Cloud Console gestisce client OAuth, API e account di servizio; Google Admin Console gestisce utenti, gruppi e Domain-wide delegation.

Prima del progetto pilota, preparare un backup della configurazione e un accesso locale di ripristino già testato. Annotare inoltre i server di autenticazione esistenti e il loro ordine per ciascun servizio, i nomi host dei portali, le autorizzazioni di Device Access, le assegnazioni a gruppi e VPN e i profili amministrativi esistenti. Durante la modifica deve rimanere disponibile una sessione aperta con privilegi amministrativi completi; a causa dei possibili timeout, questa non sostituisce il secondo accesso.

Per ogni identità locale interessata, prima del primo accesso pilota si annotano in Authentication > Users l’eventuale esistenza dell’account, il precedente User type, il Profile assegnato e lo stato dell’account. Questa rilevazione dei singoli account fa parte dello stato precedente da documentare: una successiva modifica del mapping IdP o del ruolo Google non ripristina automaticamente gli account amministrativi locali esistenti.

Per la pianificazione dei permessi continuano a valere le indicazioni su amministratori personali e profili Device Access. Google SSO non sostituisce né il principio del privilegio minimo né la limitazione delle sorgenti di accesso alla gestione.

Utilizzare un nome host uniforme

Il nome del portale deve appartenere a un dominio registrabile con un TLD pubblico. Un nome singolo come firewall o un dominio locale come firewall.local non è adatto ai reindirizzamenti OAuth di Google. Utilizzare lo stesso FQDN per l’accesso al portale, gli URI di reindirizzamento e i reindirizzamenti automatici del portale. Verificare la risoluzione DNS e un certificato HTTPS attendibile corrispondente al nome dalle reti client effettivamente utilizzate.

fw.example.com è usato qui solo come esempio per la documentazione e deve essere sostituito con il proprio FQDN valido. Non è un URI di reindirizzamento pronto all’uso. Il percorso di callback e la porta del servizio verranno copiati in seguito senza modifiche da Show URLs, non ricostruiti a partire da un esempio. Per questa procedura si utilizza un FQDN anche in caso di inserimento manuale, non un indirizzo IP.

Verificare i limiti prima della migrazione

Per ogni servizio di autenticazione è possibile selezionare un solo server IdP OIDC. Un’assegnazione Entra già presente non viene quindi semplicemente affiancata: deve essere sostituita consapevolmente oppure lasciata invariata.
Per lo stesso dominio, gli utenti non possono essere sincronizzati contemporaneamente tramite Active Directory e Google Workspace. Gli utenti e i gruppi esistenti richiedono oggetti Google corrispondenti; gli oggetti preesistenti non associabili continuano a essere gestiti manualmente.
La MFA integrata nel firewall non viene utilizzata per Google OIDC. Il requisito MFA viene configurato in Google e verificato effettivamente nel progetto pilota. Gli account locali di emergenza mantengono la propria protezione.
Nel cluster HA, Google SSO attualmente non supporta l’accesso a WebAdmin sul dispositivo ausiliario. A questo scopo rimane necessario un percorso di gestione locale indipendente.
Per Google SSO con Sophos Connect sono previsti Windows e la versione client 2.4 o successiva. Il supporto di Entra su macOS non implica il supporto di Google Workspace.

Solo se si intende utilizzare Context-Aware Access (CAA): prima del progetto pilota, verificare per ciascun utente previsto la disponibilità di una licenza o edizione che supporti CAA; verificare inoltre il supporto per l’applicazione e il flusso di accesso specifici e l’effettiva assegnazione della policy desiderata all’applicazione e al gruppo di utenti o all’unità organizzativa. Gli utenti con edizioni diverse non sono soggetti alla policy CAA, anche se questa è assegnata allo stesso gruppo o alla stessa unità organizzativa; Endpoint Verification, da solo, non dimostra che l’utente disponga di una licenza idonea per CAA. CAA è facoltativo e una licenza premium non è un prerequisito per il normale utilizzo di Google OIDC. La documentazione Google relativa a SAML non dimostra il supporto del flusso OIDC di Sophos. Prima dell’approvazione, dimostrare l’effetto desiderato mediante nuovi test di accesso positivi e negativi per l’applicazione, gli utenti e le condizioni specifici; l’assenza di supporto o un test negativo in cui l’accesso riesce inaspettatamente impediscono l’approvazione del flusso protetto da CAA.

Preparare Google Workspace

Creare il client web OAuth

In Google Cloud Console > APIs & Services > Credentials, selezionare il progetto corretto. Se Google richiede prima la configurazione della schermata di consenso OAuth, completarla per la propria organizzazione e per gli utenti autorizzati; non creare un’autorizzazione esterna generale solo per il test.
Aprire Create credentials > OAuth client ID e selezionare Application type: Web application.
Assegnare un nome riconoscibile, ad esempio SFOS-Google-SSO-Pilot, e creare il client.
Salvare immediatamente Client ID e Client secret in un vault di segreti approvato. Non copiare il segreto in screenshot, ticket o documentazione della modifica.

L’ID del client OAuth identifica il firewall durante l’accesso. Non è l’ID numerico dell’account di servizio, che servirà in seguito per la delega. Gli URI di reindirizzamento vengono aggiunti solo dopo che il firewall li ha generati.

Configurare l’account di servizio e il recupero dei gruppi

L’accesso e il recupero dei gruppi utilizzano credenziali diverse: il client OAuth serve per il login interattivo; l’account di servizio consente al firewall di recuperare le informazioni di Google Directory. Google non fornisce le appartenenze ai gruppi semplicemente come parte della normale risposta di autenticazione OIDC.

In Google Cloud Console > IAM & admin > Service accounts > Create service account, creare un account dedicato a questa integrazione, ad esempio sfos-directory-reader.
Non assegnare indiscriminatamente i ruoli Owner o Editor come presunto prerequisito. I permessi IAM aggiuntivi vengono autorizzati solo per un’attività la cui necessità sia stata verificata.
Nei dettagli dell’account di servizio, annotare la Unique ID numerica.
In Keys > Add key > Create new key, scegliere il tipo JSON. Conservare in modo protetto la chiave privata scaricata per il successivo caricamento sul firewall ed evitare copie del download non controllate.
In APIs & Services > Library, cercare Admin SDK API e attivarla con Enable.

⚠️ Se compare Service account key creation is disabled, interrompere la configurazione. Non disattivare una policy a livello dell’intera organizzazione per proseguire con questa guida. Il responsabile della sicurezza Google deve approvare un’eccezione limitata e documentata, altrimenti l’integrazione rimane bloccata. La configurazione Sophos qui descritta richiede un file di chiave JSON; non viene proposta un’altra modalità di autenticazione come alternativa non verificata.

Limitare la Domain-wide delegation

Come Super Admin autorizzato, aprire Google Admin Console > Security > Access and data control > API controls.
In Domain-wide delegation > Manage domain wide delegation > Add new, inserire la Unique ID dell’account di servizio come Client ID, non l’ID del client web OAuth.
In OAuth scopes (comma-delimited), inserire i due scope di lettura necessari:

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

Se anche WebAdmin deve essere autenticato tramite Google, aggiungere questo scope:

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

Salvare la delega con Authorize e controllare l’ID e l’elenco completo degli scope.

Gli URL degli scope sono identificatori API fissi, non valori di esempio. Se Multi-party approval è attivo, un altro Super Admin deve approvare la delega. Le modifiche possono richiedere fino a 24 ore; durante questo intervallo non creare frettolosamente una seconda delega con permessi più ampi. La Domain-wide delegation consente l’accesso per conto di altri utenti nel tenant Workspace ed è quindi un’autorizzazione rilevante per la sicurezza, anche se limitata alla lettura. Assegnare un responsabile identificato e documentare account di servizio, ID della chiave, account amministrativo delegato, finalità e data di revisione.

Preparare gruppi separati per gli amministratori del firewall

Per iniziare in modo chiaro, si consiglia il mapping dei gruppi. In Google Admin Console > Directory > Groups, creare un gruppo esclusivamente per gli amministratori del firewall e aggiungere solo gli amministratori pilota. Ad esempio, un gruppo SFOS-NOC-ReadOnly può essere associato a un profilo di sola lettura verificato in precedenza. Nome e indirizzo del gruppo sono valori specifici della propria organizzazione; un normale gruppo di dipendenti o utenti VPN non riceve permessi WebAdmin.

In alternativa, in Account > Admin roles è possibile assegnare ruoli amministrativi Google personalizzati o predefiniti e utilizzare Roles nel server del firewall. I ruoli personalizzati vengono associati tramite il nome esatto del ruolo; i ruoli predefiniti richiedono il loro specifico valore IdP, non semplicemente il nome visualizzato. Un esempio confermato è Groups admin → _GROUPS_ADMIN_ROLE. I ruoli amministrativi Google possono concedere anche permessi in Google Admin Console. Pertanto, non vengono assegnati solo come comoda etichetta per il firewall; un gruppo dedicato è generalmente la scelta più restrittiva.

Configurare il server OIDC sul firewall

Client, reindirizzamenti ed endpoint

Aprire WebAdmin tramite il FQDN previsto e accedere a Authentication > Servers > Add.
Selezionare Server type: OpenID Connect, un Server name univoco e IdP vendor: Google Workspace.
Inserire Client ID e Client secret del client web OAuth.
In Redirect URIs, selezionare Use firewall URL. Il firewall utilizza il nome host dell’URL WebAdmin corrente. In alternativa, inserire il proprio FQDN verificato tramite Enter manually.
Aprire Show URLs e copiare gli URL completi per Web admin console, Captive portal o VPN portal and remote access dei servizi effettivamente previsti.
Lasciare la Issuer URL impostata automaticamente su https://accounts.google.com e utilizzare Discover/Reset endpoint URLs. Authorization URL, Token URL, Logout URL, JWKS URL e User info URL vengono compilati tramite discovery, non impostati per tentativi.

Identità, fallback e permessi amministrativi

In User attributes, Display name e Username supportano i valori name o email; il valore predefinito documentato è name per entrambi. Email address è precompilato con email. La scelta viene effettuata prima del primo accesso pilota: email può semplificare l’associazione a un indirizzo di accesso Workspace univoco, ma deve essere compatibile con le identità esistenti sul firewall. I valori degli attributi non vengono modificati successivamente senza un’attenta valutazione, perché ciò può generare associazioni diverse degli account.

Per l’utilizzo esclusivo di VPN o Captive Portal, IdP authentication for firewall administrators rimane disattivato. Per WebAdmin, attivare consapevolmente l’opzione e creare ogni associazione con IdP attribute, l’esatto IdP value e Device access profile. I valori dei gruppi o dei ruoli vengono ricavati dalla propria configurazione Google, non dedotti dal nome di esempio.

Il firewall verifica le regole di mapping dall’alto verso il basso e utilizza il primo profilo corrispondente. Un utente appartenente a più gruppi amministrativi deve quindi essere testato esplicitamente. Senza un’associazione amministrativa corrispondente, l’identità non ottiene accesso a WebAdmin e può essere creata come utente normale.

In Fallback group, scegliere un gruppo di utenti volutamente limitato. Se il gruppo Google non esiste sul firewall, viene utilizzato questo gruppo di fallback. Anche quando il server è selezionato in Firewall authentication methods, Default group non sostituisce questa assegnazione di fallback OIDC. Un gruppo VPN con permessi estesi non è una destinazione di fallback sicura.

Verificare l’account di servizio e uniformare i nomi host

In Service account credentials > Email address, inserire l’indirizzo del Super Admin di Google Workspace previsto per questo accesso. Qui non deve essere inserito l’indirizzo email dell’account di servizio.
In JSON private key > Browse, selezionare il file di chiave JSON protetto dell’account di servizio dedicato.
Eseguire Test connection. Il test verifica la connettività di rete e i permessi applicativi. Non dimostra ancora che l’accesso dell’utente o l’associazione amministrativa siano corretti.
Salvare con Save.
Tramite Go to Admin and user settings, in When redirecting users to the captive portal or other interactive pages, impostare lo stesso FQDN del portale: Use the firewall’s configured hostname oppure Use a different hostname, in base alla propria configurazione. Salvare con Apply.
In Google Cloud Console > APIs & Services > Credentials, aprire il client web OAuth e inserire in Authorized redirect URIs > Add URI ciascun URL di callback completo copiato in precedenza. Salvare con Save e confrontare i valori carattere per carattere.

Abilitare gruppi, servizi e VPN

Importare i gruppi e assegnare le policy

In Authentication > Servers, aprire Assistant for importing groups del server Google. È possibile importare tutti i gruppi oppure selezionare gruppi specifici in base a Display name e Mail. Per il progetto pilota viene selezionato solo l’insieme di utenti necessario. Nella procedura guidata è possibile assegnare Surfing quota, Access time, Network traffic e Traffic shaping a tutti i gruppi o a singoli gruppi.

Il firewall e Google devono avere l’ora sincronizzata, altrimenti anche l’importazione dei gruppi può fallire. Dopo l’importazione, controllare i nomi dei gruppi e le policy previste. Per IPsec o SSL VPN, i nuovi gruppi devono essere aggiunti anche alle rispettive policy VPN. Un’importazione riuscita non costituisce ancora un’autorizzazione VPN.

Modificare l’autenticazione per ciascun servizio

In Authentication > Services, selezionare il server Google solo per i metodi necessari:

Administrator authentication methods: WebAdmin.
Firewall authentication methods: Captive Portal.
VPN portal authentication methods: VPN Portal.
VPN (IPsec/dial-in/L2TP/PPTP) authentication methods: accesso remoto IPsec; il nome dell’elenco non implica il supporto OIDC per ogni protocollo legacy menzionato.
SSL VPN authentication methods: accesso remoto SSL VPN.

Trascinare il server all’inizio dell’elenco per il servizio scelto e utilizzare Apply per ciascun servizio. Verificare l’ordine e il fallback locale rispetto allo stato documentato in precedenza; Local non viene rimosso incidentalmente per gli amministratori locali personali. I servizi non necessari rimangono invariati.

Sophos Connect e raggiungibilità

Google SSO utilizza la porta del VPN Portal anche per la comunicazione di accesso remoto. Per questo utilizzo, in Administration > Device access > Local service ACL deve essere consentito l’accesso al VPN Portal dalla WAN. Pianificare consapevolmente le sorgenti consentite e la raggiungibilità effettivamente necessaria; WebAdmin non viene aperto sulla WAN a questo scopo. Le limitazioni sono descritte in Device Access e Local Service ACL.

Con un file di provisioning, IPsec, SSL VPN e VPN Portal devono utilizzare lo stesso server Google. Il valore gateway corrisponde al FQDN con cui sono stati generati i reindirizzamenti. Senza un file di provisioning, anche SSL VPN e VPN Portal devono utilizzare lo stesso server; IPsec può utilizzare un altro server Google. Nei file VPN esistenti, quindi, non modificare alla cieca soltanto un campo di autenticazione.

Dopo la configurazione o la modifica della configurazione Google, gli utenti Windows devono importare nuovamente il proprio file di configurazione in Sophos Connect 2.4 o successivo. Solo a quel punto viene testata una nuova connessione. Sugli endpoint condivisi, per gli utenti successivi deve essere imposto un nuovo accesso SSO; una sessione Google esistente non deve autenticare la persona successiva senza che ciò venga rilevato.

Facoltativo: utilizzare il Captive Portal in modo sicuro

Per la relativa regola firewall basata sugli utenti sono necessari Match known users e Use web authentication for unknown users. In Authentication > Web authentication > Captive portal behavior, per questo flusso del portale attivare Show web page after sign-in, selezionare In new browser window e disattivare Use insecure HTTP instead of HTTPS. Salvare con Apply; OIDC non supporta questa modalità HTTP non sicura.

Gli utenti lasciano aperta la finestra del Captive Portal per effettuare esplicitamente la disconnessione. In questo caso, l’inattività o la chiusura di una scheda non termina la sessione Google SSO come avviene con altri metodi di accesso al portale. Dopo la disconnessione, la pagina di disconnessione di Google rimane visibile. Credential login con nome utente e password non sostituisce questo flusso Google OIDC basato su token.

Convalidare accesso e autorizzazioni

La convalida distingue connessione, identità e autorizzazione. Tutti i test vengono registrati con data e ora, account, servizio, versione del client e risultato atteso, senza annotare segreti o token.

Completare con successo Test connection e l’importazione mirata dei gruppi. Aprire quindi una finestra di navigazione privata tramite il FQDN previsto.
Accedere tramite Google con un amministratore pilota e controllare il requisito MFA atteso. In Authentication > Users, identità, stato di amministratore e profilo assegnato devono essere corretti.
Verificare positivamente i menu necessari e verificare che l’accesso a un’area bloccata venga negato. Un account di sola lettura non deve poter salvare modifiche. Un normale account VPN non deve poter accedere a WebAdmin.
Verificare un account che corrisponde a più regole di mapping. Il profilo deve essere quello della prima regola corrispondente documentata, non quello del ruolo ritenuto più potente.
Accedere separatamente al VPN Portal e stabilire un tunnel IPsec o SSL VPN con la configurazione Sophos Connect appena importata. Una risorsa interna autorizzata deve essere raggiungibile; una risorsa non autorizzata deve rimanere bloccata.
Disconnettersi e ripetere la verifica con una nuova sessione. Accesso a Google, accesso al portale e tunnel VPN sono criteri di successo distinti.
Correlare gli eventi WebAdmin in Log viewer > Admin e gli accessi a Captive Portal, VPN Portal, IPsec e SSL VPN in Log viewer > Authentication. Per un’analisi più approfondita è disponibile oauth_sso_svc.log nella Advanced Shell; non sono richiesti comandi di debug o riavvio a questo scopo.
Verificare nuovamente l’accesso locale di ripristino indipendente prima di migrare altri utenti.

Gli account amministrativi vengono creati o aggiornati solo dopo un accesso a WebAdmin riuscito. Un accesso VPN o Captive Portal non sincronizza un ruolo amministrativo. Le modifiche ai ruoli Google vengono quindi convalidate tramite un nuovo accesso a WebAdmin, non sulla base di un tunnel stabilito con successo.

Individuare le cause degli errori in modo mirato

Google segnala redirect_uri_mismatch

Confrontare l’URL completo interessato, ricavato da Show URLs, con Authorized redirect URIs del client OAuth effettivamente utilizzato: schema, FQDN, porta e percorso devono corrispondere esattamente. Verificare quindi che il browser utilizzi lo stesso nome host e che il reindirizzamento automatico del portale punti a quel nome. Dopo la correzione, testare un nuovo accesso; né i reindirizzamenti con caratteri jolly né il passaggio a un indirizzo IP sono la soluzione.

Test connection o l’importazione dei gruppi non riesce

Verificare innanzitutto l’ora di sistema e la connettività di rete. Controllare quindi Admin SDK API, la validità del file di chiave JSON, il corretto account Super Admin delegato e Domain-wide delegation con l’ID numerico dell’account di servizio e gli scope richiesti. Se mancano dei gruppi, controllare anche il filtro di importazione Display name/Mail. Un errore non viene risolto concedendo indiscriminatamente permessi Cloud Owner o aggiungendo scope di scrittura.

L’accesso a Google funziona, ma WebAdmin lo rifiuta

Controllare l’appartenenza ai gruppi o l’assegnazione dei ruoli in Google, IdP authentication for firewall administrators, l’esatto IdP value, l’ordine delle regole di mapping e il Device access profile locale. Eseguire quindi un nuovo accesso a WebAdmin e controllare Log viewer > Admin. Un precedente accesso VPN non dimostra né il corretto mapping né l’aggiornamento dell’amministratore.

Il portale funziona, ma il tunnel o la risorsa interna no

Verificare la versione di Windows e di Sophos Connect, il file di configurazione appena importato, la raggiungibilità del VPN Portal e l’assegnazione del server per ciascun servizio. Controllare quindi l’appartenenza ai gruppi nelle policy VPN e le regole per la risorsa di destinazione. Log viewer > Authentication mostra l’accesso; una voce di autenticazione riuscita, da sola, non dimostra che il traffico dati sia consentito.

Context-Aware Access o la riautenticazione si comporta diversamente dal previsto

Le condizioni Google CAA basate sul dispositivo richiedono un flusso browser supportato e dati di verifica dell’endpoint effettivamente disponibili. Per la procedura di verifica descritta viene utilizzato Google Chrome con Endpoint Verification. Un accesso a Sophos Connect riuscito non viene considerato una prova che ogni condizione CAA basata sul dispositivo sia stata valutata.

CAA viene valutato durante l’autenticazione e non termina una sessione firewall già attiva. Anche l’intervallo di riautenticazione di Google non impone un nuovo accesso a una sessione VPN attiva del firewall. Verificare una nuova autenticazione dopo una disconnessione controllata dall’account o dal tunnel; le sessioni esistenti devono essere gestite separatamente durante l’offboarding.

Gestione operativa, offboarding e ripristino

Una modifica ai gruppi o ai ruoli viene verificata con un nuovo accesso e con test positivi e negativi. Quando si rimuove una persona dall’amministrazione, la sola modifica del ruolo Google non è sufficiente: SFOS non riconverte automaticamente un account amministrativo esistente in un utente normale. Dopo aver verificato le dipendenze e disponendo di un altro amministratore funzionante, l’account amministrativo interessato deve essere eliminato sul firewall. Al successivo accesso normale, il firewall può ricreare l’utente. Le sessioni WebAdmin e VPN attive vengono controllate e terminate separatamente; la rimozione da un gruppo non costituisce una revoca immediata delle sessioni verificata.

Per il segreto OAuth e la chiave dell’account di servizio vengono definiti responsabile, archiviazione sicura, revisione e rotazione. In caso di rotazione pianificata, la vecchia chiave rimane disponibile solo per il tempo richiesto dal percorso di ripristino documentato. Le nuove credenziali vengono prima verificate con Test connection, recupero dei gruppi e un nuovo accesso, prima di revocare le vecchie credenziali. Una compromissione, invece, viene gestita secondo il proprio processo di risposta agli incidenti; non si prolunga l’utilizzo delle credenziali compromesse per agevolare il rollback.

Se il progetto pilota non riesce, dalla sessione aperta con privilegi amministrativi completi o dall’accesso locale di ripristino si ripristinano l’assegnazione dei servizi e l’ordine dei server precedenti, annotati esattamente. Anche i nomi host dei portali, Device Access, le policy di gruppo/VPN e i mapping amministrativi modificati vengono riportati al rispettivo stato precedente. Verificare quindi l’accesso amministrativo locale e il precedente percorso VPN in nuove sessioni.

Inoltre, tramite l’accesso indipendente con privilegi amministrativi completi, confrontare ogni account interessato in Authentication > Users con la rilevazione dei singoli account. Per gli account già esistenti, ripristinare esplicitamente il precedente User type, il Profile assegnato e lo stato dell’account; se a questo scopo è necessario eliminare e ricreare un account, verificare prima tutte le dipendenze e salvaguardare le assegnazioni precedenti. Rimuovere solo gli oggetti amministratore o utente creati durante il progetto pilota, dopo averne verificato le dipendenze da gruppi, VPN, policy e altri elementi. Il ripristino del mapping del server o la rimozione di un ruolo Google non sostituiscono questa sistemazione degli account e non terminano alcuna sessione esistente. Le sessioni WebAdmin, dei portali e VPN attive vengono quindi controllate e terminate separatamente. Infine, verificare in nuove sessioni il precedente accesso amministrativo locale e il precedente accesso VPN, nonché il rifiuto dell’accesso a un’identità pilota non più autorizzata; per gli account preesistenti ripristinati, verificare i diritti originari e il rifiuto dei permessi aggiuntivi concessi solo durante il progetto pilota.

Solo quando il percorso di ripristino funziona e nessun altro servizio dipende da questi elementi, rimuovere in modo controllato gli URI di reindirizzamento, le autorizzazioni di delega e le credenziali creati esclusivamente per il progetto pilota. I client o gli account di servizio condivisi non vengono eliminati senza una verifica delle dipendenze. Un backup completo della configurazione viene ripristinato solo nella finestra di ripristino autorizzata, perché può annullare anche modifiche indipendenti apportate al firewall.