Configurar Synchronized User ID Authentication na Sophos Firewall

O Synchronized User ID Authentication associa o início de sessão do Windows num endpoint gerido à Sophos Firewall. O Sophos Endpoint envia o utilizador do domínio através do Security Heartbeat, a firewall valida-o no Active Directory e apresenta-o depois 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 documentação atual da Sophos confirma este processo para o Windows 10. Não descreve o Server Protection, utilizadores locais do Windows, outros serviços de diretório ou outras versões do Windows como igualmente suportados. Estes sistemas não devem ser migrados para este processo sem aprovação ou teste específico.

Synchronized User ID em oito passos

1. Escolher como piloto um cliente de domínio Windows 10 com Sophos Endpoint.
2. Verificar o 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 Central 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. É adequado quando um endpoint Windows 10 gerido pertence normalmente a exatamente um utilizador do AD e o Sophos Endpoint já envia um Security Heartbeat à firewall.

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

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 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 Central, o Windows, o Active Directory e a firewall devem associar inequivocamente o mesmo utilizador.

Preparar os requisitos

Verificar o Sophos Central e o Security Heartbeat

A firewall deve estar ligada ao Sophos Central 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. O registo e a linha de base do heartbeat são explicados em Ligar a Sophos Firewall ao Sophos Central.

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

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

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.

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 Central 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, criar uma regra com âmbito restrito para o grupo piloto ou utilizar de forma controlada uma regra de utilizador existente:

• 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

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 Central e na firewall.
4. Procurar anna.muster e 10.20.30.101 em Current activities > Live users.
5. Confirmar que o utilizador, o endereço IP e Client Type correspondem ao método esperado.
6. Gerar um teste de tráfego permitido através de LAN_User_Internet.
7. Comparar no Log Viewer 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.

Delimitar sistematicamente os erros

O endpoint não aparece com um heartbeat verde

Verificar primeiro o registo no Central, 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

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.

Utilizador ou grupo incorreto

Comparar o domínio UPN, o âmbito de pesquisa AD, o grupo importado, Main Group e os objetos de utilizador locais. Não eliminar objetos de utilizador antes de verificar dependências de VPN, portais, 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 para este processo. A ajuda atual da Sophos menciona expressamente o Windows 10. Não se deve deduzir suporte de produção para outras versões do Windows ou tipos de endpoint desconhecidos a partir de um único piloto bem-sucedido.

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 Central. 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.

A Sophos utiliza este ficheiro 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. Para a variante persistente, remover /content/no_userid de forma controlada e reiniciar o access_server. Segundo a Sophos, a variante temporária só termina no próximo reinício da firewall.
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

• 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 Central.
• 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