Ligar um servidor LDAP genérico ao Sophos Firewall

Active Directory é o servidor de autenticação mais comum no Sophos Firewall, mas não o único. Quem utiliza OpenLDAP, 389 Directory Server, FreeIPA, Google Secure LDAP ou outro diretório LDAP puro pode ligar o Sophos Firewall da mesma forma como cliente LDAP. O tipo de servidor chama-se propositadamente LDAP server, e não Active Directory, mesmo que o Active Directory seja tecnicamente também um diretório LDAP.

Este artigo aborda especificamente o caso genérico: um serviço de diretório sem os campos específicos do AD, como nomes de domínio ou Kerberos. Para ambientes Active Directory com LDAPS, importação de grupos e AD SSO, é mais adequado ligar Active Directory ao Sophos Firewall. Para autenticação baseada em RADIUS, por exemplo via Microsoft NPS ou um gateway MFA, o artigo indicado é configurar servidor RADIUS no Sophos Firewall.

Quando um servidor LDAP genérico é adequado

Um servidor LDAP no Sophos Firewall faz sentido quando:

• os utilizadores e grupos estão num diretório que não é Active Directory, por exemplo OpenLDAP, 389 Directory Server ou FreeIPA.
• um diretório baseado em cloud oferece uma interface LDAP, por exemplo Google Secure LDAP ou um proxy LDAP à frente do Entra ID ou do Okta.
• vários sistemas já se autenticam contra o mesmo diretório LDAP e o firewall deve usar a mesma fonte.
• não é necessário Kerberos nem NTLM, bastando uma simples autenticação por bind.

Se, em vez disso, for utilizado um Windows Server com Active Directory Domain Services, o tipo de servidor AD especializado costuma ser a melhor opção, porque mapeia corretamente campos adicionais como o nome de domínio. O tipo de servidor LDAP genérico também funciona contra Active Directory, mas mapeia menos automatismos específicos do AD.

Pré-requisitos

• Acesso ao WebAdmin do Sophos Firewall.
• Alcançabilidade do servidor LDAP a partir do firewall, normalmente na porta 389 (plaintext/StartTLS) ou 636 (LDAPS).
• Uma conta de bind com permissões de leitura sobre a sub-árvore relevante, especificada como Distinguished Name (DN).
• O Base DN sob o qual os utilizadores são procurados, por exemplo ou=people,dc=firma,dc=local.
• Conhecimento do atributo que serve como nome de login, frequentemente uid, sAMAccountName ou mail.
• Em ligações encriptadas: o certificado do servidor ou a cadeia de certificados, caso o firewall deva validá-lo.

⚠️ Uma conta de bind deve ter apenas permissões de leitura sobre a sub-árvore necessária. Não é usada para alterações administrativas no diretório, mas apenas para autenticar pedidos de utilizadores do firewall junto do servidor LDAP.

Criar o servidor LDAP

1. Abrir Authentication > Servers.
2. Selecionar Add e escolher LDAP server como Server type.
3. Em Server name, atribuir um nome único, por exemplo LDAP_Firma_Intern.
4. Em Server IP/domain, inserir o endereço IP ou o nome DNS do servidor LDAP.
5. Em Version, escolher a versão LDAP suportada pelo servidor, normalmente Version 3.
6. Em Connection security, escolher entre Plaintext, SSL/TLS ou STARTTLS.
7. Em Port, definir a porta adequada, caso não seja usada a porta padrão.
8. Desativar Anonymous login, caso o servidor não permita pedidos de bind anónimos.
9. Em Bind DN, inserir a conta técnica como Distinguished Name, por exemplo cn=svc-sophos,ou=service,dc=firma,dc=local.
10. Inserir a Password correspondente.
11. Em Base DN, inserir o âmbito de pesquisa para utilizadores, por exemplo ou=people,dc=firma,dc=local.
12. Em Authentication attribute, inserir o campo que serve como nome de login, frequentemente uid.
13. Opcionalmente, definir Display name attribute e Email address attribute, por exemplo cn e mail.
14. Opcionalmente, definir Group name attribute, caso as associações de grupo devam ser avaliadas.
15. Executar Test connection e verificar o resultado.
16. Selecionar Save.

Os campos em resumo:

Um Test connection bem-sucedido apenas comprova que o servidor, a porta, a conta de bind e a base de pesquisa estão, em princípio, alcançáveis. Se os utilizadores certos são encontrados e os grupos corretamente associados tem de ser verificado depois com um utilizador de teste real.

Escolher corretamente a encriptação

Em ambientes produtivos, a ligação entre o firewall e o servidor LDAP deve ser encriptada, seja via LDAPS na porta 636, seja via STARTTLS na porta clássica 389. LDAP em plaintext envia palavras-passe de bind e, em parte, dados de utilizadores sem encriptação, devendo ser usado apenas em cenários de teste internos e bem protegidos.

Em Validate server certificate, o firewall verifica se o certificado apresentado pelo servidor LDAP é confiável. Com certificados autoassinados, como os usados por exemplo pelo Google Secure LDAP, o certificado pode ser marcado como não confiável, mesmo que a ligação funcione. Neste caso, deve decidir-se conscientemente se a verificação do certificado é ajustada ou se o certificado é importado para o firewall.

Exemplo: Google Secure LDAP

O Google Secure LDAP mostra bem como um diretório baseado em cloud é ligado via LDAP genérico:

• Server IP/domain: ldap.google.com
• Port: 636
• Version: 3
• Connection security: SSL/TLS
• Bind DN e Password: credenciais das LDAP Client Credentials geradas na Google Admin Console.
• Certificado: o certificado de cliente emitido pela Google, com a chave privada, é guardado no firewall.
• Atributos: uid para o login, cn para o nome apresentado, mail para o endereço de e-mail, memberOf para grupos.

Este exemplo pode ser transposto para outros fornecedores LDAP com estrutura semelhante. O que decide é sempre qual o atributo que o fornecedor realmente preenche para nome de login, nome apresentado, e-mail e associação de grupo.

Inserir corretamente o Bind DN e o Base DN

A fonte de erro mais comum num novo servidor LDAP é uma sintaxe DN mal escrita ou mal compreendida.

Regras importantes:

• Um DN é escrito da parte mais específica para a mais geral, por exemplo cn=svc-sophos,ou=service,dc=firma,dc=local.
• O Base DN para a pesquisa de utilizadores tem de ser a sub-árvore onde os objetos de utilizador relevantes realmente se encontram, não necessariamente a raiz do diretório.
• Se os utilizadores estiverem em várias unidades organizacionais, o Base DN tem de ser escolhido suficientemente acima na árvore para incluir todos os contentores relevantes.
• Append base DN decide se o Base DN é adicionalmente anexado ao Bind DN. Isto depende do servidor e deve ser testado de forma específica em caso de problemas.

Se o Base DN for escolhido de forma demasiado restrita, o firewall pode, em determinadas circunstâncias, reportar um teste de ligação bem-sucedido, mas depois não encontrar utilizadores. Se o Base DN for escolhido de forma demasiado ampla, a pesquisa pode demorar desnecessariamente ou incluir objetos indesejados.

Associar grupos e atributos

Para regras de firewall, Web Policies ou permissões VPN por grupo, o Group name attribute é decisivo. Determina qual o atributo LDAP que o firewall interpreta como associação de grupo.

Padrões típicos:

• Diretórios com esquema clássico groupOfNames ou posixGroup usam frequentemente um atributo como memberOf ou avaliam a associação de grupo através de referências inversas.
• Diretórios cloud com proxy LDAP, por exemplo Google Secure LDAP, entregam grupos frequentemente diretamente no atributo memberOf do objeto de utilizador.
• Se o esquema não for claro, um browser LDAP ou uma ferramenta de linha de comandos como ldapsearch ajuda a ver o objeto de utilizador na íntegra antes de configurar o firewall.

Depois da configuração, deve testar-se pelo menos um utilizador de cada grupo relevante. Um único login bem-sucedido não comprova que a associação de grupo funciona corretamente para todos os grupos.

Ativar o servidor LDAP para serviços

Um servidor LDAP criado ainda não autentica ninguém por si só. Tem também de ser associado ao serviço pretendido em Authentication > Services, por exemplo VPN Portal, SSL VPN, Captive Portal ou login de administração.

Procedimento prático:

1. Abrir Authentication > Services.
2. Selecionar o serviço em causa, por exemplo Firewall authentication methods ou VPN.
3. Adicionar o servidor LDAP recém-criado como fonte de autenticação.
4. Verificar a ordem, caso vários servidores sejam usados em paralelo.
5. Testar o serviço previsto com um utilizador de teste.

Se vários servidores de autenticação estiverem ativos simultaneamente, por exemplo LDAP e utilizadores locais, a ordem deve ser escolhida conscientemente. O firewall consulta os servidores na ordem configurada.

Testar e validar a ligação

Depois de guardar, a configuração deve ser testada em várias etapas:

1. Test connection na máscara do servidor: confirma a alcançabilidade, a conta de bind e o Base DN.
2. Autenticar um utilizador de teste no serviço de destino: confirma que a autenticação realmente funciona.
3. Verificar a associação de grupo: confirma que o Group name attribute é avaliado corretamente.
4. Testar utilizador ou palavra-passe errados: confirma que os logins falhados são rejeitados de forma limpa.
5. Verificar o Log Viewer: mostra se os pedidos de autenticação chegam e são processados como esperado.

Um utilizador de teste que se autentica com sucesso, mas não é associado ao grupo esperado, indica normalmente um Group name attribute incorreto ou um esquema de grupos inesperado.

Erros típicos

• Sintaxe DN incorreta: Bind DN ou Base DN estão trocados, mal escritos ou usam separadores errados. Verificar a sintaxe contra o esquema do diretório.
• Base DN escolhido de forma demasiado restrita: o teste de ligação é bem-sucedido, mas os utilizadores reais não são encontrados. Definir o Base DN mais acima na árvore do diretório.
• Porta ou encriptação errada: LDAPS na porta 389 ou plaintext na porta 636 não funciona. A porta e o Connection security têm de corresponder entre si.
• Certificado não confiável: com certificados autoassinados, o firewall pode classificar a ligação como não confiável. Importar conscientemente o certificado ou ajustar a validação de forma específica.
• Anonymous login ativo, apesar de o servidor o recusar: o bind falha. Desativar Anonymous login e inserir Bind DN/Password.
• Atributo de grupo não corresponde ao esquema: o login funciona, mas as políticas de grupo não são aplicadas. Verificar o atributo contra o esquema LDAP real, por exemplo com ldapsearch.
• Servidor LDAP não associado em Authentication > Services: o servidor está criado, mas não é usado por nenhum serviço. Fazer a associação em Authentication > Services.
• Vários servidores de autenticação em ordem errada: outro servidor responde primeiro e produz um comportamento inesperado. Verificar a ordem em Authentication > Services.

FAQ