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.

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.

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:

⚠️ 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.

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. A CA emissora do certificado do Domain Controller é conhecida na firewall em Certificates > Certificates.
2. O valor em Server IP/domain corresponde ao nome do certificado ou a um Subject Alternative Name do certificado.
3. Se for usado um CNAME, a firewall consegue resolver internamente esse nome.
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 example.local ou 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 password

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
• owner documentado para alterações de password
• password longa e única
• sem login interativo, se as políticas AD o permitirem corretamente
• monitoring ou lembrete antes da expiração da password

Se a password 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. Para isso, o Domain Controller precisa de um certificado adequado e a firewall tem de confiar na CA emissora.

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.
• A CA emissora é conhecida na firewall, se a validação for necessária.
• Hora e data em firewall e Domain Controller estão corretas.

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.

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

sAMAccountName é frequentemente robusto e curto em ambientes AD clássicos. userPrincipalName está mais próximo de nomes de login modernos e identidades cloud. displayName é fácil de ler para humanos, mas nem sempre suficientemente inequívoco para operação e troubleshooting.

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=example,DC=local

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

OU=Users,OU=Company,DC=example,DC=local

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.

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 login, a firewall verifica novamente que grupos importados correspondem ao utilizador e atualiza a associação.

Se um utilizador não for encontrado em nenhum grupo AD importado, fica na Default Group. Esta Default Group é visível em Authentication > Services nos Firewall Authentication Methods. Por predefinição, é frequentemente a Open group.

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.

Main Group, ordem de grupos e grupos aninhados

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

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 é assumido como uma membership 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 tabela é especialmente importante:

Exemplo prático: Um utilizador está em VPN-Users e Firewall-Admins. Para SSL VPN, a membership múltipla 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. A firewall valida utilizadores na ordem configurada no WebAdmin. Isto não substitui um desenho AD limpo.

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 failover não apenas com Test connection, mas com um login real de utilizador.
• Em caso de falha de um servidor AD, a mensagem para o utilizador pode parecer uma password 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.

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.

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.

Ter em atenção Active Directory SSO

Active Directory SSO é uma área operacional própria. A ligação pura ao servidor AD é uma base para isso, mas SSO precisa adicionalmente de condições adequadas em cliente, browser, 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 browser. NTLM é mais tolerante e pode ser o fallback pragmático em ambientes antigos, mas não deve tornar-se silenciosamente o único método funcional.

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.
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. Num cliente Windows, setspn -Q HTTP/* ajuda a verificar os HTTP SPNs existentes.
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.

Se Use web authentication for unknown users tiver de autenticar tráfego HTTPS em modo transparente, a firewall pode decifrar a ligação para o processo de autenticação. Isto tem de estar alinhado com o desenho de TLS Inspection e certificados; caso contrário, AD SSO parece rapidamente um problema de browser, 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.

A questão da conta é importante. Para consultas LDAP normais, muitas vezes basta um Domain User com direitos de leitura. Para AD SSO, porém, a firewall tem de entrar no domínio e conseguir criar um objeto de computador ou SPN. É preciso uma conta Domain Admin ou uma conta com direitos de domain join corretamente delegados. Em ambientes HA, com vários servidores AD ou após upgrades, a firewall pode ter de voltar a entrar no domínio. Por isso, não se deve fazer o join uma vez com Domain Admin e depois mudar para uma conta mais fraca se essa conta não puder realizar o rejoin mais tarde.

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

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.

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 browser. 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 browser 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/* 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 browser, não necessariamente uma ligação AD server avariada.

Após um upgrade, alguns logins 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 password.

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.

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