Sophos Firewall: AD SSO falha após upgrade para SFOS 22

Após um upgrade do SFOS 21.5 ou anterior para o SFOS 22.0 GA, o Active Directory Single Sign-On com Kerberos e NTLM pode falhar imediatamente. A firewall continua a encaminhar o restante tráfego, mas deixa de reconhecer os utilizadores de domínio afetados. Como resultado, as regras de firewall baseadas em utilizadores deixam de corresponder como previsto.

⚠️ O cleanup só pode ser utilizado na Advanced Shell e apenas quando o caminho de upgrade e o cenário de erro correspondem ao problema descrito. Se a firewall já estiver no MR1 Build 490 ou mais recente, se o erro já existia antes do upgrade ou se estiver envolvido um cluster HA, o comando não deve ser executado indiscriminadamente.

Se a firewall ainda executar o SFOS 22.0 GA e o nasm.log apresentar no momento correspondente um erro com unknown option, o NASM pode ser reconstruído de forma direcionada. As verificações seguintes evitam que o cleanup seja usado num problema comum de DNS, SPN ou Domain Join.

Estão documentados dois IDs diferentes para esta falha: NC-176853 e NC-176039. A própria KBA-000048429 não fornece qualquer ID NC. Este artigo regista diretamente o estado concreto da versão: ambos os registos indicam SFOS 22.0 MR1 Build 490 como versão corrigida; a KBA designa-a SFOS v22.0.1 MR-1. Por isso, nenhum dos IDs é tratado como o único canónico. Antes de uma alteração, os dados dinâmicos sobre builds aprovadas, maintenance release atual e caminho de upgrade são verificados com a verificação antes do upgrade para o SFOS 22. O cleanup é uma reparação específica para o caso de upgrade para GA descrito, não uma solução geral para todos os problemas de AD SSO.

Quando este procedimento se aplica

O procedimento destina-se ao seguinte caso:

• upgrade do SFOS 21.5 ou anterior para o SFOS 22.0 GA
• o AD SSO com Kerberos e NTLM funcionava antes do upgrade
• depois do upgrade, os utilizadores de domínio deixam de conseguir autenticar-se por AD SSO
• as regras baseadas em identidade deixam de reconhecer os utilizadores
• outras funções da firewall e logins não baseados em AD continuam a funcionar

Um Test connection bem-sucedido em Authentication > Servers não exclui este erro. O teste confirma a ligação ao Domain Controller e as credenciais, mas não todo o processo de AD SSO.

Se o próprio Test connection falhar, a causa estará provavelmente na acessibilidade, DNS, porta, certificado ou conta de serviço. Estes fundamentos são explicados em Ligar Active Directory à Sophos Firewall.

Verificar o erro em nasm.log

Iniciar sessão na firewall por SSH e abrir 5. Device Management > 3. Advanced Shell. O acesso SSH à Sophos Firewall é explicado separadamente.

Em seguida, procurar o sinal de confirmação específico deste problema:

grep "unknown option" /log/nasm.log

Este resultado só confirma o erro de upgrade descrito se o timestamp corresponder ao upgrade e à falha; uma entrada antiga não comprova um erro atual.

Se o comando não produzir resultados, falta o sinal de confirmação necessário. O cleanup não deve ser executado por suspeita. Devem verificar-se primeiro DNS, SPN, Domain Join, Redirection Location, confiança do browser e a configuração normal de Kerberos/NTLM; se o caminho de upgrade e os sintomas continuarem a corresponder, deve contactar-se o Sophos Support.

Limpar o NASM de forma direcionada

Ao mudar de firmware, o SFOS volta a criar os diretórios NASM de acordo com a versão de Samba utilizada. No upgrade afetado, este passo pode ficar incompleto. O novo NASM carrega então componentes Samba mais antigos e incompatíveis, provocando a falha do AD SSO.

Antes da alteração, devem ser documentados a versão atual do firmware, o momento da falha e o resultado do nasm.log. Deve também existir um acesso de administrador local ou alternativo para o caso de a autenticação não estar disponível durante os trabalhos.

A Sophos identifica o cleanup como a solução preferida para uma firewall que execute atualmente o SFOS 22.0 GA. Executar na Advanced Shell:

opcode -ds nosync nasm_cleanup

O comando força o cleanup e a regeneração do ambiente NASM em conformidade com Samba 4.22.1; normalmente não é necessário reiniciar depois. A Sophos não especifica uma mensagem de sucesso concreta nem um comando para desfazer a operação. Por isso, o sucesso não deve ser avaliado com base numa única saída da Shell, mas através de um novo login AD SSO. Se o resultado for inesperado, não se deve repetir o comando; as informações registadas antes da intervenção devem ser entregues ao Sophos Support com a referência KBA-000048429.

Validar o AD SSO com tráfego real de utilizador

Após o cleanup, repetir o Test connection não é suficiente. A validação deve usar um utilizador de domínio e uma regra realmente baseada em utilizador:

1. Num cliente de domínio, abrir uma nova ligação de browser que utilize AD SSO e uma regra de firewall baseada em utilizador.
2. Em Current activities > Live users, verificar se o utilizador de domínio volta a aparecer.
3. Abrir Log viewer no canto superior direito, selecionar Authentication no seletor de módulos e consultar Log Comp para ver se é utilizado Kerberos ou NTLM. Kerberos authentication initialized successfully e NTLM authentication channel established successfully confirmam uma inicialização bem-sucedida.
4. No log da firewall, verificar se utilizador, grupo e Firewall Rule ID correspondem à regra prevista.
5. Testar a aplicação ou o destino que não estava acessível antes do cleanup.

O erro só fica corrigido quando a identidade do utilizador e o match da regra estão corretos. Se o log Authentication apresentar Cannot initialize Kerberos authentication ou Cannot establish NTLM authentication channel, o canal AD ainda não está operacional. Se voltar a aparecer apenas um login de Captive Portal ou se o utilizador continuar ausente, a verificação deve incluir também SPN, resolução DNS, Redirection Location e confiança do browser. O mapeamento de outros ficheiros de autenticação encontra-se em Sophos Firewall Troubleshooting: serviços e logs.

Solução permanente e alternativa sem Advanced Shell

Atualizar para uma versão SFOS corrigida

A KBA indica SFOS v22.0.1 MR-1 como versão corrigida; apesar da discrepância entre os IDs NC-176853 e NC-176039, ambos os registos atuais indicam SFOS 22.0 MR1 Build 490 como destino com a correção. Em 4 de setembro de 2026, o SFOS 22.0 MR2 Build 546 é a versão 22.0 atual. Antes de qualquer alteração, este estado dinâmico deve ser novamente verificado com a verificação de upgrade para SFOS 22. Deve instalar-se a maintenance release mais recente aprovada para o modelo e caminho de upgrade em causa, em vez de escolher deliberadamente uma versão intermédia já ultrapassada. A mesma verificação também abrange o caminho de upgrade, backup, armazenamento, HA e caminho de reversão antes da mudança de firmware.

Se o mesmo sintoma surgir pela primeira vez no MR1 Build 490 ou numa versão mais recente, o erro de upgrade para GA aqui descrito deixa de ser uma correspondência inequívoca. Nesse caso, não se repete o cleanup; executa-se o diagnóstico normal de AD SSO e envolve-se o Sophos Support, se necessário.

Quando a Advanced Shell não está acessível

Quando a Advanced Shell não está acessível, uma nova mudança de firmware pode voltar a criar os diretórios NASM:

• Se a firewall já estiver novamente no SFOS 21.5, voltar a iniciar no SFOS 22.0 GA.
• Se a firewall estiver no SFOS 22.0 GA, iniciar primeiro no slot de firmware SFOS 21.5 existente e depois novamente no SFOS 22.0 GA.

Este percurso volta a iniciar a criação dos diretórios NASM. Provoca indisponibilidade e não é o mesmo que um reinício normal. No WebAdmin, abrir Backup and firmware > Firmware e selecionar Boot firmware image para o slot inativo. As duas partições mantêm configurações separadas. Enquanto o SFOS 21.5 estiver ativo, vigora a configuração anterior; ao regressar à partição 22.0, a configuração correspondente volta a ficar ativa. Não devem ser feitas alterações à configuração de produção durante este percurso, porque as partições não as partilham.

Antes de começar, deve planear-se uma janela de manutenção, guardar externamente um backup atual e confirmar que o firmware inativo é compatível e está disponível. O acesso à consola é uma precaução sensata. Após cada arranque, deve confirmar-se no Control Center qual é a versão ativa. Não está definida uma sequência específica para os nós HA; num cluster HA, qualquer uma das soluções deve ser coordenada com o Sophos Support. Se estes requisitos não forem cumpridos, é mais seguro fazer o upgrade direto para uma versão corrigida ou seguir um procedimento coordenado com o Sophos Support.

Quando o cleanup não é a solução certa

O nasm_cleanup não deve ser usado como comando geral de reparação. É necessário outro caminho de diagnóstico quando:

• a firewall já executa o SFOS 22.0 MR1 Build 490 ou mais recente
• o problema já existia antes do upgrade
• o Test connection ao servidor AD falha
• apenas alguns utilizadores, grupos ou browsers são afetados
• o problema envolve STAS, Microsoft Entra ID SSO, RADIUS ou um login LDAP normal
• DNS, SPN, Domain Join, certificados ou confiança do browser não funcionam corretamente
• o caminho de upgrade ou o momento da falha não corresponde ao erro descrito
• está envolvido um cluster HA; não está definida uma sequência específica para os nós HA

Nestes casos, um cleanup não corrige uma configuração incorreta e pode ocultar a causa real. Primeiro deve delimitar-se o método de autenticação afetado; perante um comportamento pouco claro ou divergente, o Sophos Support é o ponto de escalamento adequado.