Ligar Active Directory à Sophos Firewall

Active Directory continua a ser, em muitos ambientes Sophos Firewall, a fonte central para utilizadores, grupos e autenticação. A firewall usa a ligação AD, por exemplo, para regras de utilizador, Remote Access VPN, Captive Portal, User Portal, Reporting ou cenários Single Sign-On.

Este artigo explica como adicionar um servidor Active Directory à Sophos Firewall, que campos são realmente importantes e como verificar a ligação depois. Para novos desenhos de Remote Access, deve também ser decidido se AD clássico, RADIUS ou Microsoft Entra ID SSO para Sophos Connect e VPN Portal se adequa melhor.

Se o Active Directory for o destino de um ambiente eDirectory existente, deve planear-se primeiro a migração controlada do eDirectory, incluindo a validação de grupos, o cutover por serviço e o caminho de reversão.

O seguinte vídeo Sophos Techvids mostra o processo base como complemento visual. Foi criado com SFOS v21; a lógica continua útil, mas algumas janelas podem ter aspeto ligeiramente diferente em SFOS 22.

O procedimento prático divide-se em quatro partes. Um teste de ligação bem-sucedido é apenas o início; VPN, portais, regras de utilizador e SSO têm de ser validados separadamente.

1. Adicionar o servidor: introduzir corretamente o Domain Controller, o domínio NetBIOS, a base de pesquisa e a conta de serviço.
2. Proteger a ligação: planear conscientemente LDAPS, validação do certificado e resolução DNS interna.
3. Importar grupos: importar apenas os grupos AD necessários e compreender a Main Group.
4. Testar a utilização: verificar início de sessão, MFA, VPN, User Portal, Captive Portal, SSO e Log Viewer.

Enquadramento

A Sophos Firewall pode usar várias fontes de autenticação. Active Directory faz sentido quando utilizadores e grupos já são mantidos localmente num domínio Windows e a firewall deve usar diretamente essas identidades.

Casos de utilização típicos:

• sincronização de utilizadores e grupos a partir do Active Directory local
• regras de firewall com referência a utilizadores ou grupos
• Remote Access VPN com utilizadores AD
• User Portal ou Captive Portal com contas de domínio
• Reporting por utilizador em vez de apenas por endereço IP
• Active Directory SSO com NTLM ou Kerberos

A ligação AD, porém, não significa automaticamente que todas as questões de autenticação estejam resolvidas. É necessário distinguir se a firewall apenas consulta utilizadores por LDAP/LDAPS, se grupos são importados, se SSO é utilizado ou se Remote Access precisa adicionalmente de MFA. Para fundamentos de MFA, consulte Ativar MFA para Sophos Firewall WebAdmin, VPN Portal e Remote Access.

Decisões importantes antes da configuração

Antes de adicionar o servidor, estes pontos devem estar esclarecidos:

• Ligação: sempre que possível, usar LDAPS com SSL/TLS na porta 636.
• Conta de serviço: usar uma conta AD dedicada com permissões de leitura em vez de Domain Admin.
• Base de pesquisa: pesquisar apenas as unidades organizacionais necessárias, não todo o domínio indiscriminadamente.
• Atributo de apresentação: escolher conscientemente sAMAccountName, userPrincipalName ou displayName.
• Grupos: importar apenas os grupos realmente necessários para a firewall, VPN ou portal.
• MFA: proteger adicionalmente o acesso remoto e os portais com MFA.
• Ordem dos servidores: definir conscientemente a ordem de consulta quando existem vários servidores AD.
• Operação: verificar regularmente os registos de autenticação, a importação de grupos, os certificados e a expiração da palavra-passe.

Também têm de estar definidos o encaminhamento e o caminho de origem da firewall até ao Domain Controller. LDAPS requer TCP 636 e STARTTLS TCP 389; a resolução DNS interna e uma cadeia de certificados completa e válida têm de funcionar a partir do caminho realmente usado pela firewall. Antes da alteração, crie e descarregue uma cópia de segurança cifrada da configuração em Backup and firmware > Backup and restore e guarde a respetiva palavra-passe em segurança.

⚠️ A ligação entre firewall e servidor de autenticação deve ser cifrada. LDAP não cifrado na porta 389 pode funcionar em laboratórios, mas não é uma boa solução permanente para ambientes produtivos.

Para integração AD, também são suportadas versões mais antigas de Windows Server, mas em ambientes atuais são sobretudo relevantes Windows Server 2016, 2019, 2022 e 2025. Desde SFOS 21.5 MR1, Active Directory SSO com Windows Server 2025 é possível para NTLM e Kerberos. SFOS 22 contém componentes Samba atualizados para autenticação Kerberos e NTLM e remove métodos de cifragem antigos. Especialmente após upgrades de firewall ou Domain Controller, AD SSO, importação de grupos e Remote Access devem, por isso, ser testados especificamente.

Importante: a Sophos Firewall não suporta atualmente enforcement estrito de LDAP Channel Binding e LDAP Signing. Se Domain Controllers impuserem requisitos LDAP muito rígidos, a ligação AD deve ser testada numa janela de manutenção antes de uma alteração produtiva.

Adicionar servidor Active Directory

A configuração é feita no WebAdmin da Sophos Firewall:

Authentication > Servers

Aí é criado com Add um novo servidor de autenticação e escolhido Active Directory como Server Type.

Campos da configuração Active Directory

A numeração na captura de ecrã foi escolhida deliberadamente: os campos mais importantes são explicados de cima para baixo. Consoante a versão SFOS, a ordem pode ser ligeiramente diferente. Em versões mais recentes, também se vê Validate server certificate quando a validação de certificado para LDAPS deve ser ativada.

1. Server type: para um domínio Windows clássico, use Active Directory. RADIUS, LDAP e Microsoft Entra ID são integrações diferentes e não devem ser confundidas.
2. Server name: nome interno apresentado na firewall. Não influencia DNS nem AD, mas deve ser inequívoco, por exemplo AD-ZH-DC01 ou AD-HQ-LDAPS. Com vários Domain Controllers, um nome claro ajuda no Log Viewer e na resolução de problemas.
3. Server IP/domain: endereço IP ou nome DNS do Domain Controller. O nome DNS é preferível quando corresponde ao certificado, à resolução DNS interna e ao failover. Um IP facilita o diagnóstico, mas prende a firewall a um controlador específico.
4. Port: porta da ligação LDAP. Em produção, prefira 636 com SSL/TLS. A porta 389 serve para LDAP não cifrado ou STARTTLS, mas não deve ser uma solução permanente.
5. NetBIOS domain: nome NetBIOS curto do domínio AD, por exemplo AVANET. Não é o nome DNS do domínio. Um valor incorreto impede frequentemente que os utilizadores sejam encontrados ou associados devidamente.
6. ADS user name: nome da conta usada para consultas AD. A Sophos utiliza o nome curto administrator no seu exemplo. Em produção, a Avanet recomenda uma conta de serviço dedicada com permissões para pesquisar, ler e consultar associações a grupos, em vez de uma conta Domain Admin. A Sophos não confirma que nome curto, DOMAIN\user e UPN sejam equivalentes em todas as configurações; use e documente o formato testado no seu AD.
7. Password: palavra-passe da conta de serviço. Se expirar ou mudar, as consultas, a importação de grupos e os inícios de sessão de VPN ou portal podem falhar subitamente; documente e monitorize a conta.
8. Connection security: para LDAPS, use SSL/TLS com a porta 636. STARTTLS usa normalmente 389 e requer suporte correto no Domain Controller. Simple não cifra a ligação e deve limitar-se a testes.
9. Display name attribute: atributo AD usado como nome apresentado. Tem de corresponder ao esquema do diretório e ser verificado com um utilizador de teste; a documentação geral da Sophos não indica valores predefinidos universalmente intercambiáveis. Para Microsoft Entra Domain Services, a Sophos indica expressamente DisplayName.
10. Email address attribute: atributo do endereço de email, normalmente mail. Só é útil se os endereços estiverem realmente mantidos no AD.
11. Domain name: nome DNS do domínio AD, por exemplo ad.example.com. Não é o nome NetBIOS e tem de corresponder ao domínio, à base de pesquisa e ao Domain Controller.
12. Search queries: base para consultas de utilizadores e grupos. Introduza um Distinguished Name como DC=ad,DC=example,DC=com ou restrinja-o a OU=Users,OU=Company,DC=ad,DC=example,DC=com. Uma OU específica limita os utilizadores visíveis e mantém a importação clara.

Apenas os utilizadores abrangidos por pelo menos uma Search query podem aparecer para este servidor AD em Current activities > Live users. Se um utilizador esperado não aparecer apesar de um Test connection bem-sucedido, verifica-se primeiro se o Base DN e o âmbito da OU incluem o respetivo objeto real no diretório. A search base não é alargada preventivamente a todo o domínio.

Se existirem vários Domain Controllers, deve ser decidido conscientemente se a firewall fala com um DC específico ou se um nome DNS interno estável aponta para uma infraestrutura AD adequada. O importante é que resolução DNS, certificado, routing e regras de firewall correspondam.

Validate server certificate

Em versões SFOS atuais, também pode ser ativado Validate server certificate. Isto faz sentido para LDAPS, porque a firewall não só estabelece uma ligação cifrada, como também verifica se confia no certificado do Domain Controller.

Para isso, estes pontos têm de estar corretos:

1. O certificado de servidor do Domain Controller é carregado em Certificates > Certificates > Add > Upload certificate. Um certificado apenas de CA pertence a Certificates > Certificate authorities; não confunda as duas listas.
2. Conforme indicado pela Sophos, introduza o CNAME em Server IP/domain; esse nome DNS tem de constar no Subject Alternative Name do certificado de servidor.
3. A firewall consegue resolver internamente o CNAME.
4. Data e hora em firewall e Domain Controller estão corretas.

Se a resolução DNS interna não resolver corretamente um CNAME ou o nome do Domain Controller, uma DNS Host Entry em Network > DNS > DNS host entry pode ajudar.

NetBIOS domain e domain name

A Sophos Firewall precisa tanto de dados sobre o NetBIOS domain como sobre o domain name. Estes valores devem corresponder exatamente ao domínio AD.

O NetBIOS domain encontra-se, por exemplo, em Active Directory Users and Computers, nas propriedades do domínio.

O domain name é o nome DNS do domínio, por exemplo ad.example.com.

Erros típicos neste ponto:

• NetBIOS name e DNS domain name são confundidos.
• O Domain Controller introduzido pertence a outro domínio.
• A firewall não consegue resolver o nome DNS do Domain Controller.
• Uma firewall de rede ou Windows Firewall bloqueia a ligação entre firewall e Domain Controller.

Conta de serviço e palavra-passe

Para acesso ao Active Directory, deve ser usada uma conta de serviço dedicada. Uma conta Domain Admin não é necessária para a consulta LDAP normal e aumenta o risco desnecessariamente.

Requisitos sensatos:

• conta própria para a firewall, por exemplo svc-sophos-fw-ldap
• apenas permissões de leitura necessárias
• responsável documentado pelas alterações da palavra-passe
• palavra-passe longa e única
• sem início de sessão interativo, se as políticas AD o permitirem corretamente
• monitorização ou lembrete antes da expiração da palavra-passe

Se a palavra-passe da conta de serviço expirar ou for alterada, a firewall deixa de conseguir consultar utilizadores e grupos. Mais tarde, isto aparece frequentemente como problema de VPN, portal ou regra de utilizador, embora a causa real esteja na ligação AD.

Segurança da ligação e LDAPS

Para ambientes produtivos, deve preferir-se LDAPS. O Domain Controller precisa de um certificado de servidor adequado. Com Validate server certificate ativo, siga a importação Sophos descrita acima para o certificado de servidor; qualquer certificado CA adicional é importado separadamente como Certificate Authority.

Deve verificar-se:

• A porta 636 é acessível da interface da firewall para o Domain Controller.
• O certificado do Domain Controller é válido.
• O nome do certificado corresponde ao nome DNS utilizado.
• O certificado de servidor e, se necessário, a CA emissora estão importados nas listas de certificados corretas.
• Hora e data em firewall e Domain Controller estão corretas.

Mantém-se um limite importante do produto: o SFOS 22 não suporta atualmente a aplicação estrita de LDAP Channel Binding e LDAP Signing. O LDAPS com validação de certificado protege a ligação, mas não comprova a conformidade com uma política de segurança AD que imponha channel binding ou signing. Se a organização exigir essa aplicação, a integração é validada com a política AD concreta antes do rollout e não é aprovada apenas com base num Test connection bem-sucedido.

Em temas de certificado, a distribuição de CA também é relevante. Para distribuir a CA da Sophos Firewall a clientes, consulte Distribuir certificado CA da Sophos Firewall para HTTPS Scanning. Para LDAPS, porém, a CA do Domain Controller ou da PKI interna é o ponto decisivo.

Ligar Microsoft Entra Domain Services

Um domínio gerido Microsoft Entra Domain Services pode ser ligado como servidor Active Directory. A Sophos inclui neste âmbito WebAdmin, Captive Portal, User Portal, Client Authentication Agent e Remote Access SSL VPN. Não se trata de SSO direto do Entra ID; em particular, esta documentação não confirma suporte para VPN Portal.

Em produção, ativar Secure LDAP e permitir a porta 636 do caminho firewall escolhido até ao domínio. O certificado de servidor precisa da Extended Key Usage Server Authentication. Em vez de expor LDAPS publicamente, usar se possível um caminho Azure ou IPsec privado e limitar a Network Security Group ao endereço de origem necessário.

O exemplo oficial da Sophos usa o IP público de Secure LDAP, SSL/TLS, porta 636, DisplayName e mail, e desativa Validate server certificate. A ligação privada por redes Azure ou IPsec é uma recomendação de segurança adicional da Sophos. A validação com nome correspondente e cadeia de confiança correta é uma recomendação de reforço da Avanet, que deve ser testada no ambiente local e não apresentada como parte do exemplo oficial. Os utilizadores Entra têm primeiro de iniciar sessão e alterar a palavra-passe para gerar e sincronizar hashes Kerberos/NTLM; a conta de ligação deve pertencer ao grupo de administradores configurado do Entra Domain Services.

Display attribute e Email attribute

O display attribute define como os utilizadores são apresentados na Sophos Firewall. Valores típicos:

• sAMAccountName
• userPrincipalName
• displayName
• name

Estes valores não são universalmente intercambiáveis. O esquema do diretório, a unicidade e o resultado com um utilizador de teste são determinantes. Para Entra Domain Services, a Sophos documenta DisplayName; daí não resulta uma regra geral para AD local.

Os atributos podem ser verificados em Active Directory Users and Computers quando Advanced Features está ativo.

O Email attribute é normalmente mail. É sobretudo relevante quando a firewall deve associar informações relacionadas com email aos utilizadores.

Search base e grupos

A search base define que parte do Active Directory a firewall pesquisa. Para um domínio completo, um exemplo seria:

DC=ad,DC=example,DC=com

Para uma OU individual, o caminho poderia ser, por exemplo:

OU=Users,OU=Company,DC=ad,DC=example,DC=com

O Distinguished Name de uma OU encontra-se em Active Directory Users and Computers, nos atributos da OU.

Uma search base demasiado ampla funciona muitas vezes, mas torna a configuração menos clara. Para ambientes produtivos é melhor:

• OU dedicada ou search base clara para utilizadores relevantes
• grupos AD separados para VPN, portais ou regras de firewall
• nenhuma reutilização aleatória de grandes grupos departamentais
• testar importação de grupos após alterações
• remover regularmente grupos antigos ou vazios

Importações de grupos demasiado amplas podem também sobrecarregar a gestão interna de utilizadores da firewall a longo prazo. Se muitos utilizadores ou grupos antigos forem criados e downloads do VPN Portal falharem inesperadamente mais tarde, ajuda verificar o limite de User-ID da Sophos Firewall.

Importante em Remote Access: em SFOS 21.5 MR1, a Sophos alterou o comportamento para que L2TP e PPTP deixem de ser ativados automaticamente na importação de grupos de Active Directory e Microsoft Entra ID. Isto reduz superfície de ataque involuntária, mas deve ser verificado após upgrades se processos antigos de Remote Access dependiam disso. Configurar L2TP Remote Access na Sophos Firewall explica a atribuição explícita de membros, o limite da Main Group e a validação.

Importar grupos e compreender utilizadores

Depois de adicionar o servidor AD, os grupos AD não ficam automaticamente completos na firewall. Os grupos são importados através do assistente de importação:

Authentication > Servers > Import

O processo é:

1. Selecionar o servidor AD e iniciar Import.
2. Escolher Base DN para a pesquisa de grupos.
3. Selecionar os grupos AD necessários.
4. Verificar group policies comuns.
5. Controlar a seleção e concluir a importação.
6. Em Authentication > Groups, verificar se os grupos existem corretamente.

Utilizadores só aparecem em Authentication > Users quando se autenticam num serviço, por exemplo User Portal, VPN Portal, Captive Portal ou Remote Access VPN. Em cada início de sessão, a firewall verifica novamente que grupos importados correspondem ao utilizador e atualiza a associação.

Se nenhum grupo AD do utilizador existir na firewall, é-lhe aplicado o Default group configurado em Authentication > Services. O valor predefinido do produto é Open group. Ainda assim, confirme o valor efetivo antes da implementação, pois pode ter sido alterado e determina diretamente as definições herdadas.

Em ambientes HA, os grupos AD são importados no dispositivo Primary. Isto também se aplica à limpeza de utilizadores AD antigos com Purge AD users.

O procedimento completo para operar e testar políticas de grupo, Default Group, grupo principal, substituições dos utilizadores e comportamento de vários grupos conforme a função encontra-se em Gerir corretamente grupos de utilizadores e o grupo principal na Sophos Firewall.

Main Group, ordem de grupos e grupos aninhados

Um utilizador AD pode estar em vários grupos. A Sophos Firewall distingue entre:

• Group: o primeiro grupo correspondente na lista de grupos da firewall. É a Main Group do utilizador.
• Other group memberships: outros grupos importados aos quais o utilizador também pertence.
• Group order: ordem em Authentication > Groups. Este valor decide que grupo se torna Main Group quando existem várias correspondências.

Isto é importante porque nem todas as funções avaliam múltiplos grupos. Algumas funções usam apenas a Main Group. Se um utilizador estiver em vários grupos AD, uma policy diferente da esperada pode aplicar-se.

A ordem dos grupos é alterada aqui:

Authentication > Groups > Reorder

Grupos AD aninhados não são suportados. Se uma firewall policy deve aplicar-se a um subgrupo, esse subgrupo tem de ser importado diretamente. Não basta importar apenas o grupo AD superior.

O grupo AD primário de um utilizador também não é tratado como uma associação normal. Isto afeta especialmente o grupo AD padrão Domain Users. Para firewall policies, devem ser usados grupos de segurança explícitos, com utilizadores adicionados diretamente a esses grupos.

Que funções suportam múltiplos grupos

Para a operação, esta distinção é especialmente importante.

Podem ser considerados vários grupos AD em:

• Firewall rules: a ordem das regras da firewall continua a ser decisiva.
• SSL/TLS inspection rules: aplica-se a primeira regra de inspeção correspondente.
• Web policies: primeiro corresponde a regra da firewall e depois a regra Web Policy adequada.
• IPS policies: aplica-se a política da regra correspondente.
• Application control policies: a avaliação é feita através da regra da firewall correspondente.
• SD-WAN routes: os critérios de utilizador ou grupo podem considerar vários grupos.
• Policy test: ajuda a verificar a correspondência de grupos e políticas.
• Remote access SSL VPN: são consideradas as permissões das políticas Full e Split Tunnel correspondentes; Full Tunnel tem prioridade.
• Clientless SSL VPN: combinam-se as permissões dos grupos correspondentes.

Só são considerados a Main Group ou utilizadores explícitos em:

• WAF rules
• Remote access IPsec VPN
• L2TP e PPTP
• Hotspots
• MFA, quando aplicado especificamente a grupos
• Surfing quota, Access time, Network traffic e Traffic shaping
• Quarantine digest, MAC binding e Sign-in restriction

Access Time da Sophos Firewall para utilizadores e grupos mostra como verificar o grupo principal para um acesso de utilizador dependente da hora e delimitar exceções de utilizador.

O mesmo limite de Main Group aplica-se a créditos de tempo e dados baseados no consumo. Surfing Quota e Network Traffic Quota na Sophos Firewall apresenta o procedimento completo.

Exemplo prático: um utilizador pertence a VPN-Users e Firewall-Admins. Para SSL VPN, a associação a vários grupos pode funcionar. Para IPsec Remote Access ou associação MFA por grupo, porém, apenas a Main Group pode contar. Por isso, em Remote Access e acessos administrativos, deve ser testado conscientemente que grupo está definido como Group no objeto do utilizador.

Vários servidores Active Directory

Podem ser configurados vários servidores AD. Em Firewall authentication methods aplica-se uma regra importante: a firewall só passa ao servidor seguinte quando o anterior está inacessível; credenciais recusadas não acionam o failover normal. Esta ordem não é balanceamento de carga nem substitui uma arquitetura AD bem planeada.

Recomendações:

• Definir conscientemente a ordem dos servidores em Authentication > Services.
• Documentar por servidor search base e domain.
• Não usar grupos contraditórios com o mesmo nome em fontes diferentes.
• Em múltiplos UPNs ou domínios, planear DNS e configuração AD separadamente e de forma limpa.
• Testar a redundância não apenas com Test connection, mas com um início de sessão real de utilizador.
• Em caso de falha de um servidor AD, a mensagem para o utilizador pode parecer uma palavra-passe errada.

Se vários UPNs pertencerem à mesma infraestrutura de domínio, registos DNS e configuração de servidor AD têm de corresponder ao respetivo domínio. O importante é que Search Base, Domain Name e resolução do servidor pertençam ao mesmo contexto.

Testar ligação

Após guardar, a ligação deve ser testada diretamente. O teste verifica se a firewall alcança o servidor e se os dados introduzidos estão basicamente corretos.

Um teste bem-sucedido não significa automaticamente que regras de utilizador, SSO ou VPN já funcionem. Depois, pelo menos estes pontos devem ser verificados:

1. Utilizadores ou grupos AD são encontrados corretamente.
2. Utilizador de teste consegue autenticar-se no local previsto.
3. Membership de grupo corresponde à permissão de firewall ou VPN pretendida.
4. Log Viewer mostra eventos de autenticação compreensíveis.
5. Remote Access VPN, User Portal ou Captive Portal funcionam com um utilizador de teste normal.
6. MFA é pedido se estiver previsto para o caso de utilização.
7. O servidor AD está em Authentication > Services no local pretendido dos Firewall Authentication Methods.

Se continuar por esclarecer se falha a seleção do serviço, a identidade do utilizador, a Main Group, a quota ou apenas a regra de firewall posterior, Resolver sistematicamente erros de autenticação na Sophos Firewall separa estas camadas com um caso de teste reproduzível.

Para Remote Access com Sophos Connect, Configurar Sophos Connect Client na Sophos Firewall é o passo seguinte adequado.

Validação por caso de utilização

Depois da ligação AD, não se deve documentar apenas um teste de ligação isolado. Funções diferentes usam a integração AD de formas diferentes. Por isso, deve ser realizado um teste próprio para cada caso de utilização planeado.

• Importação de grupos: procurar um grupo AD relevante e importá-lo na firewall. Em caso de erro, o grupo não é encontrado ou contém utilizadores inesperados.
• User Portal: testar a autenticação com um utilizador AD normal. Um sintoma típico é o início de sessão falhar apesar de o teste do servidor ter sido bem-sucedido.
• Remote Access VPN: verificar início de sessão VPN, permissão de grupo, MFA e acesso a destinos internos. O utilizador pode autenticar-se, mas não receber a política adequada ou acesso.
• Regra de firewall baseada no utilizador: gerar tráfego de teste e verificar utilizador, grupo e Rule ID no Log Viewer. Em caso de erro, o tráfego aparece apenas com o endereço IP ou corresponde a outra regra.
• Captive Portal: testar o início de sessão no navegador e o tráfego subsequente. O início de sessão pode funcionar, mas o utilizador não ser associado corretamente depois.
• AD SSO ou STAS: verificar Live Users e Log Viewer após o início de sessão no Windows. Em caso de problema, o utilizador permanece desconhecido ou é associado ao IP errado.

Esta separação poupa tempo em operação. Um teste LDAP bem-sucedido prova apenas que servidor, porta, bind account e search base estão basicamente acessíveis. Não prova que grupos VPN estejam corretamente associados, que MFA se aplique ou que tráfego de utilizador seja avaliado com identidade em regras de firewall.

Para regras baseadas em utilizador, deve ser sempre gerado tráfego real de teste e verificado no Log Viewer se username, grupo, Firewall Rule ID e ação correspondem ao esperado. Se apenas o endereço IP for visível, a causa está frequentemente em SSO, STAS, Captive Portal ou na ordem das regras de firewall. Para ambientes STAS, Configurar STAS na Sophos Firewall é o artigo de seguimento adequado.

Se o Sophos Endpoint já enviar Security Heartbeat, o Synchronized User ID Authentication pode transmitir um utilizador de domínio Windows 10 à firewall sem um agente de autenticação adicional. O processo continua a exigir a validação AD correspondente e um teste real da regra.

Ter em atenção Active Directory SSO

Active Directory SSO é uma área operacional própria. A ligação ao servidor AD é uma base, mas o SSO também exige condições adequadas no cliente, navegador, DNS, Kerberos ou NTLM.

Para Web Authentication, Sophos Firewall suporta AD SSO clássico com Kerberos e NTLM. Kerberos é mais limpo e rápido, mas exige mais rigor em FQDN, DNS, SPN e confiança do navegador. NTLM é mais tolerante e pode ser o método alternativo pragmático em ambientes antigos, mas não deve tornar-se silenciosamente o único método funcional.

A Sophos coloca o NTLM iniciado pelo navegador atrás de General Authentication Client, Clientless single sign-on e Client-based single sign-on. O NTLM só é usado como alternativa quando essas atribuições não se aplicam; se o NTLM também falhar, é apresentado Captive Portal. Se um utilizador surgir com um método inesperado em Current activities > Live users, verificam-se primeiro o Client type apresentado e as fontes de identidade já ativas antes de alterar o SPN ou Web Authentication.

A definição Kerberos & NTLM oferece ambos os métodos ao navegador, e o cliente decide qual utiliza. Não existe um modo apenas Kerberos, porque a especificação HTTP não o suporta. Para tráfego web transparente, a firewall redireciona a autenticação para a porta TCP 8091.

Quando vários utilizadores partilham o mesmo IP de RDS ou de servidor de terminais, o mapeamento normal por IP não é suficiente. Para tráfego HTTP e HTTPS conduzido exclusivamente por um proxy explícito, Per-Connection AD SSO para hosts multiutilizador explica o procedimento próprio e a distinção em relação ao SATC.

⚠️ Nota de atualização para o SFOS 22: Após um upgrade do SFOS 21.5 ou anterior para o SFOS 22.0 GA, o AD SSO com Kerberos e NTLM pode deixar de funcionar. As regras baseadas em utilizadores deixam então de reconhecer os utilizadores de domínio afetados, enquanto o restante tráfego da firewall continua. A Sophos corrigiu o erro no SFOS 22.0 MR1 Build 490. O AD SSO deve ser testado com um utilizador de domínio real e tráfego efetivo antes e imediatamente após o upgrade. Reparar o AD SSO após o upgrade para SFOS 22 descreve a verificação em nasm.log, o cleanup NASM direcionado e a validação posterior com tráfego real de utilizador.

O fluxo de AD SSO é, por isso, mais do que apenas Test connection no servidor AD:

1. Em Administration > Admin and user settings, definir um hostname ou FQDN. Para Kerberos deve ser um FQDN, em minúsculas, com a parte de host no máximo com 15 caracteres, para que NetBIOS name, objeto de computador AD e SPN não se afastem.

   Exemplo: a firewall está configurada como fw01.edge.example.com, enquanto o domínio AD se chama corp.example.com. Ao aderir ao domínio, o SFOS usa o hostname NetBIOS fw01 com o domínio AD. O nome conhecido pelo AD é, portanto, fw01.corp.example.com, e não automaticamente o FQDN configurado na firewall. O nome de redirecionamento para Kerberos transparente tem de corresponder ao HTTP-SPN registado no AD e ser resolvido por DNS.

2. Em Administration > Admin and user settings, definir a Redirection Location para que os clientes consigam resolver o nome e confiar no destino. Em cenários Kerberos transparentes, esse nome tem de corresponder ao SPN. Uma conta com acesso de leitura ao AD pode executar a seguinte consulta dirigida e apenas de leitura num sistema Windows:

   setspn -Q HTTP/fw01.corp.example.com
   

   Substitua o valor de exemplo pelo seu FQDN de redirecionamento. O resultado tem de mostrar exatamente o SPN e o objeto de computador esperados; nenhum resultado ou uma correspondência noutro objeto deve ser esclarecido com o responsável pelo AD antes da implementação.

3. Guardar o servidor AD em Authentication > Servers e executar Test connection. Este teste verifica conectividade e credenciais, mas ainda não prova que AD SSO funciona.

4. Em Authentication > Services, colocar o servidor AD na posição desejada em Firewall authentication methods. AD SSO usa os servidores por esta ordem e só passa para o seguinte se o anterior não estiver acessível.

5. Em Administration > Device access, ativar AD SSO para as zonas necessárias. Normalmente é LAN ou uma rede interna de clientes claramente definida, não todas as zonas.

6. Em Authentication > Web authentication, definir If Active Directory (AD) SSO is configured como Kerberos & NTLM ou conscientemente como NTLM only.

7. Nas regras de firewall adequadas, verificar se Match known users e, para pedidos web desconhecidos, Use web authentication for unknown users correspondem ao fluxo desejado. Uma regra separada e claramente nomeada para HTTP e HTTPS é muitas vezes mais simples de operar.

Em Authentication > Services, HTTP challenge redirect on intranet zone deve permanecer ativado. Se um website alojado na Internet iniciar um desafio NTLM, a firewall trata assim a troca através do IP da interface local na zona de intranet. Se a opção for desativada, o navegador pode enviar credenciais através da Internet. Não é uma definição de compatibilidade inofensiva.

Quando Use web authentication for unknown users autentica tráfego HTTPS em modo transparente, a firewall decifra a ligação para a autenticação independentemente das definições da regra de firewall ou da regra de SSL/TLS Inspection. Isto tem de estar alinhado com o desenho de TLS Inspection e certificados; caso contrário, AD SSO parece rapidamente um problema de navegador, certificado ou webfilter.

Para validação, Log Viewer é decisivo. Em Log viewer > Authentication, no arranque da ligação AD SSO devem aparecer mensagens como Kerberos authentication initialized successfully e NTLM authentication channel established successfully. Mensagens como Cannot initialize Kerberos authentication ou Cannot establish NTLM authentication channel são problemáticas. A coluna Log Comp mostra ainda se um cliente usa Kerberos ou NTLM.

Sophos Firewall só oferece um dos dois métodos ao navegador depois de Kerberos e NTLM terem sido inicializados com êxito na firewall. Por isso, uma alternativa visível para NTLM não é motivo para ignorar a verificação de Kerberos. DNS, SPN e hora do sistema devem estar alinhados; por predefinição, os relógios envolvidos em Kerberos não podem diferir mais de cinco minutos.

As funções das contas devem ser separadas. A conta de bind LDAP só precisa dos direitos de leitura necessários para as consultas ao diretório. A operação de domain join para AD SSO exige uma conta Domain Admin ou uma conta com direitos delegados para criar o objeto de computador ou SPN. Em ambientes HA, com vários servidores AD ou após uma atualização, pode ser necessário um novo domain join; por isso, devem estar disponíveis credenciais adequadas para essa operação, sem atribuir esses privilégios elevados à conta de bind LDAP.

Desde SFOS 21.5 MR1, Windows Server 2025 é suportado em Active Directory SSO com NTLM e Kerberos. SFOS 22 traz também componentes Samba atualizados e remove métodos de cifragem antigos. Para administradores, isto significa:

• Testar AD SSO especificamente após upgrades de Domain Controller.
• Verificar autenticação e associação de utilizadores após upgrades SFOS.
• Documentar dependências Kerberos/NTLM em ambientes antigos.
• Não planear cifragem obsoleta como solução permanente.
• Verificar DNS request routes para domínios AD se a firewall não encontrar service records AD pelo resolver normal.
• Não confundir SSO com Entra ID SSO para Sophos Connect.

Se Entra ID SSO estiver planeado para VPN ou VPN Portal, deve ser usado o artigo separado Configurar Microsoft Entra ID SSO para Sophos Connect e VPN Portal. Este é um modelo de autenticação diferente da ligação AD local clássica.

Troubleshooting

Teste de ligação falha

Primeiro verificar alcance, porta, routing e DNS. Depois controlar segurança da ligação, certificado, conta de serviço e palavra-passe.

Checks práticos:

• A firewall consegue alcançar o Domain Controller por IP?
• O nome DNS é resolvido corretamente?
• A porta 389 ou 636 está acessível?
• SSL/TLS corresponde realmente à porta e ao certificado?
• A conta de serviço está ativa e não bloqueada?
• Existem regras de Windows Firewall ou requisitos LDAP Signing no lado Windows?

Utilizador não é encontrado

Então, frequentemente, a search base está errada ou demasiado restrita. Verificar o distinguishedName da OU e garantir que o utilizador está realmente dentro da search base. Também a ortografia, acentos, caracteres especiais e o display attribute escolhido podem dificultar a pesquisa.

Grupo é importado, mas acesso não funciona

Então deve ser verificada a cadeia de permissões: grupo AD, grupo importado da firewall, regra atribuída de VPN/portal/firewall, MFA e posição da regra. Em Remote Access, a configuração VPN adequada também tem de estar associada ao grupo.

Se o utilizador estiver em vários grupos AD, verificar adicionalmente a Main Group em Authentication > Users. Especialmente MFA, Remote access IPsec VPN, WAF, Hotspots e várias definições por utilizador consideram apenas a Main Group.

Novos utilizadores AD não conseguem iniciar sessão no VPN Portal

Se um utilizador AD existente consegue usar o VPN Portal, mas um utilizador recém-criado com permissões comparáveis não consegue, deve primeiro comparar-se a atribuição de grupos, o método de Remote Access e a versão de firmware. Em Authentication > Users, Group mostra a Main Group; os restantes grupos importados aparecem em Other group memberships. SSL VPN pode considerar várias memberships de grupo, enquanto IPsec Remote Access considera apenas a Main Group ou um utilizador selecionado explicitamente.

Para o diagnóstico:

1. Comparar o novo utilizador afetado com um utilizador existente que funciona.
2. Verificar a Main Group e Other group memberships.
3. Verificar os VPN portal authentication methods em Authentication > Services, a zona de origem permitida em Administration > Device access e o utilizador ou grupo na política de Remote Access.
4. Registar a versão e a build do SFOS.

Com NC-180824, a Sophos corrigiu um erro que impedia novos utilizadores AD de uma Secondary AD Group de iniciar sessão no VPN Portal. A correção está incluída no SFOS 22.0 MR2 Build 546 de 14 de julho de 2026. A Sophos não indica a versão em que o erro foi introduzido nem um workaround oficial. Se a configuração e a lógica dos grupos estiverem corretas, deve-se, por isso, atualizar uma instalação mais antiga afetada para SFOS 22.0 MR2 ou posterior e depois testar com um utilizador AD que inicia sessão na firewall pela primeira vez e cuja autorização VPN é concedida exclusivamente através da Secondary Group afetada numa política SSL-VPN.

⚠️ Não alterar a ordem dos grupos por tentativa, não limpar utilizadores prematuramente com Purge AD users nem recriar grupos. A Sophos não documenta estas medidas como solução para NC-180824, e elas podem alterar outras permissões.

Novo grupo AD não aparece automaticamente

Grupos AD recém-criados não são sincronizados automaticamente para a firewall. O grupo tem de ser importado novamente através do assistente de importação ou criado manualmente como grupo correspondente. Depois, um utilizador de teste deve iniciar sessão novamente para que a firewall reavalie as memberships de grupo.

Utilizador foi eliminado no AD, mas continua visível na firewall

Utilizadores AD que já iniciaram sessão podem permanecer visíveis na firewall. Se utilizadores foram eliminados no AD, devem primeiro ser removidos no AD e depois deve ser usado Purge AD users na firewall. Em ambientes HA, isto é feito no dispositivo Primary.

Login funciona, mas a regra de utilizador não se aplica

Então, normalmente, LDAP em si não é o problema, mas a associação de utilizador, SSO, posição da regra ou logging. No Log Viewer deve ser visível se o tráfego é avaliado com identidade de utilizador ou apenas com endereço IP. Para análise de regras, consulte Testar regra de firewall com Log Viewer, Policy Test e Packet Capture.

AD SSO cai para Captive Portal ou NTLM

Se AD SSO não funcionar de forma transparente, normalmente estão envolvidos Redirection URL, SPN, resolução DNS ou confiança do navegador. Para Kerberos, o nome para o qual a firewall redireciona tem de pertencer ao HTTP SPN correspondente e ser resolvido pelo cliente. Para NTLM, o navegador deve tratar o nome de destino como confiável; caso contrário, pede credenciais ou cai para Captive Portal.

Na prática, verificar primeiro Administration > Admin and user settings, a resolução DNS do nome de redirecionamento, setspn -Q HTTP/fw01.corp.example.com num cliente Windows e Log viewer > Authentication. Se aparecer apenas NTLM em vez de Kerberos, isso indica muitas vezes um problema de SPN ou confiança do navegador, não necessariamente uma ligação AD server avariada.

O certificado selecionado em Admin console and end-user interaction > Certificate tem de abranger o hostname ou FQDN de redirecionamento e ser considerado fidedigno pelos endpoints. O certificado autoassinado pré-instalado da firewall normalmente não cumpre nenhum destes requisitos para um nome recém-configurado. Um aviso de certificado não deve ser ignorado, mas resolvido com um certificado público ou interno correspondente.

Para NTLM, a confiança pode ser limitada ao nome de redirecionamento interno. No Windows, Microsoft Edge e Google Chrome herdam a definição de Internet Options > Security > Local intranet > Sites > Advanced. No Firefox, adicionar o mesmo FQDN a network.automatic-ntlm-auth.trusted-uris em about:config. Autorizar apenas o nome interno efetivamente utilizado, não um domínio amplo ou websites arbitrários.

Após uma atualização, alguns inícios de sessão deixam de funcionar

Após upgrades SFOS ou Domain Controller, deve prestar-se especial atenção a SSO, Kerberos/NTLM, métodos antigos de cifragem, certificados e importação de grupos. Se apenas certos utilizadores forem afetados, verificar também caracteres especiais, espaços, UPN, memberships de grupo e estado da palavra-passe.

Para authentication e service logs, consulte Sophos Firewall Troubleshooting: serviços e logs.

Ligação não funciona com validação de certificado ativa

Quando Validate server certificate está ativo, certificado, CNAME, resolução DNS e confiança na CA têm de corresponder. Causas frequentes são um certificado com outro nome, uma CA interna em falta na firewall ou um CNAME que a firewall não consegue resolver.

Reverter a alteração e continuar a operar em segurança

Antes das alterações, documente a ordem dos servidores, os serviços utilizados, os grupos e as definições de certificados. Se a validação falhar, reponha primeiro a ordem anterior, o método de ligação cifrado original e a porta. Plaintext na porta 389 destina-se exclusivamente a um diagnóstico breve e nunca deve permanecer como reversão de produção.

Se for necessário reverter toda a configuração, restaure a cópia previamente descarregada em Backup and firmware > Backup and restore. Isto substitui a configuração atual, elimina alterações posteriores e reinicia a firewall, pelo que a operação deve ocorrer numa janela de manutenção. Uma reversão de firmware arranca a partição anterior com a respetiva configuração e também termina sessões. A reversão automática de firmware só atua quando a migração da configuração falha, não quando uma falha de AD SSO apenas se torna visível durante a operação.

Depois de qualquer reversão, volte a verificar Test connection, um início de sessão normal no serviço, o efeito dos grupos e, para SSO, um acesso real de utilizador com Log viewer > Authentication. Em HA, importe grupos e execute Purge AD users no dispositivo Primary. Teste a falha do Domain Controller secundário previsto apenas numa janela de manutenção aprovada, confirmando que o primeiro servidor está realmente inacessível e que o início de sessão através do segundo funciona.

Checklist operacional

Antes da configuração:

• Domain Controller, porta e nome DNS definidos.
• LDAPS e cadeia de certificados verificados.
• Conta de serviço dedicada criada.
• Search base e grupos relevantes definidos.
• Desenho de MFA e Remote Access esclarecido.

Depois da configuração:

• Teste de ligação bem-sucedido.
• Servidor AD definido como Authentication Method primário ou adequado.
• Utilizador de teste e grupo de teste verificados.
• Grupos AD importados através do assistente de importação.
• Main Group de um utilizador de teste controlada.
• Com vários grupos: início de sessão no VPN Portal testado com um utilizador existente e um utilizador que inicia sessão na firewall pela primeira vez, cuja permissão é concedida exclusivamente através de uma Secondary Group numa política SSL-VPN.
• Remote Access, Portal ou regra de utilizador testados com utilizador normal.
• Log Viewer mostra eventos de autenticação esperados.
• Em AD SSO, as mensagens Kerberos/NTLM foram verificadas no Authentication log.
• Expiração da palavra-passe da conta de serviço documentada.
• Teste de upgrade para AD SSO, importação de grupos e processos VPN planeado.

Em operação:

• Remover grupos que já não são necessários.
• Importar ativamente novos grupos AD, não esperar sincronização automática.
• Verificar regularmente a conta de serviço.
• Renovar certificados LDAPS antes de expirarem.
• Controlar ordem dos grupos após alterações AD.
• Usar Named Admins e MFA para acessos administrativos.
• Não tratar erros de autenticação apenas como problema de utilizador; verificar também AD, rede, certificados e regras de firewall.

FAQ