Configurar Google Workspace OIDC na Sophos Firewall

Com o SFOS 23.0, é possível configurar o Google Workspace como fornecedor de identidade OpenID Connect (OIDC) para WebAdmin, Captive Portal, VPN Portal, Remote Access IPsec e SSL VPN. O Google verifica a identidade; a firewall consulta adicionalmente as associações a grupos e aplica as suas próprias permissões de utilizador, VPN e administrador. Por isso, uma autenticação bem-sucedida no Google não concede, por si só, acesso de administrador nem acesso a uma rede interna.

Procedimento rápido: Preparar um cliente web OAuth do Google e uma conta de serviço com delegação, criar um servidor OpenID Connect com IdP vendor: Google Workspace em Authentication > Servers, registar no Google os URL de callback apresentados nesse local, importar os grupos e alterar apenas os serviços necessários em Authentication > Services. Em seguida, verificar a autenticação, as permissões e os registos com uma conta piloto. O acesso de emergência local previamente testado é mantido.

Este guia descreve a configuração do SFOS 23, não constitui uma garantia relativa a uma determinada compilação de firmware disponibilizada. Antes de uma atualização, aplica-se o planeamento de firmware e cópias de segurança da organização. O SSO para Chromebook e o Google Directory Sync para Sophos Fusion são outras integrações e não substituem este servidor OIDC da firewall.

Pré-requisitos e limites de segurança

Definir responsabilidades e salvaguardar a configuração existente

São necessários um projeto Google Cloud, uma conta Google Workspace com acesso Super Admin para a configuração e um administrador da firewall. A Cloud Console gere o cliente OAuth, as API e a conta de serviço; a Google Admin Console gere os utilizadores, os grupos e a delegação ao nível do domínio.

Antes do piloto, devem ser preparados uma cópia de segurança da configuração e um acesso local de recuperação testado. Além disso, devem ser registados os servidores de autenticação existentes e a sua ordem por serviço, os nomes de anfitrião dos portais, as autorizações de Device Access, as atribuições de grupos e VPN e os perfis de administrador existentes. Deve permanecer disponível uma sessão aberta com privilégios de administrador completos durante a alteração; devido a possíveis expirações por inatividade, esta sessão não substitui o segundo acesso.

Para cada identidade local afetada, antes da primeira autenticação piloto, regista-se em Authentication > Users se a conta já existe, bem como o seu User type anterior, o Profile atribuído e o estado da conta. Este levantamento individual das contas faz parte do estado anterior documentado: uma alteração posterior ao mapeamento do IdP ou à função Google não repõe automaticamente o estado anterior das contas de administrador locais existentes.

Para o planeamento de permissões, continuam a aplicar-se os administradores pessoais e perfis de Device Access. O SSO do Google não substitui o princípio do menor privilégio nem a restrição das origens de gestão.

Utilizar um nome de anfitrião uniforme

O nome do portal tem de pertencer a um domínio registável com um TLD público. Um nome isolado como firewall ou um domínio local como firewall.local não é adequado para redirecionamentos OAuth do Google. Deve ser utilizado o mesmo FQDN para o acesso ao portal, os URI de redirecionamento e os redirecionamentos automáticos do portal. A resolução DNS e um certificado HTTPS de confiança correspondente ao nome devem ser verificados a partir das redes efetivamente utilizadas pelos clientes.

fw.example.com serve aqui apenas como exemplo de documentação e deve ser substituído pelo FQDN válido da organização. Não é um URI de redirecionamento pronto a utilizar. O caminho de callback e a porta do serviço serão copiados posteriormente, sem alterações, de Show URLs, e não construídos a partir de um exemplo. Neste procedimento, deve ser utilizado um FQDN mesmo com introdução manual, e não um endereço IP.

Verificar os limites antes da alteração

Só pode ser selecionado um servidor IdP OIDC por serviço de autenticação. Por isso, uma atribuição Entra existente não é simplesmente complementada: é substituída de forma deliberada ou mantida sem alterações.
Para o mesmo domínio, os utilizadores não podem ser sincronizados simultaneamente através do Active Directory e do Google Workspace. Os utilizadores e grupos existentes precisam de objetos Google correspondentes; os objetos antigos que não possam ser associados continuam a ser geridos manualmente.
A MFA própria da firewall não é utilizada para Google OIDC. O requisito de MFA é configurado no Google e efetivamente verificado no piloto. As contas locais de emergência mantêm a sua própria proteção.
Num cluster HA, o SSO do Google não suporta atualmente a autenticação no WebAdmin do dispositivo Auxiliary. Para esse dispositivo, continua a ser necessário um meio de gestão local independente.
Para o SSO do Google com Sophos Connect, estão previstos Windows e a versão 2.4 ou posterior do cliente. O suporte de Entra no macOS não constitui aprovação para o Google Workspace.

Apenas se estiver prevista a utilização de Context-Aware Access (CAA): Antes do piloto, verifica-se, para cada utilizador previsto, se dispõe de uma licença/edição que suporte CAA e, para a aplicação e o fluxo de autenticação concretos, se estes são suportados e se a política pretendida está efetivamente atribuída à aplicação e ao grupo de utilizadores/unidade organizacional. Os utilizadores com outras edições não ficam sujeitos à política CAA, mesmo que esta se destine ao mesmo grupo ou unidade organizacional; Endpoint Verification, por si só, não comprova a elegibilidade para CAA. O CAA é opcional e não constitui um requisito de licença premium para a utilização normal de Google OIDC. A documentação Google sobre SAML não comprova o suporte do fluxo OIDC da Sophos. Antes da aprovação, comprova-se o efeito pretendido através de novos testes de autenticação positivos e negativos para a aplicação, os utilizadores e as condições concretos; a falta de suporte ou um teste negativo que resulte inesperadamente numa autenticação bem-sucedida impede a aprovação do fluxo protegido por CAA.

Preparar o Google Workspace

Criar o cliente web OAuth

Em Google Cloud Console > APIs & Services > Credentials, selecionar o projeto correto. Se o Google exigir primeiro a configuração do ecrã de consentimento OAuth, concluí-la para a organização e o conjunto de utilizadores autorizado; não criar uma autorização externa geral apenas para o teste.
Abrir Create credentials > OAuth client ID e selecionar Application type: Web application.
Atribuir um nome identificável, por exemplo SFOS-Google-SSO-Pilot, e criar o cliente.
Guardar imediatamente Client ID e Client secret num cofre de segredos aprovado. O segredo não deve ser copiado para capturas de ecrã, pedidos de suporte ou documentação da alteração.

O ID do cliente OAuth identifica a firewall durante a autenticação. Não é o ID numérico da conta de serviço, necessário mais tarde para a delegação. Os URI de redirecionamento só são acrescentados depois de a firewall os gerar.

Configurar a conta de serviço e a consulta de grupos

A autenticação e a consulta de grupos utilizam credenciais diferentes: o cliente OAuth serve para a autenticação interativa; a conta de serviço permite à firewall consultar informações do diretório Google. O Google não fornece simplesmente as associações a grupos como parte da resposta normal de autenticação OIDC.

Em Google Cloud Console > IAM & admin > Service accounts > Create service account, criar uma conta dedicada a esta integração, por exemplo sfos-directory-reader.
Não atribuir indiscriminadamente funções Owner ou Editor como suposto pré-requisito. As permissões IAM adicionais só devem ser aprovadas para uma tarefa comprovadamente necessária.
Nos detalhes da conta de serviço, registar o valor numérico de Unique ID.
Em Keys > Add key > Create new key, selecionar o tipo JSON. Disponibilizar a chave privada transferida de forma protegida para o carregamento posterior na firewall e evitar cópias de transferência não controladas.
Em APIs & Services > Library, procurar Admin SDK API e ativá-la com Enable.

⚠️ Se surgir Service account key creation is disabled, a configuração deve ser interrompida. Não se deve desativar uma política organizacional em toda a organização para continuar este guia. O responsável pela segurança do Google tem de aprovar uma exceção limitada e documentada; caso contrário, a integração permanece bloqueada. A configuração Sophos aqui descrita requer um ficheiro de chave JSON; não se apresenta outro método de autenticação como substituto sem o verificar.

Limitar a delegação ao nível do domínio

Como Super Admin autorizado, abrir Google Admin Console > Security > Access and data control > API controls.
Em Domain-wide delegation > Manage domain wide delegation > Add new, introduzir o Unique ID da conta de serviço como Client ID, e não o ID do cliente web OAuth.
Em OAuth scopes (comma-delimited), introduzir os dois âmbitos de leitura necessários:

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

Se o WebAdmin também for autenticado através do Google, acrescentar este âmbito:

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

Guardar a delegação com Authorize e verificar o ID e a lista completa de âmbitos.

Os URL dos âmbitos são identificadores fixos da API, não valores de exemplo. Se Multi-party approval estiver ativo, outro Super Admin tem de aprovar a delegação. As alterações podem demorar até 24 horas; durante esse período, não se deve criar precipitadamente uma segunda delegação com permissões mais amplas. A delegação ao nível do domínio permite acesso em representação de terceiros no tenant do Workspace e, por isso, é uma autorização relevante para a segurança, apesar de as permissões serem apenas de leitura. A conta de serviço, o ID da chave, a conta de administrador usada para a delegação, a finalidade e a data de revisão devem ter um responsável identificado.

Preparar grupos separados para administradores da firewall

Para uma implementação inicial clara, recomenda-se o mapeamento de grupos. Em Google Admin Console > Directory > Groups, criar um grupo exclusivo para administradores da firewall e adicionar apenas os administradores piloto. Por exemplo, um grupo SFOS-NOC-ReadOnly pode ser associado a um perfil só de leitura previamente verificado. O nome e o endereço do grupo são valores próprios da organização; um grupo normal de colaboradores ou de VPN não recebe permissões de WebAdmin.

Em alternativa, podem ser atribuídas funções de administrador Google personalizadas ou predefinidas em Account > Admin roles e utilizada a opção Roles no servidor da firewall. As funções personalizadas são associadas pelo nome exato da função; as funções predefinidas precisam do seu valor IdP específico, e não apenas da designação visível. Um exemplo confirmado é Groups admin → _GROUPS_ADMIN_ROLE. As funções de administrador Google também podem conceder permissões na Google Admin Console. Por isso, não devem ser atribuídas apenas como rótulo conveniente para a firewall; um grupo dedicado é geralmente a opção mais restrita.

Configurar o servidor OIDC na firewall

Cliente, redirecionamentos e endpoints

Abrir o WebAdmin através do FQDN planeado e aceder a Authentication > Servers > Add.
Selecionar Server type: OpenID Connect, um Server name inequívoco e IdP vendor: Google Workspace.
Introduzir Client ID e Client secret do cliente web OAuth.
Em Redirect URIs, selecionar Use firewall URL. A firewall utiliza o nome de anfitrião do URL atual do WebAdmin. Em alternativa, introduzir o FQDN próprio verificado através de Enter manually.
Abrir Show URLs e copiar os URL completos de Web admin console, Captive portal ou VPN portal and remote access para os serviços efetivamente planeados.
Manter Issuer URL, definido automaticamente como https://accounts.google.com, e utilizar Discover/Reset endpoint URLs. Authorization URL, Token URL, Logout URL, JWKS URL e User info URL são preenchidos através da descoberta, e não por suposição.

Identidade, fallback e permissões de administrador

Em User attributes, Display name e Username suportam os valores name ou email; o valor predefinido documentado é name em ambos os casos. Email address está predefinido como email. A decisão deve ser tomada antes da primeira autenticação piloto: email pode facilitar a associação a um endereço de autenticação único do Workspace, mas tem de ser compatível com as identidades existentes na firewall. Os valores dos atributos não devem ser alterados mais tarde de forma casual, pois isso pode resultar em associações a contas diferentes.

Para utilização exclusiva de VPN ou Captive Portal, IdP authentication for firewall administrators permanece desativado. Para WebAdmin, a opção é ativada de forma deliberada e cada associação é criada com IdP attribute, o IdP value exato e Device access profile. Os valores de grupos ou funções são obtidos da configuração Google da organização, e não deduzidos a partir do nome do exemplo.

A firewall verifica as regras de mapeamento de cima para baixo e utiliza o primeiro perfil correspondente. Por isso, um utilizador pertencente a vários grupos de administradores tem de ser testado explicitamente. Sem uma associação de administrador correspondente, a identidade não recebe acesso ao WebAdmin e pode ser criada como utilizador normal.

Em Fallback group, selecionar deliberadamente um grupo de utilizadores com permissões restritas. Se o grupo Google não existir na firewall, é utilizado este grupo de fallback. Mesmo que o servidor esteja selecionado em Firewall authentication methods, Default group não substitui esta atribuição de fallback OIDC. Um grupo VPN com permissões amplas não é um destino de fallback seguro.

Verificar a conta de serviço e uniformizar os nomes de anfitrião

Em Service account credentials > Email address, introduzir o endereço do Super Admin do Google Workspace previsto para este acesso. Este campo não deve conter o endereço de e-mail da conta de serviço.
Em JSON private key > Browse, selecionar o ficheiro de chave JSON protegido da conta de serviço dedicada.
Executar Test connection. O teste verifica a ligação de rede e as permissões da aplicação. Ainda não comprova uma autenticação correta do utilizador nem uma associação correta de administrador.
Guardar com Save.
Através de Go to Admin and user settings, definir o mesmo FQDN do portal em When redirecting users to the captive portal or other interactive pages: Use the firewall’s configured hostname ou Use a different hostname, de acordo com a configuração da organização. Guardar com Apply.
Em Google Cloud Console > APIs & Services > Credentials, abrir o cliente web OAuth e introduzir cada URL de callback completo anteriormente copiado em Authorized redirect URIs > Add URI. Guardar com Save e comparar caráter a caráter.

Autorizar grupos, serviços e VPN

Importar grupos e atribuir políticas

Em Authentication > Servers, abrir o Assistant for importing groups do servidor Google. É possível importar todos os grupos ou selecionar grupos específicos através de Display name e Mail. Para o piloto, selecionar apenas o conjunto de utilizadores necessário. No assistente, é possível atribuir Surfing quota, Access time, Network traffic e Traffic shaping a todos os grupos ou a grupos individuais.

A firewall e o Google têm de ter a hora sincronizada; caso contrário, até a importação de grupos pode falhar. Após a importação, verificar os nomes dos grupos e as políticas previstas. Para IPsec ou SSL VPN, os novos grupos também têm de ser incluídos nas políticas VPN correspondentes. Uma importação bem-sucedida ainda não constitui uma autorização de VPN.

Alterar a autenticação por serviço

Em Authentication > Services, selecionar o servidor Google apenas nos métodos necessários:

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; a designação da lista não constitui aprovação de OIDC para todos os protocolos legados aí mencionados.
SSL VPN authentication methods: Remote Access SSL VPN.

Arrastar o servidor para o início da lista do serviço selecionado e utilizar Apply em cada serviço. A ordem e o fallback local são verificados face ao estado anteriormente documentado; Local não deve ser removido incidentalmente para os administradores locais pessoais. Os serviços não necessários permanecem inalterados.

Sophos Connect e acessibilidade

O SSO do Google utiliza também a porta do VPN Portal para a comunicação de acesso remoto. Para esta utilização, o acesso ao VPN Portal a partir da WAN tem de estar autorizado em Administration > Device access > Local service ACL. As origens permitidas e a acessibilidade efetivamente necessária devem ser planeadas de forma deliberada; o WebAdmin não é aberto na WAN para este efeito. A restrição é descrita em Device Access e Local Service ACL.

Com um ficheiro de provisionamento, IPsec, SSL VPN e VPN Portal têm de utilizar o mesmo servidor Google. O valor gateway corresponde ao FQDN com o qual foram gerados os redirecionamentos. Sem ficheiro de provisionamento, SSL VPN e VPN Portal também têm de utilizar o mesmo servidor; IPsec pode utilizar outro servidor Google. Por isso, não se deve alterar cegamente apenas um campo de autenticação nos ficheiros VPN existentes.

Após a configuração ou alteração da configuração Google, os utilizadores Windows têm de voltar a importar o seu ficheiro de configuração no Sophos Connect 2.4 ou posterior. Só depois deve ser testada uma nova ligação. Nos endpoints partilhados, deve ser imposta uma nova autenticação SSO aos utilizadores seguintes; uma sessão Google existente não pode autenticar inadvertidamente a pessoa seguinte.

Opcional: utilizar o Captive Portal de forma segura

A regra de firewall baseada em utilizadores correspondente requer Match known users e Use web authentication for unknown users. Em Authentication > Web authentication > Captive portal behavior, para este fluxo do portal, ativar Show web page after sign-in, selecionar In new browser window e desativar Use insecure HTTP instead of HTTPS. Guardar com Apply; OIDC não suporta este modo HTTP inseguro.

Os utilizadores devem manter a janela do Captive Portal aberta para terminar explicitamente a sessão. A inatividade ou o fecho de um separador não termina aqui a sessão SSO do Google, ao contrário de outros métodos de portal. Após terminar a sessão, a página de fim de sessão do Google permanece visível. Credential login, com nome de utilizador e palavra-passe, não substitui este fluxo Google OIDC baseado em tokens.

Validar a autenticação e as permissões

A validação distingue ligação, identidade e autorização. Todos os testes são registados com data e hora, conta, serviço, versão do cliente e resultado esperado, sem registar segredos nem tokens.

Concluir com êxito Test connection e a importação dos grupos selecionados. Em seguida, abrir uma janela privada do navegador através do FQDN previsto.
Autenticar um administrador piloto através do Google e verificar o requisito de MFA esperado. Em Authentication > Users, a identidade, o estado de administrador e o perfil atribuído têm de estar corretos.
Verificar o acesso aos menus necessários e confirmar que uma área bloqueada é efetivamente inacessível. Uma conta só de leitura não pode guardar alterações. Uma conta VPN normal não pode autenticar-se no WebAdmin.
Verificar uma conta que corresponda a várias regras de mapeamento. O perfil tem de corresponder à primeira regra aplicável documentada, e não à função supostamente mais poderosa.
Autenticar-se separadamente no VPN Portal e estabelecer um túnel IPsec ou SSL VPN com a configuração Sophos Connect recém-importada. Um recurso interno autorizado tem de estar acessível; um recurso não autorizado tem de permanecer bloqueado.
Terminar a sessão e voltar a verificar com uma nova sessão. A autenticação no Google, o acesso ao portal e o túnel VPN são critérios de sucesso distintos.
Correlacionar os eventos de WebAdmin em Log viewer > Admin e as autenticações de Captive Portal, VPN Portal, IPsec e SSL VPN em Log viewer > Authentication. Para uma análise mais aprofundada, está disponível oauth_sso_svc.log na Advanced Shell; não são pressupostos comandos de depuração ou reinício para esse efeito.
Voltar a verificar o acesso local de recuperação independente antes de migrar mais utilizadores.

As contas de administrador só são criadas ou atualizadas após uma autenticação bem-sucedida no WebAdmin. Uma autenticação VPN ou Captive Portal não sincroniza uma função de administrador. Por isso, as alterações às funções Google são validadas através de uma nova autenticação no WebAdmin, e não com base num túnel estabelecido com êxito.

Diagnosticar os erros de forma direcionada

O Google apresenta redirect_uri_mismatch

Comparar o URL completo afetado de Show URLs com Authorized redirect URIs do cliente OAuth efetivamente utilizado: esquema, FQDN, porta e caminho têm de corresponder exatamente. Depois, verificar se o navegador utiliza o mesmo nome de anfitrião e se o redirecionamento automático do portal aponta para esse nome. Após a correção, testar uma nova autenticação; nem redirecionamentos com carateres universais nem a mudança para um IP são a solução.

Test connection ou a importação de grupos falha

Verificar primeiro a hora do sistema e a ligação de rede. Depois, verificar Admin SDK API, a validade do ficheiro de chave JSON, a conta Super Admin correta usada para a delegação e Domain-wide delegation, com o ID numérico da conta de serviço e os âmbitos necessários. Se faltarem grupos, verificar também o filtro de importação Display name/Mail. Um erro não deve ser resolvido atribuindo indiscriminadamente permissões de Cloud Owner ou âmbitos adicionais de escrita.

A autenticação no Google funciona, mas o WebAdmin recusa o acesso

Verificar a associação a grupos ou a atribuição de funções no Google, IdP authentication for firewall administrators, o IdP value exato, a ordem de mapeamento e o Device access profile local. Em seguida, efetuar uma nova autenticação no WebAdmin e verificar Log viewer > Admin. Uma autenticação VPN anterior não comprova o mapeamento nem a atualização do administrador.

O portal funciona, mas o túnel ou o recurso interno não

Verificar as versões do Windows e do Sophos Connect, o ficheiro de configuração recém-importado, a acessibilidade do VPN Portal e a atribuição de servidores por serviço. Depois, verificar a inclusão dos grupos nas políticas VPN e as regras para o recurso de destino. Log viewer > Authentication mostra a autenticação; um registo de autenticação bem-sucedida, por si só, não comprova que o tráfego de dados é permitido.

Context-Aware Access ou a reautenticação comporta-se de forma diferente da esperada

As condições Google CAA baseadas no dispositivo requerem um fluxo de navegador suportado e dados de verificação de endpoints efetivamente disponíveis. Para o procedimento de verificação descrito, utiliza-se o Google Chrome com Endpoint Verification. Uma autenticação bem-sucedida no Sophos Connect não é considerada prova de que todas as condições CAA baseadas no dispositivo foram avaliadas.

O CAA é avaliado durante a autenticação e não termina uma sessão da firewall já ativa. O intervalo de reautenticação do Google também não força uma nova autenticação numa sessão VPN ativa da firewall. Deve ser verificada uma nova autenticação após terminar a sessão ou desligar a ligação de forma controlada; as sessões existentes têm de ser tratadas separadamente durante a remoção de acessos.

Operação, remoção de acessos e reversão

Uma alteração a grupos ou funções é verificada com uma nova autenticação e testes de acesso permitido e negado. Ao retirar uma pessoa da administração, a alteração da função no Google, por si só, não basta: o SFOS não converte automaticamente uma conta de administrador existente de volta num utilizador normal. Após verificar as dependências e com outro administrador funcional, a conta de administrador em causa tem de ser eliminada na firewall. Na próxima autenticação normal, a firewall pode voltar a criar o utilizador. As sessões ativas de WebAdmin e VPN são verificadas e terminadas separadamente; a remoção do utilizador de um grupo não constitui uma revogação imediata de sessão comprovada.

Para o segredo OAuth e a chave da conta de serviço, devem ser definidos um responsável, armazenamento seguro, revisão e rotação. Numa rotação planeada, a chave antiga só permanece disponível durante o tempo exigido pelo procedimento de reversão documentado. As novas credenciais são primeiro verificadas com Test connection, consulta de grupos e uma nova autenticação, antes de revogar as credenciais antigas. Em contrapartida, uma situação de comprometimento é tratada segundo o processo de incidentes da organização, e não prolongada para facilitar uma reversão conveniente.

Se o piloto falhar, a atribuição anterior de serviços e a ordem dos servidores, registadas com exatidão, são restauradas a partir da sessão aberta com privilégios de administrador completos ou do acesso local de recuperação. Da mesma forma, os nomes de anfitrião dos portais, Device Access, as políticas de grupos/VPN e os mapeamentos de administradores alterados são repostos nos respetivos estados anteriores. Em seguida, testar a autenticação de administrador local e o método VPN anterior em novas sessões.

Além disso, através do acesso independente disponível com privilégios de administrador completos, compara-se cada conta afetada em Authentication > Users com o levantamento individual das contas. Nas contas já existentes, repõem-se explicitamente o User type anterior, o Profile atribuído e o estado da conta; se, para tal, for necessário eliminar e voltar a criar a conta, verificam-se previamente todas as dependências e salvaguardam-se as atribuições anteriores. Apenas os objetos de administrador/utilizador criados durante o piloto são removidos, após verificar as respetivas dependências de grupos, VPN, políticas e outras. A reposição do mapeamento do servidor ou a remoção de uma função Google não substitui esta regularização das contas nem termina qualquer sessão existente. Por isso, as sessões ativas de WebAdmin, portal e VPN são verificadas e terminadas separadamente. Por fim, comprova-se, em novas sessões, o funcionamento do acesso de administrador local e do acesso VPN anteriores, bem como a recusa de acesso a uma identidade piloto que já não esteja autorizada; nas contas existentes cujo estado foi reposto, verificam-se as permissões originais e a recusa das permissões adicionais concedidas apenas durante o piloto.

Só depois de a reversão funcionar e de se confirmar que não existem dependências de outros serviços é que os URI de redirecionamento, as autorizações de delegação e as credenciais criados exclusivamente para o piloto são removidos de forma controlada. Os clientes ou contas de serviço partilhados não são eliminados sem verificar as dependências. Uma cópia de segurança completa da configuração só é restaurada durante a janela de recuperação aprovada, pois também pode reverter alterações independentes da firewall.