Resolver sistematicamente erros de autenticação na Sophos Firewall

Um erro de autenticação na Sophos Firewall pode ocorrer em pontos muito diferentes. O servidor pode estar acessível, mas não selecionado para o serviço afetado. O início de sessão pode funcionar enquanto o grupo principal, uma quota ou uma regra de firewall impede o acesso. Ou a firewall pode não reconhecer o utilizador e processar o tráfego apenas com base no endereço IP.

O percurso rápido e seguro separa deliberadamente estas camadas:

1. Registar o utilizador, IP de origem, serviço afetado, hora e resultado esperado.
2. Testar a acessibilidade do portal ou serviço de autenticação a partir da zona de origem real.
3. Em Authentication > Services, verificar se o servidor correto está selecionado para o serviço afetado e na posição pretendida.
4. Executar Test connection no servidor de autenticação, mas considerar o resultado apenas como prova das credenciais e da conectividade ao servidor.
5. Gerar um novo início de sessão e verificar o utilizador, IP de origem e Client Type em Current activities > Live users.
6. Em Authentication > Users, verificar estado, grupo principal, outros grupos, substituições do utilizador e User ID.
7. Verificar Access Time, quotas, MFA e Sign-in Restrictions apenas para o utilizador realmente afetado ou para o respetivo grupo efetivo.
8. Só depois de a identidade ser confirmada, testar com tráfego real a regra de firewall esperada, Rule ID, política web ou VPN, NAT e encaminhamento.

⚠️ Não alterar de forma abrangente servidores de autenticação, ordem dos grupos, quotas ou Device Access com base numa suspeita. Reiniciar um serviço, executar Purge AD users ou criar uma regra Any não é um primeiro passo normal de diagnóstico. Primeiro é necessário provar em que camada o processo termina.

Cinco camadas em vez de um único erro de início de sessão

Na prática, um modelo simples ajuda. O acesso de um utilizador não passa por uma única verificação, mas por pelo menos cinco camadas separadas:

1. Acessibilidade: o cliente e a firewall chegam ao portal, proxy ou servidor de autenticação pelo percurso previsto.
2. Serviço e método: o servidor de autenticação correto está selecionado em Authentication > Services para este serviço específico.
3. Identidade: a firewall reconhece o utilizador esperado e apresenta-o com o IP de origem correto e o Client Type adequado.
4. Autorização: estado do utilizador, grupo, grupo principal, Access Time, quota, MFA e permissões específicas do serviço estão corretos.
5. Tráfego posterior: uma regra de firewall, política web ou política VPN permite os destinos necessários e o percurso de retorno funciona.

Esta separação evita duas conclusões erradas frequentes. Um Test connection verde não prova que o início de sessão SSO funciona. Inversamente, um utilizador em Live users ainda não prova que o respetivo tráfego corresponde à regra ou política pretendida.

Definir um caso de teste reproduzível

Antes da primeira alteração, definir um único caso de teste. Valores de documentação seguros incluem, por exemplo:

• Utilizador: auth-pilot@example.com
• IP do cliente: 192.0.2.25
• Zona de origem: LAN
• Serviço: Firewall authentication, User portal, VPN portal, SSL VPN ou Web admin console
• Hora do teste: hora local da firewall com data e minuto
• Grupo esperado: Internet-Standard
• Regra esperada: LAN-Users-to-WAN
• Resultado esperado: início de sessão bem-sucedido e acesso HTTPS a um destino de teste definido

example.com e 192.0.2.0/24 são valores de documentação. Substituir nome de utilizador, IP de origem, zona, grupo, regra e destino por valores piloto reais. O piloto deve usar a mesma origem de autenticação e o mesmo grupo de permissões do utilizador afetado, mas sem privilégios administrativos desnecessários.

Se possível, testar também um utilizador de comparação funcional da mesma origem. Se ambos falharem, a causa encontra-se mais provavelmente no serviço, servidor ou acessibilidade. Se apenas um utilizador falhar, são mais prováveis o objeto do utilizador, grupos, quotas, MFA ou Sign-in Restrictions.

Verificar serviço, acessibilidade e servidor

Verificar Device Access apenas para o serviço necessário

Os portais e serviços de autenticação locais não são autorizados por regras de firewall normais. Em Administration > Device access, ou com uma Local service ACL exception rule direcionada, o serviço necessário deve estar acessível a partir da zona de origem prevista ou das redes de origem conhecidas.

Dependendo do teste, podem ser relevantes entradas diferentes, como Captive portal, User portal, VPN portal, SSL VPN, AD SSO ou Client Authentication. Verificar apenas o serviço realmente necessário. Uma autorização geral para LAN ou WAN ocultaria a falha e poderia expor outros serviços de gestão ou portais. Device Access e Local Service ACL na Sophos Firewall explica este limite de segurança.

A acessibilidade por si só ainda não é autenticação. Uma página de portal visível confirma apenas que o cliente chega ao serviço local. O nome de utilizador, palavra-passe, token SSO, grupo e regra de firewall posterior ainda não foram testados.

Verificar o método de autenticação por serviço

Em Authentication > Services, cada serviço tem a sua própria seleção de servidores. Por isso, não basta confirmar que existe um servidor AD, LDAP, RADIUS ou Entra. É necessário verificar se está selecionado para o serviço afetado:

• Firewall authentication methods para tráfego de utilizadores e autenticação clássica da firewall;
• User portal authentication methods para o User Portal;
• VPN portal authentication methods para o VPN Portal;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods para estes inícios de sessão VPN;
• Administrator authentication methods para administradores nominativos;
• SSL VPN authentication methods para SSL VPN.

Com vários servidores, a ordem também é relevante. Não mover prematuramente um servidor para o topo. Primeiro, documentar a ordem atual, o Default Group e o utilizador de comparação funcional. Caso contrário, uma alteração pode afetar outros utilizadores ou serviços. Para administradores externos, TACACS+ para o WebAdmin da Sophos Firewall separa também a autenticação do servidor, o perfil de administrador local e um fallback seguro contra bloqueios.

Interpretar corretamente Test connection

Em Authentication > Servers, Test connection verifica as credenciais e a ligação entre a firewall e o servidor. Se falhar, corrigir primeiro DNS, encaminhamento, porta, segurança da ligação, cadeia de certificados, conta de serviço ou palavra-passe.

No entanto, um teste bem-sucedido é apenas a primeira camada. Para AD SSO, não testa Kerberos, NTLM, SPN, Redirection Location, confiança do browser nem o acesso real do utilizador. Nos inícios de sessão de portal e VPN, a seleção do serviço, grupo, MFA e política também precisam de ser testados separadamente. Ligar Active Directory à Sophos Firewall descreve a configuração base completa de AD.

Usar Live Users como primeira prova de identidade

Depois de um novo início de sessão, abrir Current activities > Live users. Pelo menos três valores são importantes:

Para o Client Authentication Agent, o tipo de cliente tem de ser Authentication agent. Verificar também separadamente o percurso para 1.2.3.4:9922, a Authentication Server CA e o match efetivo da regra de firewall.

• User: o utilizador detetado corresponde realmente à conta piloto?
• IP address: o endereço corresponde à ligação de cliente observada?
• Client Type: foi usado o percurso esperado, por exemplo AD SSO Kerberos, AD SSO NTLM, STAS, Multi-host client, Captive portal, RADIUS SSO ou um tipo de VPN?

Se o utilizador estiver ausente, a camada de identidade ainda não foi bem-sucedida. Não continuar a diagnosticar a regra de utilizador posterior. Se aparecer o nome de um computador em vez do utilizador com sessão iniciada, um serviço do sistema operativo, como o Windows Update, pode ter enviado as credenciais NTLM do dispositivo. Um início de sessão interativo real do utilizador e um novo pedido web permitem isolar este caso.

Um utilizador externo de AD, LDAP ou RADIUS normalmente só aparece em Authentication > Users depois do primeiro início de sessão bem-sucedido num serviço da firewall. Por isso, a ausência de um registo local não prova que a conta não existe no diretório. Para uma conta gerida diretamente no SFOS, criar e gerir utilizadores locais normais descreve, pelo contrário, todo o processo de conta, serviço, testes e offboarding.

Para repetir o teste de forma limpa, uma sessão normal existente pode ser desligada em Live users. Depois de desligar manualmente uma sessão AD SSO, podem decorrer até três minutos antes de o utilizador conseguir iniciar sessão novamente. Os Clientless Users não terminam sessão nesse local com Disconnect; devem ser colocados como Inactive em Authentication > Clientless users.

Verificar o objeto do utilizador, grupo principal e restrições

Quando o utilizador estiver visível ou já existir um registo local, continuar em Authentication > Users. Não alterar valores às cegas. Primeiro, documentar as propriedades efetivas:

• estado Active ou Inactive;
• campo Group como grupo principal para utilizadores AD;
• Other group memberships;
• substituições de política específicas do utilizador;
• Access Time e Sign-in Restriction;
• Surfing Quota e Network Traffic Quota;
• atribuição MFA para o serviço afetado;
• propriedade adicional User ID.

Não considerar equivalentes o grupo principal e os outros grupos

Um utilizador AD pode pertencer a vários grupos. A Sophos Firewall mostra o grupo principal efetivo no campo Group e as outras associações separadamente. As regras de firewall, políticas web e algumas outras funções podem considerar vários grupos. Access Time, quotas, MFA e várias funções de acesso remoto usam, porém, apenas o grupo principal ou uma atribuição explícita ao utilizador.

Por isso, não alterar a ordem dos grupos como solução rápida. Primeiro, determinar qual função falha e qual lógica de grupos suporta. Depois de uma alteração planeada, autenticar novamente o utilizador e voltar a verificar o grupo principal.

O procedimento operacional completo, desde a criação de grupos e o Default Group até Reorder, vários grupos, substituições dos utilizadores e reversão, encontra-se em Gerir corretamente grupos de utilizadores e o grupo principal na Sophos Firewall.

Tratar Access Time, quotas e MFA como causas distintas

Um Captive Portal inesperado ou um início de sessão recusado também pode ser causado por um Access Time bloqueado, uma Surfing Quota ou Network Traffic Quota esgotada ou um registo MFA em falta. Comparar estas definições no utilizador e no respetivo grupo efetivo.

As verificações e os percursos de recuperação correspondentes estão descritos em Access Time para utilizadores e grupos, Surfing e Network Traffic Quota e MFA para Sophos Firewall. Não repor uma quota nem alargar uma política Access Time antes de provar a respetiva atribuição efetiva.

Atribuir o limite de User ID apenas depois de ver o valor

Em Show additional properties, é possível apresentar o User ID. Um valor superior a 65535 fica fora do intervalo suportado; o utilizador não consegue autenticar-se nem tornar-se Live User. O número de utilizadores visíveis, por si só, não é suficiente para este diagnóstico, porque os grupos partilham o mesmo intervalo de IDs.

Se o ID for válido ou o utilizador continuar completamente ausente, prosseguir com o diagnóstico geral. Purge AD users pertence apenas a um caso de limpeza comprovado. O procedimento especializado seguro encontra-se em Verificar o limite de User ID da Sophos Firewall.

Prosseguir com o método efetivamente utilizado

Quando o serviço e a camada da falha forem conhecidos, aprofundar apenas o percurso do método relevante. Assim, o diagnóstico permanece limitado e não altera vários sistemas de autenticação em simultâneo.

Início de sessão clássico e Captive Portal

Num início de sessão manual, verificar o URL direto do portal, Device Access, o método de autenticação selecionado, estado do utilizador, palavra-passe e MFA. Para Captive Portal, verificar também se a ligação desconhecida chega à regra prevista com Use web authentication for unknown users e se o DNS funciona antes do início de sessão.

A configuração completa, incluindo a porta 8090, Live Users, a regra de utilizador e o fim de sessão, está em Configurar e testar o Captive Portal da Sophos Firewall.

AD SSO com Kerberos ou NTLM

Um teste de ligação AD bem-sucedido não é suficiente para SSO. O nome de host ou FQDN, resolução DNS, Redirection Location, certificado, confiança do browser, Domain Join e, para Kerberos, o HTTP SPN correspondente também têm de estar corretos. Se Kerberos recuar para NTLM ou Captive Portal, verificar primeiro este percurso de nomes e confiança.

nasm.log é relevante para erros de NTLM e Kerberos. Não alterar SPN ou Domain Join às cegas; primeiro, guardar o estado existente na firewall e no controlador de domínio.

STAS, SATC e hosts multiutilizador

Com o Synchronized User ID Authentication, a identidade de domínio Windows e o IP do cliente chegam através do Security Heartbeat. O estado do endpoint, o domínio UPN, sAMAccountName, a validação AD e Live users devem coincidir; um heartbeat verde, por si só, não comprova a regra de utilizador.

Com STAS, o mesmo IP de cliente deve ser acompanhado através dos eventos do Windows, STA Agent, Collector e firewall. Se o utilizador faltar apenas em Live Users, verificar a acessibilidade do Collector, redes monitorizadas, Exclusion List e Client Authentication. O processo completo está em Configurar STAS na Sophos Firewall.

Vários utilizadores simultâneos atrás de um único IP de servidor de terminais exigem um modelo de sessão. SATC para Remote Desktop Services consegue associar vários protocolos a uma sessão. Per-Connection AD SSO para hosts multiutilizador, por outro lado, aplica-se apenas a ligações HTTP e HTTPS através do Direct Web Proxy. Um mapeamento normal baseado em IP não consegue distinguir de forma fiável vários utilizadores atrás do mesmo endereço.

RADIUS SSO, Entra ID e VPN

RADIUS SSO necessita de eventos de accounting com o IP de cliente correto; um teste de acesso RADIUS bem-sucedido não prova este percurso de accounting. RADIUS SSO com accounting descreve a configuração e verificação de Framed-IP-Address.

Para Microsoft Entra ID SSO, verificar também o fluxo OAuth específico do serviço. Captive Portal, VPN Portal e WebAdmin usam Redirect URIs, métodos de autenticação e ficheiros de log diferentes. Um início de sessão bem-sucedido num destes serviços não prova os restantes.

Para VPN, depois da autenticação, verificar ainda se o utilizador ou o respetivo grupo está na política de acesso remoto correta. Um estado verde do túnel ainda não prova o acesso a destinos internos.

A autenticação funciona, mas o tráfego continua bloqueado

Quando o utilizador está visível em Live users com o IP esperado, deslocar o diagnóstico para a autorização e o percurso dos pacotes. Um fluxo de teste real deve mostrar:

1. Qual Firewall Rule ID processa a ligação?
2. Esta regra contém o utilizador esperado ou um grupo suportado?
3. Log firewall traffic está ativo?
4. A regra seleciona a política web, Application, IPS ou Traffic Shaping correta?
5. Destino, serviço, NAT, route e percurso de retorno correspondem?

Uma regra IP geral acima da regra de utilizador pode já processar o tráfego. Da mesma forma, a regra de utilizador correta pode corresponder enquanto a política web, TLS Inspection, DNS, encaminhamento ou sistema de destino bloqueia o acesso posterior. Por isso, não utilizar uma alteração de autenticação como correção para um erro comprovado de encaminhamento ou política.

Testar corretamente uma regra Sophos Firewall explica a validação completa com Log Viewer, Policy tester e Packet Capture.

Correlacionar Log Viewer e ficheiros de log

No Log viewer, verificar o módulo Authentication com o utilizador registado, o IP de origem e um período de teste curto. Em seguida, procurar o mesmo momento no módulo firewall ou VPN. Assim é possível determinar se falha o próprio início de sessão ou se apenas o fluxo de dados posterior é bloqueado.

Para autenticação, autorização e accounting clássicos, access_server.log é o primeiro ficheiro a verificar. Na Advanced Shell, os seguintes comandos são apenas de leitura:

cd /log
tail -n 200 access_server.log

Adicionar apenas o ficheiro relevante para o método:

tail -n 200 nasm.log
tail -n 200 oauth_sso_captive.log
tail -n 200 oauth_sso_webadmin.log
tail -n 200 oauth_sso_vpn.log

• nasm.log corresponde a NTLM e Kerberos.
• oauth_sso_captive.log corresponde ao fluxo Entra SSO do Captive Portal.
• oauth_sso_webadmin.log corresponde a Entra SSO para WebAdmin.
• oauth_sso_vpn.log corresponde a Entra SSO para VPN Portal, IPsec e SSL VPN.

Os comandos leem apenas as últimas 200 linhas. Não ativam debug nem reiniciam serviços. Adicionar ficheiros como vpnportal.log, sslvpn.log, strongswan.log, chromebook-sso-backend.log ou csd.log apenas depois de selecionar o método. Logs de serviços da Sophos Firewall explica a correspondência.

Num cluster HA, cada nó guarda logs e relatórios apenas do tráfego que processa. Registar a função, hora do teste e nó de processamento, e verificar os ficheiros nesse nó. Um ficheiro vazio no outro dispositivo não invalida a falha.

Delimitar a falha pelo sintoma

Test connection é bem-sucedido, mas SSO não funciona

O servidor de autenticação e as respetivas credenciais estão acessíveis. Em seguida, verificar Authentication > Services, Device Access, Live Users e o percurso SSO específico do método. Para AD, isto inclui especialmente DNS, FQDN, Redirection Location, SPN, confiança do browser, Domain Join e nasm.log.

Captive Portal aparece em vez do início de sessão transparente

Primeiro, determinar se AD SSO ou STAS deveria identificar o utilizador antes do acesso web. Depois, verificar Client Type em Live Users, o módulo Authentication, Access Time, quotas e credenciais. O portal é um sintoma de identidade ausente ou rejeitada, não automaticamente uma falha do portal.

Surge o nome do computador em vez do nome de utilizador

Um serviço do sistema pode enviar as credenciais NTLM do endpoint mesmo que nenhum utilizador tenha iniciado sessão interativamente. Iniciar sessão com um utilizador real, abrir uma nova sessão de browser e repetir o teste. Se o nome do computador permanecer, verificar o percurso do browser ou proxy, método SSO e nasm.log.

O utilizador não aparece em Live Users

Primeiro, verificar a seleção do serviço, Device Access e o método concreto. Para STAS, Collector e firewall devem ver o mesmo IP; para Captive Portal, o início de sessão deve realmente terminar; para servidores externos, o registo local do utilizador só é criado após um início de sessão bem-sucedido. Verificar User ID, Sign-in Restriction e quotas apenas quando existir um registo de utilizador correspondente.

O utilizador está visível, mas o grupo ou a política está errado

Em Authentication > Users, comparar o grupo principal, Other group memberships e substituições do utilizador. Em seguida, verificar se a função concreta suporta vários grupos. Alterar a ordem dos grupos apenas numa janela de manutenção planeada, porque isso também pode deslocar MFA, quotas, Access Time, VPN e outras políticas.

O início de sessão funciona, mas a internet ou o destino VPN permanece inacessível

A autenticação já não é a primeira camada de falha. Verificar Firewall Rule ID, ordem das regras, logging, política web ou VPN, NAT, route e percurso de retorno com um fluxo real. Tanto a identidade do utilizador como o percurso dos pacotes têm de estar corretos.

A falha ocorre apenas depois de um failover HA ou esporadicamente

Registar build do firmware, mudança de função, função ativa do nó, hora do início de sessão e método de autenticação. Testar um novo início de sessão e uma nova ligação depois do failover. Depois, verificar os logs no nó que processou a tentativa. Não considerar uma sessão existente como prova de uma nova autenticação bem-sucedida.

Condições de paragem e dados de suporte

Não efetuar mais alterações na configuração de produção quando:

• o serviço ou método de autenticação afetado não é inequívoco;
• Test connection falha e DNS, route, porta, TLS ou credenciais continuam por esclarecer;
• o utilizador piloto aparece com um Client Type inesperado ou IP de origem incorreto;
• não é possível explicar a atribuição do grupo principal, substituição do utilizador ou quota;
• um teste negativo obtém acesso inesperadamente;
• apenas uma autorização ampla de Device Access ou firewall parece fazer o teste funcionar;
• um problema HA não pode ser atribuído ao nó de processamento e ao momento.

Antes de escalar, recolher pelo menos:

• modelo do equipamento, versão SFOS e build completo;
• em HA, ambas as funções e o nó de processamento;
• origem de autenticação e serviço afetado;
• utilizador de teste, IP de origem, Client Type e intervalo de tempo;
• ordem dos servidores em Authentication > Services;
• resultado de Test connection com o seu significado limitado;
• estado, grupo principal, outros grupos, substituições e User ID;
• evento de autenticação, Firewall Rule ID e resultado do fluxo de teste real;
• logs correspondentes de autenticação, portal, VPN e firewall.

Os nomes de utilizadores e grupos podem conter informações sensíveis. Fornecer o pacote apenas através do canal de suporte previsto. Criar um Consolidated Troubleshooting Report e uma exportação direcionada de logs antes de reiniciar serviços, ativar debug ou limpar dados.

Lista de verificação

• O caso de teste contém utilizador, IP de origem, serviço, hora e resultado esperado.
• O serviço local está acessível apenas a partir da zona ou origem prevista.
• O servidor correto está selecionado em Authentication > Services para o serviço afetado.
• Test connection não foi confundido com um teste SSO completo.
• Live Users mostra utilizador, IP e Client Type esperado.
• Estado, grupo principal, outros grupos, substituições e User ID foram verificados.
• Access Time, quotas, Sign-in Restriction e MFA foram avaliados apenas no percurso efetivo do utilizador.
• O sucesso da autenticação e o fluxo posterior de firewall, web ou VPN foram testados separadamente.
• Log Viewer e o ficheiro de log correspondente foram correlacionados no mesmo intervalo temporal.
• Em HA, foi verificado o nó de processamento.
• Não foi usado um reinício geral, purge ou autorização ampla como solução rápida.
• Os dados de suporte foram recolhidos antes de outras alterações.

Perguntas frequentes