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. STARTTLS cifra a ligação após a mudança de protocolo; o aviso contra o uso permanente de LDAP não cifrado não se aplica de forma geral a STARTTLS.
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. Plaintext 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.

Automatização AD na passagem do SFOS 22 para o SFOS 23: A documentação da API para adicionar e editar um servidor AD usa no SFOS 23 designações mais restritas nas tabelas do que no SFOS 22: ServerIpDomain/ServerAddress passa a ServerAddress, ServerName/NetBIOSDomain a NetBIOSDomain e ADSUsername/Administrator/Username a ADSUsername/Administrator. Em contrapartida, o exemplo XML continua a usar, sem alterações em ambas as versões, os elementos ServerAddress, NetBIOSDomain e ADSUsername. Isto comprova uma alteração das designações na documentação, não a rejeição de aliases antigos pela firewall nem uma mudança de nome dos campos WebAdmin explicados acima. O exemplo, que apresenta inconsistências internas, não é um modelo de API verificado e diretamente executável.

As designações da segurança da ligação também continuam a ser distintas: Plaintext é a designação no WebAdmin; a documentação da API indica os valores Simple, SSL e StartTLS para ConnectionSecurity. As designações da GUI não são usadas como valores da API sem verificação prévia.

Entre o SFOS 22 e o SFOS 23, também diferem as tabelas de estados/mensagens documentadas para Add e Edit. Estas tabelas, por si só, não garantem os códigos de resposta efetivos, os textos das mensagens devolvidas, os estados de transporte HTTP nem a segurança de novas tentativas. Na migração da automatização AD, a interpretação das respostas deve, por isso, ser verificada com base na documentação da API da versão utilizada e em respostas efetivamente capturadas, em vez de manter inalteradas as correspondências antigas de erros. Em seguida, devem ser verificadas a configuração AD guardada e a autenticação de um utilizador de teste normal no serviço previsto.

Retirar de serviço o servidor AD antigo em segurança: A operação de API documentada Delete Active Directory server identifica a entrada do servidor de autenticação guardada na firewall pelo seu ServerName exato, não pelo endereço IP do Domain Controller nem por um utilizador AD. Em contrapartida, Purge AD users limpa entradas de utilizadores AD na firewall e não substitui a remoção de um servidor. O facto de a tabela de Delete indicar ServerName como opcional não comprova que seja seguro eliminar sem especificar um alvo nem que exista uma eliminação em massa. Por isso, se o alvo estiver em falta ou não for inequívoco, não se gera nem se executa qualquer pedido de eliminação; a documentação não fornece uma estrutura completa de pedido verificada e executável nem esclarece o comportamento quando o alvo é omitido. Como precaução operacional conservadora, antes de uma retirada de serviço autorizada, documentam-se o nome exato do objeto e as respetivas definições, garantem-se um acesso funcional de administrador local e uma cópia de segurança da configuração, e verificam-se os serviços afetados e a ordem prevista dos servidores em Authentication > Services. Primeiro, validar o método de início de sessão de substituição com um utilizador normal e as respetivas permissões de grupo; não confiar num fallback automático quando as credenciais são recusadas. Depois, voltar a consultar a lista de servidores guardada e verificar o início de sessão e a autorização por grupos em cada serviço afetado. Se a resposta não for clara, esclarecer primeiro o estado efetivo, em vez de repetir a eliminação às cegas. A tabela de Delete continua a indicar 200 e 500 no SFOS 22 e 23, mas os identificadores de mensagens JavaScript mudam entre versões. Estes valores documentados não são estados HTTP nem comprovam o efeito da operação; as referências JavaScript não resolvidas não permitem deduzir os textos das mensagens devolvidas nem as características do comportamento em execução. Esclarecer o procedimento de eliminação e recuperação antes de alterar o servidor de autenticação.

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.

Preparar domínio gerido e certificado

Antes de alterar produção, confirmar com o responsável Azure tenant, nome DNS gerido, VNet/caminho privado, grupo administrador, âmbito de sincronização e permissões. Usar endpoint Windows, macOS ou Linux protegido com OpenSSL; este exemplo shell é Linux/macOS, não a consola SFOS. Guardar certificado, LDAP, NSG e ordem de serviços atuais; manter administrador local testado disponível.

⚠️ Exemplo mínimo histórico, não é um certificado pronto para carregamento: A sequência de comandos conservada abaixo explica a CA, a chave/CSR LDAP, serverAuth e PKCS#12. Define apenas a Extended Key Usage, mas não a Key Usage exigida nem um nome DNS com wildcard. O seu resultado não pode ser carregado diretamente no passo Azure seguinte. Primeiro, obter um certificado adequado da PKI aprovada ou planear um cenário de teste autoassinado expressamente autorizado e verificar todos os critérios seguintes. Um exemplo autoassinado não constitui uma aprovação para produção.

Para Secure LDAP, o certificado tem de apresentar as seguintes propriedades:

• Nome de domínio: wildcard para o domínio DNS gerido real no Subject ou no DNS Subject Alternative Name (SAN), por exemplo *.ad.example.com para ad.example.com. Substituir o nome de domínio de exemplo completo; um único hostname LDAP não é suficiente, porque a Microsoft opera os controladores de domínio geridos com nomes variáveis. Para a validação posterior na firewall, o nome do endpoint utilizado também tem de corresponder ao certificado.
• Key Usage: digitalSignature e keyEncipherment; adicionalmente, a Extended Key Usage serverAuth para Server Authentication. A EKU, por si só, não substitui estes dois requisitos de Key Usage.
• Validade e confiança: o certificado tem de estar já válido e abranger, pelo menos, os próximos 3 a 6 meses. Planear a renovação atempadamente. Os sistemas que acedem ao serviço têm de confiar no emissor e na cadeia necessária; no caso de uma CA própria ou de um certificado de teste autoassinado, distribuir de forma controlada os certificados públicos de confiança, nunca a chave privada do servidor ou da CA.
• Pacote para carregamento: .pfx protegida por palavra-passe, com a chave privada LDAP correspondente ao certificado de servidor e os certificados públicos necessários da cadeia, mas sem a chave privada da CA. O formato de exportação PFX também tem de cumprir os requisitos de importação descritos abaixo.

Para o exemplo histórico, trabalhar num diretório novo, acessível apenas ao proprietário, não substituir ficheiros e definir umask 077. Criar entra-eku.conf num editor de texto:

[client_server_ssl]
extendedKeyUsage = serverAuth

Executar os comandos seguintes nesse diretório apenas para compreender o exemplo mínimo histórico; responder aos pedidos de informação do certificado de acordo com o plano de nomes aprovado, sem copiar identidades de clientes de exemplo. Mesmo com respostas corretas, esta sequência de comandos não acrescenta automaticamente as extensões de certificado em falta:

umask 077
openssl genrsa -out entra-ca.key 4096
openssl req -x509 -new -key entra-ca.key -days 365 -out entra-ca.pem
openssl genrsa -out entra-ldap.key 4096
openssl req -new -key entra-ldap.key -out entra-ldap.csr
openssl x509 -req -extensions client_server_ssl -extfile entra-eku.conf -in entra-ldap.csr -CA entra-ca.pem -CAkey entra-ca.key -CAcreateserial -out entra-ldap.crt -days 365
openssl pkcs12 -export -out entra-ldap.pfx -inkey entra-ldap.key -in entra-ldap.crt -certfile entra-ca.pem
openssl x509 -in entra-ldap.crt -noout -text
openssl pkcs12 -in entra-ldap.pfx -info -noout

Introduzir uma palavra-passe de exportação única de forma interativa e guardá-la no repositório de segredos aprovado, nunca num comando, ticket ou registo. A .pfx contém a chave privada LDAP, não a chave privada da CA. As chaves geradas acima ficam armazenadas sem cifragem no suporte de armazenamento de trabalho; umask 077 limita as permissões dos ficheiros, mas não substitui a cifragem. Utilizar um suporte de armazenamento protegido e cifrado, proteger as chaves e o pacote, transferir de forma segura apenas o pacote aprovado e eliminar as cópias de trabalho de acordo com a política de chaves. Os últimos dois comandos são verificações sem apresentação de chaves privadas, não uma autorização para carregamento.

Verificar as propriedades do certificado antes da exportação

Verificar o certificado de servidor efetivamente previsto com openssl x509 -in entra-ldap.crt -noout -text; para tal, substituir o nome do ficheiro pelo certificado aprovado pela PKI, em vez de utilizar o resultado do exemplo mínimo sem verificação. No resultado, o nome de domínio gerido com wildcard, Digital Signature, Key Encipherment, TLS Web Server Authentication, o emissor e Not Before e Not After têm de corresponder aos requisitos. Solicitar também a verificação da cadeia de confiança associada e da correspondência com a chave privada prevista. Esta apresentação textual, por si só, não comprova a confiança na cadeia no endpoint da firewall nem uma aceitação bem-sucedida pelo Azure. Se faltar alguma propriedade ou a cadeia de confiança continuar por esclarecer, parar e obter um certificado adequado junto do responsável pela PKI/Azure; não carregar o exemplo mínimo.

Exportar o PFX num formato compatível e protegido

O comando openssl pkcs12 -export conservado acima não seleciona explicitamente um formato de exportação compatível. O OpenSSL 3 utiliza por predefinição AES-256-CBC/PBKDF2 e um MAC SHA256; a Microsoft exige TripleDES-SHA1 para esta importação no Entra. Por isso, o resultado histórico entra-ldap.pfx não é um pacote aprovado para carregamento. Mudar o nome do pacote ou utilizar uma palavra-passe correta não resolve este conflito de formatos. A codificação de compatibilidade diz respeito exclusivamente ao contentor PFX; não é uma recomendação para utilizar algoritmos fracos de TLS, de assinatura de certificados ou de chaves.

Uma via alternativa documentada é a exportação de certificados do Windows num sistema Windows protegido que disponibilize TripleDES-SHA1; no Windows Server, esta opção está disponível a partir do Windows Server 2016. O certificado de servidor já sujeito à verificação técnica tem de estar aí presente no arquivo pessoal de certificados, juntamente com a respetiva chave privada correspondente e exportável. Não importar chaves privadas apenas para distribuir confiança aos clientes.

1. Como administrador autorizado, abrir mmc e selecionar File > Add/Remove Snap-in > Certificates > Computer account > Local computer. Em Certificates (Local Computer) > Personal > Certificates, identificar o certificado aprovado pelo nome e pela impressão digital, não selecionar um certificado arbitrário com o mesmo nome.
2. Selecionar All Tasks > Export, depois Yes, export the private key e Personal Information Exchange - PKCS #12 (.PFX). Ativar Include all certificates in the certification path if possible. Os certificados CA são componentes públicos da cadeia; a chave privada da CA não é exportada.
3. Na página de segurança, selecionar Password, definir TripleDES-SHA1 como cifragem e introduzir e confirmar uma palavra-passe única na caixa de diálogo. Guardar num local protegido com um nome novo, por exemplo entra-ldap-upload.pfx; não substituir o ficheiro do exemplo histórico. Se a opção não estiver disponível ou a chave privada não for exportável, parar e solicitar uma exportação compatível ao responsável pela PKI, em vez de continuar com os valores predefinidos.
4. Verificar o pacote concluído num sistema protegido com openssl pkcs12 -in entra-ldap-upload.pfx -info -noout; introduzir a palavra-passe apenas de forma interativa. Esperam-se um MAC SHA1 e TripleDES/3DES para os componentes cifrados de chaves e certificados, normalmente apresentados pelo OpenSSL como pbeWithSHA1And3-KeyTripleDES-CBC. AES/PBKDF2 ou um MAC SHA256 não correspondem a este perfil de exportação. Se a versão instalada do OpenSSL ou a política de providers impedir a verificação, não desativar indiscriminadamente os mecanismos de proteção; solicitar ao responsável pela PKI que verifique o pacote com uma ferramenta de verificação aprovada. -noout impede a apresentação de certificados e chaves privadas; palavras-passe, ficheiros PFX e chaves privadas não devem constar dos registos de verificação.

Só depois de os critérios do certificado, a chave privada correspondente, a cadeia, o perfil de exportação e a transferência segura terem sido verificados e documentados poderá a entra-ldap-upload.pfx aprovada ser utilizada no passo seguinte. Validar a ligação e a autenticação no ambiente de destino antes da implementação.

Configurar Secure LDAP e descobrir o endpoint

1. O responsável Azure provisiona o domínio com DNS/VNet/admin acordados; aguardar Microsoft Entra Domain Services > Running. Em Synchronization, escolher conscientemente All ou Scoped, Save synchronization scope. Incluir utilizadores previstos e concluir sincronização de hashes descrita acima.
2. Só após a conclusão bem-sucedida da verificação do certificado e do PFX, abrir Secure LDAP do domínio, ativar e carregar exclusivamente o pacote aprovado para carregamento, não o ficheiro do exemplo histórico, em .PFX file with secure LDAP certificate. Introduzir a palavra-passe de exportação em Password to decrypt .PFX file e selecionar Save. O exemplo público de referência também ativa Allow secure LDAP access over the internet; para um caminho privado, isto não é obrigatório. Ativar apenas para acesso público expressamente autorizado, com a NSG a permitir TCP 636 exclusivamente a partir do endereço IP público de origem real da firewall.
3. Em Properties, registar IP addresses, Secure LDAP external IP addresses, Admin group. Em Microsoft Entra ID > Users, verificar pertença da conta bind ao grupo. Para routing privado verificar endpoint gerido, DNS e caminho de origem; IP do tenant não substitui controlador de domínio.

Mapear servidor e validar serviços

Em Authentication > Servers > Add: Server type: Active Directory, Server name único, Server IP/domain do endpoint LDAP escolhido, Connection security: SSL/TLS, Port: 636, NetBIOS domain gerido. ADS user name é o membro Admin group verificado; introduzir palavra-passe com segurança. Display name attribute: DisplayName, Email address attribute: mail, Domain name DNS gerido e Search queries como DN LDAP apenas dos objetos sincronizados necessários. Mantém-se a qualificação anterior: desativar Validate server certificate é o exemplo fonte, não o padrão de hardening de produção Avanet.

Test connection, depois Save. Importar grupos necessários em Authentication > Servers > Import, verificar Authentication > Groups, selecionar servidor para serviços suportados previstos em Authentication > Services, sem alterar silenciosamente outras ordens. Testar login e autorização de grupos de utilizador sincronizado normal por serviço. Perante falha, verificar Running, sincronização/hashes, endpoint/rota, NSG TCP 636, palavra-passe/validade/EKU PFX, grupo bind e DN. Não abrir LDAP amplamente nem desativar validação permanentemente. Se a aceitação falhar, restaurar certificado/LDAP/NSG/serviços registados na manutenção e testar caminho anterior; não eliminar domínio. Definir responsável de renovação e reversão.

Display attribute e Email attribute

O display attribute define como os utilizadores são apresentados na Sophos Firewall. Os seguintes atributos podem existir no diretório do seu ambiente e devem ser verificados antes da utilização:

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

Se o AD deve ser o método de autenticação principal deste procedimento, ir a Authentication > Services, selecionar o servidor AD configurado em Firewall authentication methods, movê-lo para a primeira posição da lista de servidores selecionados e clicar em Apply. Depois, verificar os grupos importados em Authentication > Groups e pedir a um utilizador de teste que volte a iniciar sessão para atualizar a associação aos grupos. Esta primeira posição aplica-se ao procedimento com AD como método principal, não a todas as ordens de servidores existentes.

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.

Para vários domínios UPN no mesmo servidor de domínio, a Sophos descreve esta configuração específica: criar uma entrada DNS para cada domínio que aponte para o endereço IP desse servidor e uma configuração de servidor AD separada na firewall para cada domínio. Usar o respetivo domínio AD como Search query em formato DN LDAP, por exemplo DC=ad,DC=example,DC=com para ad.example.com. Substituir os valores pelos domínios do ambiente e testar o início de sessão e a associação aos grupos para cada domínio UPN. Não é um procedimento de balanceamento de carga nem de failover entre vários Domain Controllers; com LDAPS, o nome de servidor utilizado tem de continuar a corresponder à validação do certificado.

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. Verificar se o grupo é encontrado e se um utilizador de teste definido aparece como membro.
• 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:

A Sophos descreve o registo da firewall no domínio Windows como a criação de um objeto para a firewall no Domain Controller primário. Este contexto pertence ao domain join para AD SSO; as consultas LDAP/LDAPS ao diretório, por si só, não exigem automaticamente esse join. Os direitos necessários para o join permanecem separados dos direitos de leitura da conta de bind LDAP.

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 ambos os 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