Configurar Google Workspace OIDC en Sophos Firewall

Con SFOS 23.0, se puede configurar Google Workspace como proveedor de identidad OpenID Connect (OIDC) para WebAdmin, Captive Portal, VPN Portal y el acceso remoto mediante IPsec y SSL VPN. Google verifica la identidad; además, el firewall consulta las pertenencias a grupos y aplica sus propios permisos de usuario, VPN y administrador. Por tanto, iniciar sesión correctamente en Google no concede por sí solo acceso de administrador ni acceso a una red interna.

Procedimiento rápido: Preparar un cliente web OAuth de Google y una cuenta de servicio delegada, crear un servidor OpenID Connect con IdP vendor: Google Workspace en Authentication > Servers, registrar en Google las URL de callback que se muestran allí, importar los grupos y cambiar únicamente los servicios necesarios en Authentication > Services. Después, comprobar el inicio de sesión, los permisos y los registros con una cuenta piloto. Se conserva el acceso local de emergencia previamente probado.

Esta guía describe la configuración de SFOS 23; no garantiza la compatibilidad con una compilación de firmware publicada concreta. Antes de una actualización, se aplica la propia planificación de firmware y copias de seguridad. Chromebook SSO y Google Directory Sync para Sophos Fusion son otras integraciones y no sustituyen a este servidor OIDC del firewall.

Requisitos previos y límites de seguridad

Definir responsabilidades y guardar la configuración existente

Se necesita un proyecto de Google Cloud, una cuenta de Google Workspace con acceso Super Admin para la configuración y un administrador del firewall. Cloud Console gestiona el cliente OAuth, las API y la cuenta de servicio; Google Admin Console gestiona los usuarios, los grupos y Domain-wide delegation.

Antes de la prueba piloto, se preparan una copia de seguridad de la configuración y un acceso local de recuperación probado. Además, se anotan los servidores de autenticación existentes y su orden para cada servicio, los nombres de host de los portales, las autorizaciones de Device Access, las asignaciones de grupos y VPN, y los perfiles de administrador existentes. Durante el cambio, se mantiene disponible una sesión abierta con permisos completos de administrador; debido a los posibles tiempos de espera de sesión, esta no sustituye al segundo acceso.

Antes del primer inicio de sesión piloto, se documenta para cada identidad local afectada en Authentication > Users si la cuenta ya existe, así como su User type anterior, el Profile asignado y el estado de la cuenta. Este registro individual de cuentas forma parte del estado previo: un cambio posterior en la asignación del IdP o en el rol de Google no restablece automáticamente las cuentas de administrador locales existentes.

Para planificar los permisos, siguen siendo aplicables los administradores personales y perfiles de Device Access. Google SSO no sustituye al principio de mínimo privilegio ni a la restricción de los orígenes de administración.

Utilizar un nombre de host uniforme

El nombre del portal debe pertenecer a un dominio registrable con un TLD público. Un nombre aislado como firewall o un dominio local como firewall.local no es adecuado para las redirecciones OAuth de Google. Se utiliza el mismo FQDN para el acceso al portal, las URI de redirección y las redirecciones automáticas al portal. La resolución DNS y un certificado HTTPS de confianza que corresponda al nombre se comprueban desde las redes de cliente que se utilizan realmente.

fw.example.com se utiliza aquí únicamente como ejemplo de documentación y debe sustituirse por el FQDN válido propio. No es una URI de redirección lista para usar. La ruta de callback y el puerto del servicio se copiarán más adelante sin cambios desde Show URLs, y no se construirán a partir de un ejemplo. En este procedimiento se utiliza un FQDN, no una dirección IP, incluso cuando se introduce manualmente.

Comprobar los límites antes del cambio

Solo se puede seleccionar un servidor IdP OIDC para cada servicio de autenticación. Por tanto, una asignación existente de Entra no se complementa de forma incidental, sino que se sustituye deliberadamente o se mantiene sin cambios.
Los usuarios de un mismo dominio no pueden sincronizarse simultáneamente mediante Active Directory y Google Workspace. Los usuarios y grupos existentes necesitan objetos de Google correspondientes; los objetos antiguos que no puedan asociarse siguen gestionándose manualmente.
La MFA propia del firewall no se utiliza para Google OIDC. El requisito de MFA se configura en Google y se comprueba realmente durante la prueba piloto. Las cuentas locales de emergencia mantienen su propia protección.
En un clúster HA, Google SSO no admite actualmente el inicio de sesión en WebAdmin del dispositivo auxiliar. Para ello, sigue siendo necesaria una vía de administración local independiente.
Para Google SSO con Sophos Connect, se contemplan Windows y la versión 2.4 o posterior del cliente. La compatibilidad de Entra con macOS no implica compatibilidad con Google Workspace.

Solo si se va a utilizar Context-Aware Access (CAA): Antes de la prueba piloto, se comprueba que cada usuario previsto dispone de una licencia o edición compatible con CAA, que la aplicación concreta y el flujo de inicio de sesión son compatibles y que la política deseada está realmente asignada a la aplicación y al grupo de usuarios o unidad organizativa. Los usuarios con otras ediciones no están sujetos a la política CAA, aunque esta se dirija al mismo grupo o unidad organizativa; Endpoint Verification por sí solo no demuestra que el usuario tenga derecho a utilizar CAA. CAA es opcional y no constituye un requisito de licencia prémium para el uso habitual de Google OIDC. La documentación de Google sobre SAML no demuestra la compatibilidad del flujo OIDC de Sophos. Antes de autorizar el uso, se demuestra el efecto deseado mediante pruebas positivas y negativas con nuevos inicios de sesión para la aplicación, los usuarios y las condiciones concretos; la falta de compatibilidad o un inicio de sesión inesperadamente correcto en una prueba negativa impiden autorizar el flujo protegido por CAA.

Preparar Google Workspace

Crear el cliente web OAuth

Seleccionar el proyecto correcto en Google Cloud Console > APIs & Services > Credentials. Si Google solicita primero configurar la pantalla de consentimiento OAuth, completar la configuración para la propia organización y el conjunto de usuarios autorizado; no crear una autorización externa general solo para la prueba.
Abrir Create credentials > OAuth client ID y seleccionar Application type: Web application.
Asignar un nombre identificable, por ejemplo SFOS-Google-SSO-Pilot, y crear el cliente.
Guardar inmediatamente Client ID y Client secret en un almacén de secretos autorizado. El secreto no se copia en capturas de pantalla, tickets ni documentación del cambio.

El ID del cliente OAuth identifica al firewall durante el inicio de sesión. No es el ID numérico de la cuenta de servicio que se necesitará más adelante para la delegación. Las URI de redirección se añaden únicamente cuando el firewall las haya generado.

Configurar la cuenta de servicio y la consulta de grupos

El inicio de sesión y la consulta de grupos utilizan credenciales diferentes: el cliente OAuth sirve para el inicio de sesión interactivo; la cuenta de servicio permite al firewall consultar información de Google Directory. Google no proporciona las pertenencias a grupos simplemente como parte de la respuesta normal de inicio de sesión OIDC.

Crear una cuenta dedicada a esta integración en Google Cloud Console > IAM & admin > Service accounts > Create service account, por ejemplo sfos-directory-reader.
No conceder roles generales Owner o Editor como supuesto requisito previo. Los permisos IAM adicionales solo se autorizan para una tarea cuya necesidad esté demostrada.
Anotar el valor numérico de Unique ID en los detalles de la cuenta de servicio.
Seleccionar el tipo JSON en Keys > Add key > Create new key. Guardar de forma protegida la clave privada descargada para cargarla posteriormente en el firewall y evitar copias de descarga sin control.
Buscar Admin SDK API en APIs & Services > Library y activarla con Enable.

⚠️ Si aparece Service account key creation is disabled, se detiene la configuración. No se desactiva una política de organización para toda la organización con el fin de continuar esta guía. El responsable de seguridad de Google debe autorizar una excepción limitada y documentada; de lo contrario, la integración permanece bloqueada. La configuración de Sophos descrita aquí requiere un archivo de clave JSON; no se presenta otro tipo de autenticación como sustituto sin verificar.

Limitar Domain-wide delegation

Como Super Admin autorizado, abrir Google Admin Console > Security > Access and data control > API controls.
En Domain-wide delegation > Manage domain wide delegation > Add new, introducir el valor de Unique ID de la cuenta de servicio como Client ID, no el ID del cliente web OAuth.
En OAuth scopes (comma-delimited), introducir los dos ámbitos de lectura necesarios:

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

Si WebAdmin también va a autenticarse mediante Google, añadir este ámbito:

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

Guardar la delegación con Authorize y comprobar el ID y la lista completa de ámbitos.

Las URL de los ámbitos son identificadores fijos de API, no valores de ejemplo. Si Multi-party approval está activo, otro Super Admin debe aprobar la delegación. Los cambios pueden tardar hasta 24 horas; durante ese tiempo, no se crea precipitadamente una segunda delegación con permisos más amplios. Domain-wide delegation permite el acceso en nombre de otros usuarios dentro del tenant de Workspace y, por tanto, constituye una autorización relevante para la seguridad, aunque los permisos sean de lectura. Se asigna un responsable identificado para la cuenta de servicio, el ID de clave, la cuenta de administrador utilizada para la delegación, la finalidad y la fecha de revisión.

Preparar grupos separados de administradores del firewall

Para empezar de forma clara, se recomienda la asignación mediante grupos. En Google Admin Console > Directory > Groups, crear un grupo exclusivo para administradores del firewall y añadir únicamente a los administradores piloto. Por ejemplo, un grupo SFOS-NOC-ReadOnly puede asociarse a un perfil de solo lectura previamente comprobado. El nombre y la dirección del grupo son valores propios de la organización; un grupo normal de empleados o de VPN no recibe permisos de WebAdmin.

Como alternativa, se pueden asignar roles de administrador de Google personalizados o predefinidos en Account > Admin roles y utilizar Roles en el servidor del firewall. Los roles personalizados se asignan mediante el nombre exacto del rol; los roles predefinidos requieren su valor IdP específico, no simplemente el nombre visible. Un ejemplo confirmado es Groups admin → _GROUPS_ADMIN_ROLE. Los roles de administrador de Google también pueden conceder permisos en Google Admin Console. Por ello, no se asignan únicamente como una etiqueta práctica para el firewall; un grupo dedicado suele ser la opción más restrictiva.

Configurar el servidor OIDC en el firewall

Cliente, redirecciones y endpoints

Abrir WebAdmin mediante el FQDN previsto y acceder a Authentication > Servers > Add.
Seleccionar Server type: OpenID Connect, un Server name único e IdP vendor: Google Workspace.
Introducir Client ID y Client secret del cliente web OAuth.
En Redirect URIs, seleccionar Use firewall URL. El firewall utiliza el nombre de host de la URL actual de WebAdmin. Como alternativa, introducir el FQDN propio comprobado mediante Enter manually.
Abrir Show URLs y copiar las URL completas de Web admin console, Captive portal o VPN portal and remote access correspondientes a los servicios que se prevé utilizar realmente.
Mantener la Issuer URL https://accounts.google.com establecida automáticamente y utilizar Discover/Reset endpoint URLs. Authorization URL, Token URL, Logout URL, JWKS URL y User info URL se completan mediante Discovery, no se adivinan.

Identidad, grupo alternativo y permisos de administrador

En User attributes, Display name y Username admiten los valores name o email; el valor predeterminado documentado es name en ambos casos. Email address tiene predefinido email. La decisión se toma antes del primer inicio de sesión piloto: email puede facilitar la asociación con una dirección única de inicio de sesión de Workspace, pero debe ser compatible con las identidades existentes en el firewall. Los valores de los atributos no se cambian posteriormente de forma incidental, ya que ello puede generar otras asociaciones de cuentas.

Para un uso exclusivo de VPN o Captive Portal, IdP authentication for firewall administrators permanece desactivado. Para WebAdmin, se activa deliberadamente la opción y se crea cada asignación con IdP attribute, el IdP value exacto y Device access profile. Los valores de grupos o roles se toman de la configuración propia de Google, no se deducen del nombre del ejemplo.

El firewall comprueba las reglas de asignación de arriba abajo y utiliza el primer perfil que coincida. Por tanto, un usuario que pertenezca a varios grupos de administradores debe probarse expresamente. Sin una asignación de administrador coincidente, la identidad no obtiene acceso a WebAdmin y puede crearse como usuario normal.

En Fallback group, seleccionar un grupo de usuarios deliberadamente restringido. Si el grupo de Google no existe en el firewall, se utiliza este grupo alternativo. Aunque el servidor esté seleccionado en Firewall authentication methods, Default group no sustituye a esta asignación de grupo alternativo OIDC. Un grupo VPN con permisos amplios no es un destino alternativo seguro.

Comprobar la cuenta de servicio y unificar los nombres de host

En Service account credentials > Email address, introducir la dirección del superadministrador de Google Workspace previsto para este acceso. Aquí no se introduce la dirección de correo electrónico de la cuenta de servicio.
En JSON private key > Browse, seleccionar el archivo de clave JSON protegido de la cuenta de servicio dedicada.
Ejecutar Test connection. La prueba comprueba la conexión de red y los permisos de la aplicación. Todavía no demuestra que el inicio de sesión del usuario o la asignación de administrador sean correctos.
Guardar con Save.
Mediante Go to Admin and user settings, establecer el mismo FQDN del portal en When redirecting users to the captive portal or other interactive pages: Use the firewall’s configured hostname o Use a different hostname, según la configuración propia. Guardar con Apply.
En Google Cloud Console > APIs & Services > Credentials, abrir el cliente web OAuth e introducir cada URL de callback completa copiada anteriormente en Authorized redirect URIs > Add URI. Guardar con Save y comparar carácter por carácter.

Habilitar grupos, servicios y VPN

Importar grupos y asignar políticas

En Authentication > Servers, abrir Assistant for importing groups del servidor de Google. Se pueden importar todos los grupos o seleccionar grupos mediante Display name y Mail. Para la prueba piloto, se selecciona únicamente el conjunto de usuarios necesario. En el asistente, se pueden asignar Surfing quota, Access time, Network traffic y Traffic shaping a todos los grupos o a grupos individuales.

El firewall y Google deben tener la hora sincronizada; de lo contrario, incluso la importación de grupos puede fallar. Tras la importación, comprobar los nombres de los grupos y las políticas previstas. Para IPsec o SSL VPN, los nuevos grupos también deben añadirse a las políticas VPN correspondientes. Una importación correcta todavía no concede permisos de VPN.

Cambiar la autenticación por servicio

En Authentication > Services, seleccionar el servidor de Google únicamente en los métodos necesarios:

Administrator authentication methods: WebAdmin.
Firewall authentication methods: Captive Portal.
VPN portal authentication methods: VPN Portal.
VPN (IPsec/dial-in/L2TP/PPTP) authentication methods: acceso remoto IPsec; el nombre de la lista no implica compatibilidad OIDC con todos los protocolos heredados que aparecen en ella.
SSL VPN authentication methods: acceso remoto SSL VPN.

Arrastrar el servidor al principio de la lista para el servicio seleccionado y utilizar Apply en cada servicio. Se comprueban el orden y la alternativa local frente al estado documentado anteriormente; Local no se elimina de forma incidental para los administradores locales personales. Los servicios no necesarios permanecen sin cambios.

Sophos Connect y accesibilidad

Google SSO utiliza el puerto de VPN Portal también para la comunicación de acceso remoto. Para este uso, debe permitirse el acceso a VPN Portal desde WAN en Administration > Device access > Local service ACL. Para ello, se planifican deliberadamente los orígenes permitidos y la accesibilidad realmente necesaria; no se abre WebAdmin en WAN para este fin. La restricción se describe en Device Access y Local Service ACL.

Con un archivo de aprovisionamiento, IPsec, SSL VPN y VPN Portal deben utilizar el mismo servidor de Google. El valor gateway corresponde al FQDN con el que se generaron las redirecciones. Sin un archivo de aprovisionamiento, SSL VPN y VPN Portal también deben utilizar el mismo servidor; IPsec puede utilizar otro servidor de Google. Por tanto, no se modifica a ciegas únicamente un campo de autenticación en los archivos VPN existentes.

Tras configurar o modificar la configuración de Google, los usuarios de Windows deben volver a importar su archivo de configuración en Sophos Connect 2.4 o posterior. Solo entonces se prueba una conexión nueva. En endpoints compartidos, debe forzarse un nuevo inicio de sesión SSO para los usuarios posteriores; una sesión de Google existente no debe iniciar inadvertidamente la sesión de la siguiente persona.

Opcional: utilizar Captive Portal de forma segura

La regla de firewall basada en usuarios correspondiente requiere Match known users y Use web authentication for unknown users. En Authentication > Web authentication > Captive portal behavior, para este flujo del portal, activar Show web page after sign-in, seleccionar In new browser window y desactivar Use insecure HTTP instead of HTTPS. Guardar con Apply; OIDC no admite este modo HTTP inseguro.

Los usuarios mantienen abierta la ventana de Captive Portal para cerrar la sesión explícitamente. En este caso, la inactividad o el cierre de una pestaña no finalizan la sesión de Google SSO como ocurre con otros métodos del portal. Tras cerrar la sesión, la página de cierre de sesión de Google permanece visible. Credential login con nombre de usuario y contraseña no sustituye a este proceso de Google OIDC basado en tokens.

Validar el inicio de sesión y los permisos

La validación distingue entre conexión, identidad y autorización. Todas las pruebas se registran con la hora, la cuenta, el servicio, la versión del cliente y el resultado esperado, sin registrar secretos ni tokens.

Completar correctamente Test connection y la importación selectiva de grupos. Después, abrir una ventana privada del navegador mediante el FQDN previsto.
Iniciar sesión con un administrador piloto mediante Google y comprobar el requisito de MFA esperado. En Authentication > Users, la identidad, el estado de administrador y el perfil asignado deben ser correctos.
Comprobar positivamente los menús necesarios y realizar una prueba negativa en un área bloqueada. Una cuenta de solo lectura no debe poder guardar cambios. Una cuenta VPN normal no debe poder iniciar sesión en WebAdmin.
Comprobar una cuenta que coincida con varias reglas de asignación. El perfil debe corresponder a la primera regla coincidente documentada, no al rol supuestamente más potente.
Iniciar sesión por separado en VPN Portal y establecer un túnel IPsec o SSL VPN con la configuración de Sophos Connect recién importada. Un recurso interno autorizado debe ser accesible; un recurso no autorizado debe permanecer bloqueado.
Cerrar la sesión y volver a comprobar con una sesión nueva. El inicio de sesión en Google, el acceso al portal y el túnel VPN son criterios de éxito independientes.
Correlacionar los eventos de WebAdmin en Log viewer > Admin y los inicios de sesión de Captive Portal, VPN Portal, IPsec y SSL VPN en Log viewer > Authentication. Para un análisis más detallado, está disponible oauth_sso_svc.log en Advanced Shell; no se requieren comandos de depuración ni de reinicio para ello.
Volver a comprobar el acceso local de recuperación independiente antes de migrar a más usuarios.

Las cuentas de administrador solo se crean o actualizan tras un inicio de sesión correcto en WebAdmin. Un inicio de sesión en VPN o Captive Portal no sincroniza ningún rol de administrador. Por tanto, los cambios de roles de Google se validan mediante un nuevo inicio de sesión en WebAdmin, no a partir de un túnel establecido correctamente.

Delimitar los errores de forma específica

Google muestra redirect_uri_mismatch

Comparar la URL completa afectada de Show URLs con Authorized redirect URIs del cliente OAuth que se utiliza realmente: el esquema, el FQDN, el puerto y la ruta deben coincidir exactamente. Después, comprobar si el navegador utiliza el mismo nombre de host y si la redirección automática al portal apunta a ese nombre. Tras la corrección, probar un nuevo inicio de sesión; ni las redirecciones con comodines ni el cambio a una IP son la solución.

Fallan Test connection o la importación de grupos

Comprobar primero la hora del sistema y la conexión de red. Después, verificar Admin SDK API, la validez del archivo de clave JSON, la cuenta correcta de Super Admin utilizada para la delegación, y Domain-wide delegation con el ID numérico de la cuenta de servicio y los ámbitos necesarios. Si faltan grupos, comprobar también el filtro de importación Display name/Mail. Un error no se soluciona mediante permisos generales de Cloud Owner ni ámbitos de escritura adicionales.

El inicio de sesión en Google funciona, pero WebAdmin lo rechaza

Comprobar la pertenencia a grupos o la asignación de roles en Google, IdP authentication for firewall administrators, el IdP value exacto, el orden de asignación y el Device access profile local. Después, realizar un nuevo inicio de sesión en WebAdmin y revisar Log viewer > Admin. Un inicio de sesión VPN anterior no demuestra ni la asignación ni la actualización del administrador.

El portal funciona, pero el túnel o el recurso interno no

Comprobar las versiones de Windows y Sophos Connect, el archivo de configuración recién importado, la accesibilidad de VPN Portal y la asignación de servidor por servicio. Después, comprobar la pertenencia a grupos en las políticas VPN y las reglas para el recurso de destino. Log viewer > Authentication muestra el inicio de sesión; una entrada de autenticación correcta no demuestra por sí sola que se permita el tráfico de datos.

Context-Aware Access o el nuevo inicio de sesión se comportan de forma distinta a la esperada

Las condiciones de Google CAA basadas en el dispositivo necesitan un proceso de navegador compatible y datos de verificación del endpoint realmente disponibles. Para el procedimiento de comprobación descrito, se utiliza Google Chrome con Endpoint Verification. Un inicio de sesión correcto en Sophos Connect no se considera prueba de que se hayan evaluado todas las condiciones CAA basadas en el dispositivo.

CAA se evalúa durante la autenticación y no finaliza una sesión de firewall ya activa. Tampoco el intervalo de reautenticación de Google fuerza un nuevo inicio de sesión en una sesión VPN activa del firewall. Se comprueba una nueva autenticación tras cerrar la sesión o desconectar de forma controlada; las sesiones existentes deben tratarse por separado al dar de baja a un usuario.

Operación, baja de usuarios y reversión

Los cambios en grupos o roles se comprueban mediante un nuevo inicio de sesión y pruebas positivas y negativas. Al retirar a una persona de la administración, el cambio de rol en Google no basta por sí solo: SFOS no convierte automáticamente una cuenta de administrador existente de nuevo en un usuario normal. Tras comprobar las dependencias y con otro administrador operativo, debe eliminarse del firewall la cuenta de administrador correspondiente. En el siguiente inicio de sesión normal, el firewall puede volver a crear al usuario. Las sesiones activas de WebAdmin y VPN se comprueban y finalizan por separado; retirar a un usuario de un grupo no constituye una revocación inmediata de sesión demostrada.

Para el secreto OAuth y la clave de la cuenta de servicio, se definen el responsable, el almacenamiento seguro, la revisión y la rotación. En una rotación planificada, la clave antigua permanece disponible únicamente durante el tiempo que requiera el procedimiento de reversión documentado. Las nuevas credenciales se comprueban primero mediante Test connection, la consulta de grupos y un nuevo inicio de sesión, antes de revocar las credenciales antiguas. En cambio, una vulneración se gestiona conforme al propio proceso de respuesta a incidentes, sin prolongarla para facilitar una reversión cómoda.

Si la prueba piloto falla, desde la sesión abierta con permisos completos de administrador o el acceso local de recuperación se restablecen la asignación previa de servicios y el orden de servidores anotados exactamente. Asimismo, los nombres de host de portal, Device Access, las políticas de grupos/VPN y las asignaciones de administrador modificados se restablecen a sus respectivos estados anteriores. Después, se prueban el inicio de sesión del administrador local y la vía VPN anterior en sesiones nuevas.

Además, mediante el acceso independiente disponible con permisos completos de administrador, se compara cada cuenta afectada en Authentication > Users con el registro individual de cuentas. En las cuentas que ya existían, se restablecen expresamente el User type anterior, el Profile asignado y el estado de la cuenta; si para ello es necesario eliminar y volver a crear una cuenta, primero se comprueban todas sus dependencias y se guardan sus asignaciones anteriores. Solo se eliminan los objetos de administrador o usuario creados durante la prueba piloto, tras comprobar sus dependencias de grupos, VPN, políticas y cualquier otra dependencia. Restablecer la asignación del servidor o retirar un rol de Google no sustituye esta limpieza de cuentas ni finaliza ninguna sesión existente. Por ello, las sesiones activas de WebAdmin, de los portales y de VPN se comprueban y finalizan por separado. Por último, se demuestra en sesiones nuevas que funcionan el acceso local de administrador y la vía VPN anteriores, y que se rechaza una identidad piloto que ya no está autorizada; en las cuentas preexistentes restablecidas, se comprueban los permisos originales y la denegación de los permisos adicionales concedidos únicamente durante la prueba piloto.

Solo cuando la reversión funciona y ningún otro servicio depende de ellos, se eliminan de forma controlada las URI de redirección, las autorizaciones de delegación y las credenciales creadas exclusivamente para la prueba piloto. Los clientes o las cuentas de servicio compartidos no se eliminan sin comprobar sus dependencias. Una copia de seguridad completa de la configuración solo se restaura dentro de la ventana de recuperación autorizada, ya que también puede revertir cambios independientes del firewall.