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.

A firewall suporta, no máximo, 20 servidores de autenticação no total, e para cada método de autenticação podem também ser selecionados, no máximo, 20 servidores. A ausência de outro servidor ao adicioná-lo ou na seleção não significa automaticamente uma falha de ligação. Primeiro, verificar a quantidade total, a seleção e a necessidade real de cada servidor.

O User Portal e o VPN Portal podem herdar a lista de servidores de autenticação da firewall através de Set authentication methods same as firewall. O SSL VPN pode, da mesma forma, usar Same as VPN ou Same as firewall. Esta herança é prática, mas amplia o efeito de alterações posteriores na seleção ou na ordem dos servidores. Por isso, durante o diagnóstico, deve documentar-se sempre a lista efetivamente herdada. Administrator authentication methods também não se aplica ao superadministrador local admin; o respetivo percurso de recuperação deve ser mantido e testado separadamente.

Verificar separadamente os limites globais de sessão: Maximum session timeout termina uma sessão autenticada quando atinge a duração máxima. O SFOS verifica a autorização a cada três minutos; Access Policies, Surfing Quota, Data Transfer Limit e a duração máxima da sessão podem limitar o acesso mais cedo. O valor global Simultaneous logins aplica-se apenas a utilizadores criados depois de o valor ser definido.

No SFOS 22 e no SFOS 23, os valores específicos de cada método em Authentication > Services também são verificados separadamente: AD SSO settings (NTLM and Kerberos) e Web client settings (iOS, Android and API) têm, cada um, Inactivity time e Data transfer threshold. Se, durante o período configurado, for transferida uma quantidade de dados inferior ao mínimo, o utilizador é considerado inativo; Inactivity time define após quanto tempo de inatividade a sessão é terminada. Se uma sessão terminar inesperadamente, documentar primeiro o Client Type utilizado, ambos os valores do bloco correspondente e o tráfego real no mesmo período. Não alterar, em alternativa, o valor global Maximum session timeout nem os temporizadores de STAS ou Captive Portal.

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.

Substituir eDirectory antes da atualização: A integração nativa eDirectory pertence ao SFOS 22. Antes de atualizar para SFOS 23.0 ou posterior, validar uma alternativa suportada para todos os serviços afetados e remover a configuração nativa eDirectory; se esta permanecer, a atualização falha. Não eliminar a autenticação de produção antes de verificar os inícios de sessão pela alternativa, os grupos, as políticas e um acesso local de recuperação independente. Migrar eDirectory em segurança descreve a transição controlada e a recuperação.

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:

Limite de capacidade: O SFOS 22 suporta, no máximo, 32,000 utilizadores ativos. Utilizadores e grupos partilham o intervalo de User ID; para o diagnóstico, um ID visível até 65535 é válido. Em ambientes muito grandes, verificar este limite separadamente de uma falha de início de sessão individual. Não eliminar sessões ou objetos de utilizador sem controlo.

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?

O tipo deve ser interpretado pela sua origem, e não como um início de sessão genérico. As sessões de Captive Portal no browser e as sessões de convidados aparecem como Web client, Android web client ou iOS web client. Os mapeamentos iniciados pelo cliente incluem STAS, Thin client, Heartbeat e API; o SSO iniciado pelo servidor inclui RADIUS SSO e Chromebook SSO. eDirectory SSO pertence apenas à lista do SFOS 22; o SFOS 23 remove o SSO nativo de eDirectory e deixa de apresentar este tipo na lista. As entradas VPN distinguem IPsec VPN, SSL VPN, L2TP VPN e PPTP VPN. O tipo observado deve corresponder ao mecanismo previsto.

Os Clientless Users são a exceção ao teste com um novo início de sessão: aparecem na lista assim que são configurados, porque o SFOS os autentica pelo endereço IP, e deixam de aparecer quando estão Inactive.

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, selecionar uma sessão normal existente em Live users, clicar em Disconnect, alterar o texto da notificação se necessário e confirmar com Disconnect. Depois de desligar manualmente uma sessão AD SSO, podem decorrer até três minutos antes de o utilizador conseguir iniciar sessão novamente. A notificação só chega aos utilizadores com sessão iniciada através de Authentication agent, Android client, iOS client ou Chromebook SSO.

Os Clientless Users não terminam sessão com Disconnect. Em vez disso, colocar o utilizador específico como Inactive em Authentication > Clientless users. Se Disconnect já tiver sido usado num Clientless User e for necessário restaurar o acesso, alterar o estado do utilizador para Inactive e depois para Active.

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.

Se apenas a MFA falhar, verificar Issued tokens, o estado do token e a hora na firewall e no telemóvel. Synchronize token time offset permite detetar e corrigir desvios de relógio. O SFOS 22 suporta SHA1, SHA256 e SHA512; a aplicação de autenticação tem de suportar o algoritmo configurado. Alterar o algoritmo ou eliminar um token não é um teste de diagnóstico, mas uma migração ou novo registo planeado.

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. O nome de utilizador e a palavra-passe podem ter, no máximo, 50 carateres cada.

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.

Se /log/nasm.log mostrar um erro KVNO, o cliente pode ainda ter um ticket Kerberos com a versão de chave anterior depois de a firewall voltar a aderir ao domínio. Primeiro, bloquear e desbloquear o cliente Windows ou terminar e voltar a iniciar a sessão do utilizador para obter um novo ticket. Se o erro persistir, verificar o Key Version Number, o objeto de computador da firewall e o SPN no controlador de domínio; repetir o Domain Join não é o primeiro passo.

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.

O Legacy SATC Client deixou de ser suportado. A Sophos recomenda migrar as instalações SATC para o Sophos Server Protection no Sophos Fusion. Antes do diagnóstico, é necessário identificar qual cliente SATC está realmente instalado; alterar regras de firewall ou grupos não corrige um cliente legacy obsoleto.

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. O VPN Portal não suporta autenticação RADIUS com MFA baseada em challenge; por isso, um fluxo de challenge recusado nesse portal não indica uma falha na ordem dos servidores.

SFOS 22: 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.

SFOS 23.0: Em Authentication > Servers, o tipo de servidor é OpenID Connect; IdP vendor distingue Microsoft Entra ID de Google Workspace. Para o serviço realmente afetado, usar os procedimentos de validação por versão de Entra WebAdmin, Entra VPN Portal e acesso remoto ou Google Workspace OIDC. Redirect URI, atribuição do serviço, grupos ou mapeamento de administrador, MFA e testes positivos, negativos e do acesso local de recuperação continuam a ser verificações separadas. Um início de sessão bem-sucedido no IdP não concede automaticamente direitos de administrador.

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

Os seguintes exemplos de leitura Entra específicos por serviço aplicam-se apenas ao SFOS 22, não ao SFOS 23:

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.
• SFOS 22: oauth_sso_captive.log corresponde ao fluxo Entra SSO do Captive Portal.
• SFOS 22: oauth_sso_webadmin.log corresponde a Entra SSO para WebAdmin.
• SFOS 22: oauth_sso_vpn.log corresponde a Entra SSO para VPN Portal, IPsec e SSL VPN.

SFOS 23.0: Verificar o fluxo de início de sessão OIDC em /log/oauth_sso_svc.log. Para Entra, um erro TLS de Test connection deve, em alternativa, ser analisado em /log/sfos-macro-cfg.log. No Log viewer, usar Admin para WebAdmin e Authentication para Captive Portal, VPN Portal, IPsec e SSL VPN. Os procedimentos dos fornecedores ligados acima associam a validação e o diagnóstico ao serviço real; este diagnóstico apenas de leitura não exige reinícios.

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