Configurer Google Workspace OIDC sur Sophos Firewall

Avec SFOS 23.0, Google Workspace peut être configuré comme fournisseur d’identité OpenID Connect (OIDC) pour WebAdmin, Captive Portal, VPN Portal ainsi que pour l’accès distant IPsec et SSL VPN. Google vérifie l’identité ; le firewall récupère également les appartenances aux groupes et applique ses propres droits utilisateur, VPN et administrateur. Une authentification Google réussie ne donne donc pas, à elle seule, un accès administrateur ou un accès à un réseau interne.

Procédure rapide : préparer un client Web OAuth Google et un compte de service délégué, créer sous Authentication > Servers un serveur OpenID Connect avec IdP vendor: Google Workspace, enregistrer dans Google les URL de rappel qui y sont affichées, importer les groupes et ne modifier que les services nécessaires sous Authentication > Services. Vérifier ensuite l’authentification, les droits et les journaux avec un compte pilote. L’accès de secours local testé est conservé.

Ce guide décrit la configuration sous SFOS 23, sans garantir sa disponibilité dans un build de firmware approuvé particulier. Avant une mise à jour, appliquer sa propre planification du firmware et des sauvegardes. Chromebook SSO et Google Directory Sync pour Sophos Fusion sont d’autres intégrations et ne remplacent pas ce serveur OIDC du firewall.

Prérequis et limites de sécurité

Définir les responsabilités et sauvegarder la configuration existante

Un projet Google Cloud, un compte Google Workspace disposant d’un accès Super Admin pour la configuration et un administrateur du firewall sont nécessaires. Cloud Console gère le client OAuth, les API et le compte de service ; Google Admin Console gère les utilisateurs, les groupes et la délégation à l’échelle du domaine.

Avant le pilote, préparer une sauvegarde de la configuration et un accès local de récupération testé. Noter également les serveurs d’authentification existants et leur ordre pour chaque service, les noms d’hôte des portails, les autorisations Device Access, les affectations de groupes et de VPN ainsi que les profils administrateur existants. Une session disposant de tous les droits administrateur reste ouverte pendant la modification ; en raison des délais d’expiration possibles, elle ne remplace pas le second accès.

Pour chaque identité locale concernée, consigner avant la première connexion pilote, sous Authentication > Users, si le compte existe déjà, ainsi que son User type actuel, le Profile attribué et le statut du compte. Cet inventaire individuel des comptes fait partie de l’état antérieur à conserver : une modification ultérieure du mapping IdP ou du rôle Google ne rétablit pas automatiquement l’état des comptes administrateur locaux existants.

Pour la planification des droits, les recommandations concernant les administrateurs personnels et les profils Device Access continuent de s’appliquer. Le SSO Google ne remplace ni le principe du moindre privilège ni la restriction des sources d’administration.

Utiliser un nom d’hôte uniforme

Le nom du portail doit appartenir à un domaine enregistrable doté d’un TLD public. Un nom simple tel que firewall ou un domaine local tel que firewall.local ne convient pas aux redirections OAuth Google. Utiliser le même FQDN pour l’accès au portail, les URI de redirection et les redirections automatiques vers le portail. Vérifier la résolution DNS et un certificat HTTPS de confiance correspondant au nom depuis les réseaux clients réellement utilisés.

fw.example.com sert ici uniquement d’exemple documentaire et doit être remplacé par son propre FQDN valide. Il ne s’agit pas d’une URI de redirection prête à l’emploi. Le chemin de rappel et le port du service seront repris ultérieurement, sans modification, depuis Show URLs, et non assemblés à partir d’un exemple. Pour cette procédure, utiliser également un FQDN lors d’une saisie manuelle, et non une adresse IP.

Vérifier les limites avant la migration

Un seul serveur IdP OIDC peut être sélectionné pour chaque service d’authentification. Une affectation Entra existante ne peut donc pas simplement être complétée : elle doit être remplacée délibérément ou laissée inchangée.
Pour un même domaine, les utilisateurs ne peuvent pas être synchronisés simultanément via Active Directory et Google Workspace. Les utilisateurs et groupes existants doivent disposer d’objets Google correspondants ; les anciens objets sans correspondance restent gérés manuellement.
La MFA propre au firewall n’est pas utilisée pour Google OIDC. L’exigence de MFA est configurée dans Google et effectivement vérifiée pendant le pilote. Les comptes de secours locaux conservent leur propre protection.
Dans un cluster HA, le SSO Google ne prend actuellement pas en charge la connexion à WebAdmin sur l’équipement auxiliaire. Un accès d’administration local indépendant reste donc nécessaire.
Le SSO Google avec Sophos Connect est prévu pour Windows et la version 2.4 ou ultérieure du client. La prise en charge d’Entra sous macOS ne constitue pas une validation pour Google Workspace.

Uniquement si Context-Aware Access (CAA) doit être utilisé : avant le pilote, vérifier pour chaque utilisateur prévu qu’il dispose d’une licence ou d’une édition prenant en charge CAA. Vérifier également la prise en charge de l’application et du flux de connexion précis, ainsi que l’affectation effective de la politique souhaitée à l’application et au groupe d’utilisateurs ou à l’unité organisationnelle. Les utilisateurs disposant d’autres éditions ne sont pas soumis à la politique CAA, même si le même groupe ou la même unité organisationnelle est ciblé ; Endpoint Verification ne prouve pas, à lui seul, que l’utilisateur bénéficie de CAA. CAA est facultatif et une licence premium n’est pas requise pour une utilisation ordinaire de Google OIDC. La documentation Google relative à SAML ne démontre pas la prise en charge du flux OIDC de Sophos. Avant la mise en service, démontrer l’effet attendu au moyen de nouveaux tests de connexion positifs et négatifs pour l’application, les utilisateurs et les conditions concernés ; une absence de prise en charge ou la réussite inattendue d’un test négatif bloque la mise en service du flux protégé par CAA.

Préparer Google Workspace

Créer le client Web OAuth

Dans Google Cloud Console > APIs & Services > Credentials, sélectionner le bon projet. Si Google demande d’abord de configurer l’écran de consentement OAuth, terminer cette configuration pour son organisation et les utilisateurs autorisés ; ne pas créer une autorisation externe générale uniquement pour le test.
Ouvrir Create credentials > OAuth client ID et sélectionner Application type: Web application.
Attribuer un nom explicite, par exemple SFOS-Google-SSO-Pilot, puis créer le client.
Enregistrer immédiatement Client ID et Client secret dans un coffre-fort de secrets approuvé. Ne pas copier le secret dans des captures d’écran, des tickets ou la documentation du changement.

L’ID du client OAuth identifie le firewall lors de l’authentification. Il ne s’agit pas de l’ID numérique du compte de service qui sera nécessaire pour la délégation. Les URI de redirection ne seront ajoutées qu’une fois générées par le firewall.

Configurer le compte de service et la récupération des groupes

L’authentification et la récupération des groupes utilisent des accès différents : le client OAuth sert à la connexion interactive ; le compte de service permet au firewall de récupérer les informations de l’annuaire Google. Google ne fournit pas simplement les appartenances aux groupes dans la réponse d’authentification OIDC habituelle.

Sous Google Cloud Console > IAM & admin > Service accounts > Create service account, créer un compte dédié à cette intégration, par exemple sfos-directory-reader.
Ne pas attribuer globalement les rôles Owner ou Editor en les considérant à tort comme des prérequis. Les droits IAM supplémentaires ne sont approuvés que pour une tâche dont la nécessité est démontrée.
Dans les détails du compte de service, noter la valeur numérique Unique ID.
Sous Keys > Add key > Create new key, choisir le type JSON. Conserver la clé privée téléchargée de manière sécurisée pour son import ultérieur sur le firewall et éviter les copies de téléchargement non contrôlées.
Sous APIs & Services > Library, rechercher Admin SDK API et l’activer avec Enable.

⚠️ Si Service account key creation is disabled s’affiche, arrêter la configuration. Ne pas désactiver une règle d’organisation à l’échelle de toute l’organisation pour poursuivre ce guide. Le responsable de la sécurité Google doit approuver une exception limitée et documentée ; sinon, l’intégration reste bloquée. La configuration Sophos décrite ici nécessite un fichier de clé JSON ; aucun autre mode d’authentification n’est présenté comme un remplacement non vérifié.

Limiter la délégation à l’échelle du domaine

En tant que Super Admin autorisé, ouvrir Google Admin Console > Security > Access and data control > API controls.
Sous Domain-wide delegation > Manage domain wide delegation > Add new, saisir la valeur Unique ID du compte de service dans Client ID, et non l’ID du client Web OAuth.
Dans OAuth scopes (comma-delimited), saisir les deux scopes de lecture nécessaires :

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

Si WebAdmin doit également utiliser l’authentification Google, ajouter ce scope :

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

Enregistrer la délégation avec Authorize, puis vérifier l’ID et la liste complète des scopes.

Les URL des scopes sont des identifiants d’API fixes, et non des valeurs d’exemple. Si Multi-party approval est actif, un autre Super Admin doit approuver la délégation. Les modifications peuvent nécessiter jusqu’à 24 heures ; pendant ce délai, ne pas créer prématurément une seconde délégation avec des droits plus étendus. La délégation à l’échelle du domaine permet un accès au nom d’un utilisateur dans le tenant Workspace et constitue donc une autorisation sensible pour la sécurité, malgré les seuls droits de lecture. Désigner un responsable pour le compte de service, l’ID de clé, le compte administrateur délégué, la finalité et la date de révision.

Préparer des groupes distincts pour les administrateurs du firewall

Pour une mise en place claire, il est recommandé d’utiliser le mapping de groupes. Sous Google Admin Console > Directory > Groups, créer un groupe exclusivement destiné aux administrateurs du firewall et n’y ajouter que les administrateurs pilotes. Par exemple, un groupe SFOS-NOC-ReadOnly peut être associé à un profil en lecture seule préalablement vérifié. Le nom et l’adresse du groupe sont propres à l’organisation ; un groupe ordinaire d’employés ou d’utilisateurs VPN ne reçoit aucun droit WebAdmin.

Il est également possible d’attribuer des rôles administrateur Google personnalisés ou prédéfinis sous Account > Admin roles et d’utiliser Roles dans le serveur du firewall. Les rôles personnalisés sont associés au moyen du nom exact du rôle ; les rôles prédéfinis nécessitent leur valeur IdP spécifique, et non simplement le libellé affiché. Un exemple confirmé est Groups admin → _GROUPS_ADMIN_ROLE. Les rôles administrateur Google peuvent également donner des droits dans Google Admin Console. Ils ne doivent donc pas être attribués uniquement pour servir d’étiquette pratique sur le firewall ; un groupe dédié constitue généralement l’option la plus restrictive.

Configurer le serveur OIDC sur le firewall

Client, redirections et points de terminaison

Ouvrir WebAdmin via le FQDN prévu et accéder à Authentication > Servers > Add.
Sélectionner Server type: OpenID Connect, un Server name unique et IdP vendor: Google Workspace.
Saisir Client ID et Client secret du client Web OAuth.
Sous Redirect URIs, sélectionner Use firewall URL. Le firewall utilise le nom d’hôte de l’URL WebAdmin actuelle. Il est également possible de saisir son propre FQDN vérifié avec Enter manually.
Ouvrir Show URLs et copier les URL complètes pour Web admin console, Captive portal ou VPN portal and remote access, selon les services effectivement prévus.
Conserver la valeur Issuer URL définie automatiquement, https://accounts.google.com, et utiliser Discover/Reset endpoint URLs. Authorization URL, Token URL, Logout URL, JWKS URL et User info URL sont renseignées par découverte, et non déterminées au hasard.

Identité, groupe de repli et droits administrateur

Sous User attributes, Display name et Username prennent en charge les valeurs name ou email ; la valeur par défaut documentée est name dans les deux cas. Email address est prérempli avec email. Ce choix doit être fait avant la première connexion pilote : email peut simplifier l’association à une adresse de connexion Workspace unique, mais doit correspondre aux identités existantes sur le firewall. Ne pas modifier ultérieurement les valeurs des attributs sans planification, car cela peut entraîner d’autres associations de comptes.

Pour une utilisation exclusivement VPN ou Captive Portal, laisser IdP authentication for firewall administrators désactivé. Pour WebAdmin, activer délibérément cette option et créer chaque association avec IdP attribute, la valeur exacte IdP value et Device access profile. Reprendre les valeurs des groupes ou des rôles de sa propre configuration Google, sans les déduire du nom d’exemple.

Le firewall vérifie les règles de mapping de haut en bas et utilise le premier profil correspondant. Un utilisateur appartenant à plusieurs groupes administrateur doit donc faire l’objet d’un test explicite. Sans association administrateur correspondante, l’identité ne reçoit aucun accès WebAdmin et peut être créée comme utilisateur normal.

Sous Fallback group, choisir un groupe d’utilisateurs volontairement restreint. Si le groupe Google n’existe pas sur le firewall, ce groupe de repli est utilisé. Même lorsque le serveur est sélectionné sous Firewall authentication methods, Default group ne remplace pas cette affectation de repli OIDC. Un groupe VPN disposant de droits étendus n’est pas un groupe de repli sûr.

Vérifier le compte de service et harmoniser les noms d’hôte

Sous Service account credentials > Email address, saisir l’adresse du super-administrateur Google Workspace prévu pour cet accès. L’adresse e-mail du compte de service ne doit pas être saisie ici.
Sous JSON private key > Browse, sélectionner le fichier de clé JSON protégé du compte de service dédié.
Exécuter Test connection. Le test vérifie la connexion réseau et les autorisations de l’application. Il ne démontre pas encore que l’authentification des utilisateurs ou l’association des administrateurs est correcte.
Enregistrer avec Save.
Via Go to Admin and user settings, définir le même FQDN de portail sous When redirecting users to the captive portal or other interactive pages : Use the firewall’s configured hostname ou Use a different hostname, selon sa configuration. Enregistrer avec Apply.
Dans Google Cloud Console > APIs & Services > Credentials, ouvrir le client Web OAuth et saisir chaque URL de rappel complète précédemment copiée sous Authorized redirect URIs > Add URI. Enregistrer avec Save et comparer caractère par caractère.

Autoriser les groupes, les services et le VPN

Importer les groupes et attribuer les politiques

Sous Authentication > Servers, ouvrir Assistant for importing groups du serveur Google. Il est possible d’importer tous les groupes ou de cibler certains groupes à l’aide de Display name et Mail. Pour le pilote, sélectionner uniquement les groupes regroupant les utilisateurs nécessaires. Dans l’assistant, Surfing quota, Access time, Network traffic et Traffic shaping peuvent être attribués à tous les groupes ou à certains d’entre eux.

Le firewall et Google doivent avoir une heure synchronisée, faute de quoi l’importation des groupes peut déjà échouer. Après l’importation, vérifier les noms des groupes et les politiques prévues. Pour IPsec ou SSL VPN, les nouveaux groupes doivent également être ajoutés aux politiques VPN concernées. Une importation réussie ne constitue pas encore une autorisation VPN.

Modifier l’authentification pour chaque service

Sous Authentication > Services, sélectionner le serveur Google uniquement pour les méthodes nécessaires :

Administrator authentication methods: WebAdmin.
Firewall authentication methods: Captive Portal.
VPN portal authentication methods: VPN Portal.
VPN (IPsec/dial-in/L2TP/PPTP) authentication methods: accès distant IPsec ; le libellé de la liste ne signifie pas que chaque protocole hérité qui y figure est pris en charge pour OIDC.
SSL VPN authentication methods: accès distant SSL VPN.

Déplacer le serveur en tête de liste pour le service choisi et utiliser Apply pour chaque service. Vérifier l’ordre et le repli local par rapport à l’état précédemment documenté ; ne pas supprimer au passage Local pour les administrateurs locaux personnels. Les services non nécessaires restent inchangés.

Sophos Connect et accessibilité

Le SSO Google utilise également le port du VPN Portal pour les communications d’accès distant. Pour cet usage, l’accès au VPN Portal depuis le WAN doit être autorisé sous Administration > Device access > Local service ACL. Planifier délibérément les sources autorisées et l’accessibilité réellement nécessaire ; WebAdmin ne doit pas être ouvert sur le WAN à cette fin. Les restrictions sont décrites dans Device Access et Local Service ACL.

Avec un fichier de provisionnement, IPsec, SSL VPN et VPN Portal doivent utiliser le même serveur Google. La valeur gateway correspond au FQDN utilisé pour générer les redirections. Sans fichier de provisionnement, SSL VPN et VPN Portal doivent également utiliser le même serveur ; IPsec peut utiliser un autre serveur Google. Il ne faut donc pas se contenter de modifier aveuglément un champ d’authentification dans les fichiers VPN existants.

Après la mise en place ou la modification de la configuration Google, les utilisateurs Windows doivent réimporter leur fichier de configuration dans Sophos Connect 2.4 ou ultérieur. Une nouvelle connexion n’est testée qu’ensuite. Sur les terminaux partagés, imposer une nouvelle connexion SSO aux utilisateurs suivants ; une session Google existante ne doit pas connecter la personne suivante à son insu.

Facultatif : utiliser Captive Portal de manière sécurisée

La règle de firewall correspondante, basée sur les utilisateurs, nécessite Match known users et Use web authentication for unknown users. Sous Authentication > Web authentication > Captive portal behavior, pour ce parcours de portail, activer Show web page after sign-in, sélectionner In new browser window et désactiver Use insecure HTTP instead of HTTPS. Enregistrer avec Apply ; OIDC ne prend pas en charge ce mode HTTP non sécurisé.

Les utilisateurs laissent la fenêtre Captive Portal ouverte pour se déconnecter explicitement. L’inactivité ou la fermeture d’un onglet ne met pas fin à la session SSO Google dans ce cas, contrairement à d’autres méthodes de portail. Après la déconnexion, la page de déconnexion Google reste visible. Credential login avec nom d’utilisateur et mot de passe ne remplace pas ce flux Google OIDC basé sur des jetons.

Valider l’authentification et les autorisations

La validation distingue connexion, identité et autorisation. Tous les tests sont consignés avec l’heure, le compte, le service, la version du client et le résultat attendu, sans enregistrer de secrets ni de jetons.

Terminer avec succès Test connection et l’importation ciblée des groupes. Ouvrir ensuite une fenêtre de navigation privée via le FQDN prévu.
Connecter un administrateur pilote via Google et vérifier l’exigence de MFA attendue. Sous Authentication > Users, l’identité, le statut administrateur et le profil attribué doivent être corrects.
Vérifier que les menus nécessaires sont accessibles et qu’une zone interdite ne l’est pas. Un compte en lecture seule ne doit pas pouvoir enregistrer de modification. Un compte VPN normal ne doit pas pouvoir se connecter à WebAdmin.
Vérifier un compte correspondant à plusieurs règles de mapping. Le profil doit correspondre à la première règle applicable documentée, et non au rôle supposé le plus puissant.
Se connecter séparément au VPN Portal et établir un tunnel IPsec ou SSL VPN avec la configuration Sophos Connect nouvellement importée. Une ressource interne autorisée doit être accessible ; une ressource non autorisée doit rester bloquée.
Se déconnecter et vérifier à nouveau avec une nouvelle session. La connexion Google, l’accès au portail et le tunnel VPN sont des critères de réussite distincts.
Corréler les événements WebAdmin dans Log viewer > Admin et les connexions Captive Portal, VPN Portal, IPsec et SSL VPN dans Log viewer > Authentication. Pour une analyse plus poussée, oauth_sso_svc.log est disponible dans Advanced Shell ; aucune commande de débogage ou de redémarrage n’est requise à cette fin.
Vérifier à nouveau l’accès local indépendant de récupération avant de migrer d’autres utilisateurs.

Les comptes administrateur ne sont créés ou mis à jour qu’après une connexion WebAdmin réussie. Une connexion VPN ou Captive Portal ne synchronise aucun rôle administrateur. Les modifications des rôles Google doivent donc être validées par une nouvelle connexion à WebAdmin, et non sur la base d’un tunnel établi avec succès.

Cibler le diagnostic des erreurs

Google signale redirect_uri_mismatch

Comparer l’URL complète concernée dans Show URLs avec Authorized redirect URIs du client OAuth réellement utilisé : le schéma, le FQDN, le port et le chemin doivent correspondre exactement. Vérifier ensuite que le navigateur utilise le même nom d’hôte et que la redirection automatique vers le portail pointe vers ce nom. Après correction, tester une nouvelle authentification ; ni les redirections avec caractères génériques ni le passage à une adresse IP ne constituent une solution.

Test connection ou l’importation des groupes échoue

Vérifier d’abord l’heure système et la connexion réseau. Contrôler ensuite Admin SDK API, la validité du fichier de clé JSON, le compte Super Admin délégué correct ainsi que Domain-wide delegation, avec l’ID numérique du compte de service et les scopes nécessaires. Si des groupes manquent, vérifier également le filtre d’importation Display name/Mail. Une erreur ne se résout pas en attribuant globalement des droits Cloud Owner ou en ajoutant des scopes d’écriture.

La connexion Google fonctionne, mais WebAdmin refuse l’accès

Vérifier l’appartenance aux groupes ou l’attribution des rôles dans Google, IdP authentication for firewall administrators, la valeur exacte IdP value, l’ordre des règles de mapping et le Device access profile local. Effectuer ensuite une nouvelle connexion à WebAdmin et consulter Log viewer > Admin. Une connexion VPN préalable ne prouve ni le bon fonctionnement du mapping ni la mise à jour de l’administrateur.

Le portail fonctionne, mais pas le tunnel ou la ressource interne

Vérifier les versions de Windows et de Sophos Connect, le fichier de configuration nouvellement importé, l’accessibilité du VPN Portal et l’affectation du serveur pour chaque service. Contrôler ensuite l’appartenance des groupes aux politiques VPN et les règles applicables à la ressource cible. Log viewer > Authentication montre l’authentification ; une entrée d’authentification réussie ne démontre pas, à elle seule, que le trafic de données est autorisé.

Context-Aware Access ou la réauthentification se comporte autrement que prévu

Les conditions Google CAA basées sur l’appareil nécessitent un flux de navigateur pris en charge et des données de vérification du terminal effectivement disponibles. Pour la procédure de vérification décrite, utiliser Google Chrome avec Endpoint Verification. Une connexion Sophos Connect réussie n’est pas considérée comme une preuve que chaque condition CAA basée sur l’appareil a été évaluée.

CAA est évalué lors de l’authentification et ne met pas fin à une session de firewall déjà active. L’intervalle de réauthentification Google n’impose pas non plus une nouvelle connexion à une session VPN active sur le firewall. Vérifier une nouvelle authentification après une déconnexion contrôlée ou une interruption contrôlée du tunnel ; les sessions existantes doivent être traitées séparément lors du départ d’un utilisateur.

Exploitation, retrait des accès et retour arrière

Toute modification des groupes ou des rôles doit être vérifiée avec une nouvelle authentification et des tests positifs et négatifs. Lorsqu’une personne est retirée de l’administration, la modification de son rôle Google ne suffit pas : SFOS ne reconvertit pas automatiquement un compte administrateur existant en utilisateur normal. Après vérification des dépendances et avec un autre administrateur opérationnel, supprimer le compte administrateur concerné sur le firewall. Lors de la prochaine connexion normale, le firewall peut recréer l’utilisateur. Les sessions WebAdmin et VPN actives sont contrôlées et terminées séparément ; le retrait d’un groupe ne constitue pas une révocation immédiate démontrée des sessions.

Définir un responsable, un stockage sécurisé, une révision et une rotation pour le secret OAuth et la clé du compte de service. Lors d’une rotation planifiée, l’ancienne clé ne reste disponible que pendant la durée exigée par la procédure de retour arrière documentée. Vérifier d’abord les nouveaux identifiants avec Test connection, la récupération des groupes et une nouvelle authentification, avant de révoquer les anciens identifiants. En revanche, une compromission est traitée selon la procédure interne de gestion des incidents ; elle ne doit pas être prolongée pour faciliter un retour arrière.

Si le pilote échoue, restaurer depuis la session ouverte disposant de tous les droits administrateur ou depuis l’accès local de récupération l’affectation précédente des services et l’ordre des serveurs exactement tels qu’ils ont été notés. Rétablir également les noms d’hôte des portails, Device Access, les politiques de groupes et de VPN ainsi que les mappings administrateur modifiés dans leur état antérieur respectif. Tester ensuite la connexion administrateur locale et l’accès VPN précédent dans de nouvelles sessions.

En complément, utiliser l’accès indépendant disposant de tous les droits administrateur pour comparer chaque compte concerné sous Authentication > Users à l’inventaire individuel des comptes. Pour les comptes qui existaient déjà, rétablir explicitement le User type antérieur, le Profile attribué et le statut du compte ; si cela nécessite une suppression puis une recréation, vérifier au préalable toutes les dépendances et sauvegarder les affectations antérieures. Supprimer uniquement les objets administrateur ou utilisateur créés pendant le pilote, après avoir vérifié leurs dépendances aux groupes, aux VPN, aux politiques et à tout autre élément. Le rétablissement du mapping du serveur ou le retrait d’un rôle Google ne remplace pas cette remise en état des comptes et ne met fin à aucune session existante. Les sessions WebAdmin, de portail et VPN actives sont donc vérifiées et terminées séparément. Enfin, vérifier dans de nouvelles sessions que l’accès administrateur local et l’accès VPN antérieurs fonctionnent, et qu’une identité pilote qui n’est plus autorisée se voit refuser l’accès ; pour les comptes préexistants rétablis, vérifier le maintien des droits initiaux et le refus des droits supplémentaires accordés uniquement pendant le pilote.

Ce n’est qu’une fois le retour arrière opérationnel et après confirmation qu’aucun autre service n’en dépend que les URI de redirection, les autorisations de délégation et les identifiants créés uniquement pour le pilote sont supprimés de manière contrôlée. Ne pas supprimer de clients ou de comptes de service partagés sans vérifier les dépendances. Une sauvegarde complète de la configuration ne doit être restaurée que pendant la fenêtre de récupération approuvée, car elle peut également annuler des modifications indépendantes du firewall.