Configurar Synchronized User ID Authentication na Sophos Firewall

O Synchronized User ID Authentication associa o início de sessão de um endpoint gerido à Sophos Firewall. O Sophos Endpoint transmite a identidade através do Security Heartbeat. No processo AD para SFOS 22, a firewall valida o utilizador do domínio através do Active Directory; a ajuda do SFOS 23 descreve adicionalmente o Microsoft Entra ID com resolução de UPN e consulta de grupos. Os utilizadores associados com êxito aparecem em Current activities > Live users.

Esta abordagem é adequada para estações de trabalho geridas onde o Sophos Endpoint e o Security Heartbeat já funcionam. Não requer um agente de autenticação adicional no cliente ou no servidor. No entanto, o próprio Sophos Endpoint continua a ser um requisito.

⚠️ A ajuda do SFOS 22 confirma o processo AD mais antigo para Windows 10 e exclui outros serviços de diretório. Esta afirmação não se aplica de forma geral ao SFOS 23: nesta versão está documentado um processo próprio para Entra ID. Os utilizadores locais e os dispositivos com Server Protection continuam excluídos. A página do SFOS 23 não indica uma versão concreta do sistema operativo; não se deve deduzir daí, nem de um piloto bem-sucedido, suporte adicional para sistemas operativos.

SFOS 23: identidade Entra através do Security Heartbeat

Este ramo descreve o início de sessão no endpoint, não o início de sessão SSO interativo no VPN Portal ou no WebAdmin. A integração Entra já deve estar corretamente configurada. A configuração de base comum do Entra explica a aplicação, as permissões, o servidor de autenticação e a importação de grupos; o próprio início de sessão VPN não é um requisito para este piloto de heartbeat. Para o acesso de administrador, aplica-se separadamente Entra ID para WebAdmin.

Requisitos mínimos e resolução da identidade

Antes do piloto, verificar estes requisitos:

• A firewall executa a build prevista do SFOS 23, está ligada ao Sophos Central ou ao Sophos Fusion e tem um Security Heartbeat funcional. As informações de licenciamento mantidas abaixo provêm expressamente da ajuda do SFOS 22; não comprovam um requisito de licenciamento novo ou alterado para o SFOS 23. Verificar separadamente o direito de utilização para a versão efetivamente utilizada.
• O Sophos Endpoint 2025.1 ou posterior está instalado no dispositivo piloto gerido. A ajuda do SFOS 23 exige Endpoint em dispositivos associados ao domínio; não se deve deduzir daí suporte adicional para quaisquer modelos de associação ou sistemas operativos.
• A conta de utilizador utiliza o mesmo endereço de e-mail no Sophos Central/Fusion, na firewall e no diretório configurado. O utilizador Entra com sessão iniciada deve poder ser associado inequivocamente.
• O Microsoft Entra ID está configurado com êxito na firewall como servidor de autenticação. Em Authentication > Servers, verificar o servidor Entra e Test connection; verificar a sincronização da hora, a acessibilidade, as permissões da aplicação e a importação de grupos de acordo com a configuração de base ligada acima.
• O Endpoint transmite o UPN válido do utilizador Entra com sessão iniciada através do heartbeat. A partir do Endpoint 2025.1, são transmitidos o nome de início de sessão, o nome do domínio e o UPN; as versões anteriores não enviam UPN. Sem UPN, a firewall não consegue associar o heartbeat a um utilizador Entra. Por isso, um heartbeat verde, por si só, não é suficiente.

⚠️ Não sincronizar simultaneamente os utilizadores de um mesmo domínio através de AD e Entra ID. Os requisitos do Entra excluem esta combinação. Não interpretar um caminho AD existente como uma migração automática: esclarecer primeiro qual o diretório responsável e o caminho de recuperação; parar o piloto se a dupla associação não estiver esclarecida.

O processo Entra é composto por cinco passos:

1. O utilizador inicia sessão com a sua conta Entra ID no dispositivo protegido pelo Sophos Endpoint.
2. O Endpoint envia as informações de identidade à firewall através do Security Heartbeat.
3. A firewall resolve o utilizador Entra com base no seu UPN. Ao contrário do ramo AD, aqui não é utilizado sAMAccountName como chave de associação Entra.
4. A firewall consulta as associações aos grupos Entra e ativa o utilizador com as políticas de utilizador e de grupo adequadas, bem como as políticas Synchronized Security correspondentes.
5. O utilizador aparece em Current activities > Live users. A firewall não utiliza nem partilha palavras-passe neste processo.

Validar o piloto Entra e a autorização

Os exemplos de documentação são anna.muster@example.com, o IP de cliente 10.20.30.101, o grupo piloto Entra SFOS-Internet-Users e a regra LAN_User_Internet. Substituir o UPN, o IP e o grupo pelos valores do próprio piloto. Limitar deliberadamente o grupo aos utilizadores de teste necessários; o nome, por si só, não comprova a pertença ao grupo nem a autorização.

1. Documentar o estado anterior da associação ao diretório, dos objetos de utilizador e de grupo, das regras e dos nós HA, bem como um acesso administrativo independente. Utilizar um cliente de teste autorizado e contas de teste; não bloquear nem eliminar contas de produção.
2. Importar o grupo Entra necessário de acordo com a configuração de base e selecioná-lo numa regra de âmbito restrito com registo, em Rules and policies > Firewall rules, com Match known users e Users or groups. Limitar a origem, o destino e os serviços ao piloto; a regra piloto descrita mais abaixo mostra os campos.
3. Terminar completamente a sessão no dispositivo piloto e iniciar uma nova sessão com a conta Entra. Verificar em conjunto o heartbeat e Current activities > Live users: o utilizador esperado, o IP do cliente e Client Type: Heartbeat devem corresponder ao início de sessão de teste. Documentar a identidade efetivamente apresentada, sem pressupor um nome de apresentação específico.
4. Gerar um novo fluxo de teste permitido e comparar no Log viewer o utilizador, a origem, o destino, o serviço, a ação, a hora e Firewall Rule ID. Só o fluxo correto comprova o efeito da regra; uma entrada em Live users, por si só, não comprova a autorização por grupo.
5. Verificar o mesmo caminho de destino com um utilizador de teste separado que não pertença ao grupo piloto. Este não deve obter acesso através da regra do grupo piloto. Outra regra válida pode continuar a ser aplicada: documentar a respetiva Rule ID em vez de esperar um bloqueio total generalizado.
6. Validar como casos de teste negativos um UPN em falta ou inválido, uma conta de teste Entra inexistente ou inativa e a falta de acessibilidade da firewall ao Entra. Provocar falhas apenas num ambiente de teste isolado e autorizado, não através de bloqueios ao nível de todo o tenant ou de bloqueios globais da rede. Sem esse ambiente, documentar os casos de teste como pendentes, não como testados com êxito. Se o UPN estiver em falta, não esperar uma associação Entra; para erros de conta e de acessibilidade, não garantir uma mensagem de erro específica nem o encerramento imediato das sessões existentes.
7. Verificar de forma controlada a perda do heartbeat e a suspensão/retoma. Na ausência de heartbeat, a sessão do utilizador sincronizado é terminada; outros métodos de autenticação podem continuar a ser aplicados e o tráfego pode ser interrompido até ao novo início de sessão. A sequência de verificação do heartbeat apresentada a seguir também se aplica aqui.

O utilizador Entra não aparece ou tem o grupo incorreto

Se o heartbeat estiver verde, mas não houver uma identidade correspondente, verificar primeiro a versão do Endpoint e o UPN efetivamente comunicado. Em seguida, verificar se a conta Entra existe e está ativa, se os serviços da firewall conseguem aceder ao Entra e se a configuração Entra foi concluída com êxito. Voltar a executar Test connection em Authentication > Servers. Um teste de ligação bem-sucedido, por si só, não comprova o UPN do endpoint nem a autorização por grupo.

Se a identidade estiver visível, mas o grupo ou a regra estiver incorreto, comparar a pertença ao grupo Entra, o grupo importado na firewall, a associação do utilizador e a ordem das regras. Guardar os dados do fluxo afetado com a Rule ID e a hora. Não alargar regras, eliminar objetos de utilizador nem reiniciar serviços por precaução. Para uma escalada, guardar a build do SFOS, a versão do Endpoint, o UPN anonimizado, o estado do heartbeat, o IP do cliente, o intervalo temporal e o nó HA que processa o tráfego, juntamente com os registos indicados abaixo.

HA e caminho de recuperação para o piloto Entra

A ajuda do SFOS 23 também descreve o Synchronized User ID como ativo por predefinição e exige a ativação ou desativação em ambos os dispositivos HA. A alteração do estado não é guardada na cópia de segurança. Os comandos shell mantidos mais abaixo também estão documentados no SFOS 23; alteram o estado da função no seu conjunto, não apenas do Entra. Por isso, um reinício deste serviço não é uma reversão inofensiva do piloto.

Testar o failover apenas numa janela de manutenção autorizada, com acesso administrativo independente. No nó que passa a processar o tráfego, voltar a validar o heartbeat, um novo início de sessão Entra, Live users, a regra de grupo e um novo fluxo de teste. Não pressupor uma transferência sem interrupções do estado dos utilizadores ou das sessões; as correções do SFOS 22 indicadas abaixo não constituem uma nova garantia de failover para o SFOS 23.

Para o caminho de recuperação, começar por repor a regra piloto e as associações piloto no estado anterior documentado e verificar o caminho de autenticação anterior com um novo início de sessão e tráfego real. Não eliminar nem desativar globalmente, como limpeza do teste, a aplicação Entra, os servidores, as permissões e os grupos utilizados em comum por VPN, portal ou WebAdmin. Se o estado global do Synchronized User ID também tiver sido alterado durante a janela de manutenção, restabelecer expressamente o estado pretendido em ambos os nós e verificá-lo separadamente após uma reposição. Só voltar a ativar um caminho de recuperação AD quando a sincronização Entra do mesmo domínio tiver sido terminada de forma controlada.

Os passos e exemplos AD seguintes são mantidos como um caminho próprio e mais antigo do SFOS 22. A resolução da identidade AD também é descrita na ajuda do SFOS 23, mas não substitui aí a verificação do Entra.

SFOS 22 com AD: Synchronized User ID em oito passos

1. Escolher como piloto um cliente de domínio Windows 10 com Sophos Endpoint.
2. Verificar o Sophos Fusion (anteriormente Sophos Central), o Security Heartbeat e a licença da firewall.
3. Ligar o Active Directory como servidor de autenticação da firewall.
4. Comparar o domínio UPN, sAMAccountName, endereço de e-mail e perfil de utilizador entre o AD, o Sophos Fusion e a firewall.
5. Preparar uma regra de utilizador com âmbito restrito e registo para um grupo piloto.
6. Iniciar uma nova sessão do Windows no piloto e confirmar um heartbeat verde.
7. Verificar o utilizador, o endereço IP e Client Type em Current activities > Live users, além do tráfego real no Log Viewer.
8. Testar a perda do heartbeat, o comportamento de HA e um caminho de recuperação controlado antes de adicionar mais endpoints.

Quando o Synchronized User ID é adequado

O Synchronized User ID não substitui de forma geral todos os métodos de autenticação da Sophos. O caminho AD do SFOS 22 aqui mantido é adequado quando um endpoint Windows 10 gerido pertence normalmente a exatamente um utilizador AD e o Sophos Endpoint já envia um Security Heartbeat. Para utilizadores Entra no SFOS 23, aplicam-se os requisitos e a validação do ramo próprio acima.

Outros modelos operacionais exigem outros métodos:

• O STAS na Sophos Firewall associa inícios de sessão do Windows provenientes de controladores de domínio, STA Agent e Collector a um IP de cliente.
• O SATC para Remote Desktop Services distingue várias sessões atrás do mesmo IP de RDS ou Citrix.
• O Per-Connection AD SSO distingue ligações HTTP e HTTPS de vários utilizadores através do Direct Web Proxy.
• O Captive Portal ou Client Authentication Agent são adequados quando é necessário um início de sessão interativo.

Não se deve forçar um cenário de servidor ou terminal server com Synchronized User ID. A Sophos indica expressamente que o Server Protection não é suportado. Se vários utilizadores partilharem o mesmo IP ou se for necessário associar ligações não web por sessão, o SATC é mais adequado.

Se o Synchronized User ID e o STAS estiverem configurados ao mesmo tempo, a Sophos indica que o servidor de autenticação utiliza o mecanismo cujo pedido de início de sessão chegar primeiro. Esta coexistência não deve ser tratada como uma prioridade fixa. O piloto deve ser inequivocamente delimitado e o Client Type verificado em cada validação.

Como funciona a associação AD

O processo é composto por quatro níveis separados:

1. O utilizador inicia sessão no cliente de domínio Windows.
2. O Sophos Endpoint envia o utilizador do domínio à firewall através do Security Heartbeat.
3. A firewall obtém o domínio a partir do UPN e o nome de utilizador a partir de sAMAccountName.
4. A firewall valida o utilizador através do servidor Active Directory correspondente e ativa-o para regras baseadas em utilizadores.

A função não autentica utilizadores locais do Windows e não substitui uma ligação ao AD. Se o domínio UPN, o servidor de diretório ou o perfil de utilizador não corresponderem, um endpoint verde pode continuar sem uma identidade de utilizador utilizável.

A Sophos Firewall não partilha nem utiliza informações de palavras-passe neste processo. O heartbeat transporta os dados de domínio e utilizador necessários para a associação, enquanto a validação ocorre no servidor AD configurado.

Exemplo AD e valores substituíveis

O processo utiliza estes valores de documentação:

• Firewall: fw01.example.com
• Domínio AD e sufixo UPN: example.com
• Cliente Windows: WS-101
• IP do cliente: 10.20.30.101
• Nome de utilizador: anna.muster
• UPN: anna.muster@example.com
• sAMAccountName: anna.muster
• Grupo AD: SFOS-Internet-Users
• Regra piloto: LAN_User_Internet

example.com, WS-101, 10.20.30.101, o utilizador e o grupo são exemplos e devem ser substituídos pelos valores reais. O nome do objeto não é o ponto decisivo. O Sophos Fusion, o Windows, o Active Directory e a firewall devem associar inequivocamente o mesmo utilizador.

Preparar os requisitos

Verificar o Sophos Fusion e o Security Heartbeat

A firewall deve estar ligada ao Sophos Fusion e ter uma subscrição válida de Network Protection. O piloto necessita do Sophos Central Endpoint Protection como licença de avaliação ou completa. Estes requisitos de licença provêm da ajuda do SFOS 22 sobre Security Heartbeat; o registo e a linha de base do heartbeat são explicados em Ligar a Sophos Firewall ao Sophos Fusion.

Em System > Sophos Fusion, o registo e o Security Heartbeat devem estar ativos. O piloto deve aparecer com um estado plausível no Control Center e no Sophos Fusion. Primeiro deve estabelecer-se esta linha de base e depois verificar a associação da identidade.

Segundo a ajuda do SFOS 22 sobre o Security Heartbeat, o endpoint e a firewall trocam dados de heartbeat através de uma ligação TLS cifrada a 52.5.76.173 na porta TCP 8347. O estado verde significa que a proteção Sophos funciona corretamente e que não foi detetado malware ativo ou inativo nem PUA. Ainda não comprova que o AD validou o utilizador. Em caso de problemas de ligação, verificar separadamente o transporte, o tenant do Fusion e o certificado do endpoint, e depois a associação do utilizador.

O Synchronized User ID está ativo por predefinição. Por isso, não existe um interruptor WebAdmin normal que tenha de ser ativado primeiro para o piloto. Os comandos shell descritos mais adiante servem apenas para desativar ou reativar a função de forma controlada.

Comparar o Active Directory e os atributos do utilizador (caminho AD)

Em Authentication > Servers deve existir e estar acessível um servidor Active Directory adequado. Ligar o Active Directory à Sophos Firewall explica LDAPS, a base de pesquisa, a importação de grupos e a ordem dos servidores.

Em seguida, ir a Authentication > Services > Firewall authentication methods e mover o servidor AD para Selected authentication server. A ajuda do SFOS 22 sobre Authentication Services confirma que tem de estar selecionado pelo menos um servidor; quando existem vários, a firewall processa-os pela ordem apresentada. Adicionar o servidor apenas em Servers não é suficiente para a autenticação da firewall.

No mínimo, estes valores devem coincidir para o piloto:

• O domínio no UPN corresponde ao domínio do servidor AD utilizado pela firewall.
• sAMAccountName é único no Active Directory e pode ser encontrado pela firewall.
• O perfil de utilizador e o endereço de e-mail coincidem entre o AD, o Sophos Fusion e o registo de utilizador local da firewall.
• O grupo AD necessário está importado e associado ao perfil de utilizador correto da firewall.

Um sufixo UPN diferente, valores sAMAccountName duplicados em âmbitos de pesquisa inadequados ou um servidor AD incorreto são sinais para parar. Não devem ser compensados com uma regra de utilizador mais ampla.

Preparar a regra piloto

Em Rules and policies > Firewall rules, clicar em Add firewall rule > New firewall rule e criar uma regra com âmbito restrito para o grupo piloto, ou utilizar de forma controlada uma regra de utilizador existente. Na secção da identidade do utilizador, ativar Match known users antes de selecionar Users or groups:

• Source zones: zona real do cliente
• Source networks and devices: rede piloto ou intervalo de origem mais restrito
• Users or groups: SFOS-Internet-Users
• Destination zones: apenas o caminho de destino necessário
• Services: apenas os serviços necessários para o teste
• Log firewall traffic: ativo

A ordem das regras, o registo e o teste negativo são mais importantes do que uma regra de permissão ampla. Criar corretamente regras na Sophos Firewall explica a configuração.

Iniciar sessão e validar o piloto AD

1. Terminar completamente a sessão do utilizador existente no cliente piloto.
2. Iniciar uma nova sessão do Windows como anna.muster@example.com.
3. Verificar um heartbeat verde no Sophos Fusion e na firewall.
4. Procurar anna.muster e 10.20.30.101 em Current activities > Live users.
5. Confirmar que são apresentados o utilizador, o endereço IP e Client Type: Heartbeat.
6. Gerar um teste de tráfego permitido através de LAN_User_Internet.
7. Abrir o Log viewer no canto superior direito, selecionar o módulo da firewall e comparar o nome de utilizador, a origem, o destino, o serviço, Firewall Rule ID, a ação e a hora.
8. Executar um teste negativo com um utilizador fora do grupo piloto.

Uma entrada em Live users comprova apenas a associação da identidade. Só o fluxo de teste registado comprova que também é aplicada a regra de utilizador correta. Se o registo de tráfego mostrar apenas o endereço IP ou o fluxo atingir outra Rule ID, não se deve ampliar a regra. É necessário verificar a associação e a ordem.

Testar deliberadamente a perda do heartbeat

Se o Security Heartbeat estiver em falta ou se perder durante uma transição de suspensão e retoma, a firewall termina a sessão do utilizador detetado através do Synchronized User ID. Outros métodos de autenticação configurados podem continuar a ser aplicados, mas o tráfego baseado em utilizadores pode ser interrompido até ao próximo início de sessão.

Para um teste controlado:

1. Documentar primeiro o utilizador ativo, o IP, o estado do heartbeat e a regra.
2. Colocar o piloto em suspensão e reativá-lo.
3. Voltar a verificar o estado do heartbeat e Live users.
4. Gerar um novo teste de tráfego e confirmar o utilizador e a Rule ID efetivamente utilizados.
5. Em caso de diferenças, verificar o endpoint, o caminho e os registos em vez de desativar globalmente o Synchronized User ID por precaução.

Um Missing Heartbeat não significa automaticamente malware. Analisar sistematicamente os alertas Missing Heartbeat explica o diagnóstico completo.

Interpretar as notas de lançamento do SFOS 22 e as limitações conhecidas

A validação deve considerar o Maintenance Release instalado, e não apenas “SFOS 22”. Este artigo atualizado sobre Synchronized User ID documenta diretamente as duas afirmações NC concretas. A verificação antes do upgrade para o SFOS 22 é responsável aqui apenas pela confirmação da versão e da build, pelo caminho de upgrade aprovado e pela preparação da alteração. As correções do produto são: MR1 Build 490 corrige o atraso no acesso à Internet após um failover de HA acionado manualmente com autenticação por heartbeat (NC-165361); MR2 Build 546 corrige falsos avisos Missing Heartbeat quando dois endpoints partilham a mesma docking station ou interface USB (NC-176012). Se um destes sintomas surgir numa build 22.0 anterior, registar primeiro a build exata e avaliar um caminho de atualização aprovado.

O runbook para analisar alertas Missing Heartbeat também aborda NC-147863: com split tunneling de SSL VPN para uma firewall externa, um novo adaptador VPN pode interromper a ligação heartbeat. O utilizador perde então a autenticação por heartbeat e pode entrar num ciclo de ligação e desligamento. Se o piloto incluir este cenário, testá-lo especificamente. Como solução alternativa, a Sophos indica desativar Match known users na regra VPN da firewall local ou utilizar o Captive Portal para autenticação. Limitar primeiro a alteração à regra VPN afetada e documentar o respetivo efeito e a reversão.

Delimitar sistematicamente os erros

O endpoint não aparece com um heartbeat verde

Verificar primeiro o registo no Fusion, a licença do endpoint, a licença Network Protection, a associação da firewall, DNS, hora e caminho de rede. Sem um Security Heartbeat funcional, o Synchronized User ID não consegue transmitir uma identidade.

O utilizador não aparece em Live users

Para o caminho AD, verificar em conjunto o início de sessão do Windows, o UPN, sAMAccountName, o servidor AD, o âmbito de pesquisa e o perfil de utilizador. Um heartbeat verde confirma a ligação do endpoint, não uma validação AD bem-sucedida automaticamente. No SFOS 23, para utilizadores Entra, utilizar em alternativa a verificação de UPN, conta e acessibilidade no ramo Entra.

Utilizador ou grupo incorreto

Para AD, comparar o domínio UPN, o âmbito de pesquisa AD, o grupo importado, Main Group e os objetos de utilizador locais. Para Entra no SFOS 23, aplicam-se adicionalmente a pertença ao grupo Entra e a associação por UPN no ramo próprio. Não eliminar objetos de utilizador antes de verificar dependências de VPN, portal, regras, quotas e relatórios.

O utilizador está visível, mas a regra não é aplicada

Verificar a zona e a rede de origem, o utilizador ou grupo, o serviço, o destino e a ordem das regras. No Log Viewer, o fluxo real deve mostrar a Firewall Rule ID esperada. Uma identidade visível, por si só, não confirma a autorização.

Servidor ou versão do Windows não confirmada

O Server Protection não é suportado em nenhum dos dois caminhos. A ajuda do SFOS 22 menciona expressamente Windows 10 para AD; a página do SFOS 23 não define uma versão concreta do sistema operativo. Para outros sistemas operativos, modelos de associação ou tipos de endpoint desconhecidos, não deduzir suporte de produção a partir da disponibilidade da documentação ou do comportamento de um único piloto.

Ler os registos relevantes

Estas verificações só de leitura são úteis na Advanced Shell:

cd /log
tail -n 200 heartbeatd.log
tail -n 200 access_server.log
tail -n 200 hbtrust.log

heartbeatd.log mostra eventos do heartbeat, access_server.log ajuda na autenticação e autorização e hbtrust.log na relação de confiança com o Sophos Fusion. Um único registo não constitui uma prova completa. Devem ser guardados em conjunto o intervalo temporal, o utilizador, o endpoint, o IP, a Rule ID e o nó HA afetado. Ficheiros de registo e serviços da Sophos Firewall explica outros caminhos.

Se continuar sem ser claro se falha o diretório, o método, o registo de utilizador local ou a regra, Resolver sistematicamente erros de autenticação apresenta uma sequência de diagnóstico transversal aos métodos.

Desativar a função de forma controlada

⚠️ Os comandos seguintes alteram o estado de autenticação e reiniciam o access_server. Primeiro devem ser documentados os utilizadores ativos, as regras afetadas, um método de acesso alternativo e o caminho de recuperação. Em HA, ambos os nós devem ser tratados deliberadamente.

As instruções oficiais do SFOS 22 e do SFOS 23 indicam estes comandos para uma desativação persistente:

touch /content/no_userid
service access_server:restart -ds nosync

Esta variante desativa a função apenas até ao próximo reinício da firewall:

touch /tmp/no_userid
service access_server:restart -ds nosync

Para reativar a função, remover o ficheiro persistente e reiniciar o serviço:

rm /content/no_userid
service access_server:restart -ds nosync

Após cada alteração, verificar um novo início de sessão do Windows, Live users, o tráfego real e os registos. O estado desativado não é guardado nas cópias de segurança da configuração. Após uma reposição, voltar a verificar o estado pretendido e defini-lo em ambos os nós HA, se necessário.

HA, cópias de segurança e operação

Num cluster HA, o Synchronized User ID é ativado ou desativado em ambos os dispositivos. Cada nó guarda apenas os registos do tráfego e dos eventos que processa. Para um incidente, deve verificar-se o nó que estava ativo ou processava o tráfego nesse momento.

Um teste HA controlado exige um novo início de sessão do Windows e um novo fluxo de tráfego. Não se deve pressupor que o estado do utilizador ou as sessões ativas continuam sem interrupção. Após o failover, voltar a validar pelo menos o heartbeat, Live users, a regra de utilizador e os registos.

O estado de /content/no_userid não está incluído numa cópia de segurança. Esta exceção deve ficar expressamente documentada nos procedimentos operacionais, testes de reposição e processo RMA.

Reversão

1. Documentar o estado atual do heartbeat, do utilizador, da regra e de HA.
2. Desativar a regra piloto ou repor o estado anterior documentado.
3. Só se o estado global da função tiver sido alterado no teste, repor de forma controlada o estado anterior documentado. Para uma reativação intencional após uma desativação persistente, remover /content/no_userid e reiniciar o access_server; não ativar indiscriminadamente uma função que estava anteriormente desativada. Segundo a Sophos, a variante temporária termina no próximo reinício da firewall. Não provocar um reinício apenas para a limpeza do teste fora de uma janela de manutenção autorizada.
4. Estabelecer o mesmo estado pretendido em ambos os nós HA.
5. Iniciar uma nova sessão do Windows no piloto e verificar o heartbeat e Live users.
6. Voltar a testar a regra de utilizador e o caminho de autenticação alternativo com tráfego real.
7. Só então remover objetos de teste temporários ou associações piloto.

Lista de verificação para o caminho AD do SFOS 22

• O piloto é um cliente de domínio Windows 10 suportado com Sophos Endpoint.
• A firewall, o endpoint e o Security Heartbeat estão visíveis no Sophos Fusion.
• As licenças Network Protection e do endpoint são válidas.
• O servidor AD, o domínio UPN, sAMAccountName, o endereço de e-mail e o perfil de utilizador coincidem.
• O grupo piloto está importado e a regra de utilizador tem âmbito restrito e registo.
• Live users mostra o utilizador esperado e o IP de cliente correto.
• O tráfego real atinge a Firewall Rule ID esperada.
• A perda do heartbeat e a suspensão ou retoma foram testadas de forma controlada.
• Os nós HA, os registos, o limite da reposição e o caminho de recuperação estão documentados.
• O Synchronized User ID não foi indevidamente alargado como substituto de SATC, STAS ou outros serviços de diretório.

Perguntas frequentes