Ligar um servidor LDAP genérico à Sophos Firewall

A Sophos Firewall pode autenticar utilizadores através do tipo de servidor LDAP server, com base nos atributos do diretório e na pertença a grupos. Na prática, são necessários quatro passos: preparar um grupo local, ligar o servidor LDAP, selecioná-lo em Authentication > Services para o serviço pretendido e verificar o início de sessão e a autorização com contas de teste reais.

OpenLDAP, 389 Directory Server ou FreeIPA são candidatos típicos para uma ligação LDAP genérica, mas não são produtos intercambiáveis. Os atributos, os valores de grupo devolvidos e a expiração das contas variam consoante o esquema. Por isso, este guia fornece um exemplo reutilizável; os valores devem ser verificados no objeto de utilizador real. O Google Secure LDAP é descrito abaixo como uma variante própria documentada pela Sophos.

Para Windows Active Directory com LDAPS, importação de grupos ou AD SSO, Ligar o Active Directory à Sophos Firewall é uma opção mais adequada. O RADIUS através do Microsoft NPS ou de um gateway MFA é abordado em Configurar um servidor RADIUS na Sophos Firewall. Quem precisar de substituir o tipo de servidor nativo do eDirectory antes do SFOS 23 encontra o processo de migração completo em Migrar o eDirectory antes do SFOS 23.

Preparar valores e caminho de reversão

É necessário:

acesso ao WebAdmin da Sophos Firewall;
acesso da firewall ao servidor LDAP através da porta configurada no servidor;
uma conta de bind com direitos de leitura para a área de diretório necessária;
Bind DN e Base DN, por exemplo cn=svc-sophos,ou=service,dc=example,dc=net e ou=people,dc=example,dc=net;
os atributos de início de sessão, nome de apresentação, endereço de e-mail, grupo e, se aplicável, expiração da conta;
para validar o certificado, um nome de servidor resolvível e a cadeia de certificação da CA adequada.

Os valores iniciais habituais são a porta 389 para STARTTLS e 636 para SSL/TLS. Não constituem uma regra rígida do SFOS: um diretório pode utilizar uma porta diferente, que deve corresponder a Connection security e à configuração do servidor.

⚠️ A conta de bind não requer permissões administrativas de escrita. Limite os respetivos direitos de leitura à subárvore e aos atributos de que a firewall necessita para as consultas de utilizador.

Antes de efetuar alterações em Authentication > Services, documente os servidores selecionados, a respetiva ordem e as opções de herança para cada método afetado. Em Firewall authentication methods, registe também o Default group anterior. Desta forma, pode anular a alteração sem eliminar precipitadamente os novos objetos. Durante as alterações, mantenha disponível um acesso de administrador local previamente testado para recuperação.

Distinguir Bind DN, Base DN e atributos

Um DN vai do objeto específico até à raiz do diretório. cn=svc-sophos,ou=service,dc=example,dc=net identifica a conta de bind no exemplo. A Base DN, por outro lado, especifica o ponto inicial da pesquisa do utilizador, como ou=people,dc=example,dc=net.

Uma Base DN demasiado restrita não encontrará todos os utilizadores necessários. Uma base de pesquisa desnecessariamente ampla pode tornar as pesquisas mais lentas e incluir objetos indesejados. Append base DN anexa a Base DN a um Bind DN incompleto durante o bind; se o DN já estiver completo, a opção fica normalmente desativada. O comportamento do servidor LDAP utilizado é determinante.

Os atributos também provêm do esquema do diretório. uid, cn, mail e memberOf são exemplos, não especificações universais. A Sophos recomenda memberOf como Group name attribute, mas utiliza GID no seu próprio exemplo de configuração geral. Por isso, o valor devolvido, o mapeamento para o grupo local e a pertença a vários grupos devem ser verificados com utilizadores de teste reais.

Escolher encriptação e certificados

Plaintext envia credenciais de utilizador não encriptadas e não é uma boa configuração de produção. SSL/TLS encripta a ligação desde o início; STARTTLS atualiza uma ligação LDAP inicialmente não encriptada para TLS.

Para Validate server certificate, deve indicar em Server IP/domain o nome especificado no certificado do servidor e que a firewall consegue resolver. A Sophos refere-se a este nome como CNAME na ajuda do SFOS 22, enquanto a mesma descrição de campo noutro local menciona apenas o IP do servidor. Por isso, o nome do certificado é a escolha segura para uma implementação controlada de TLS. Se a firewall não conseguir resolver esse nome, pode criar uma entrada em Network > DNS > DNS host entry. O TTL, a pesquisa inversa e o teste de resolução são explicados em Configurar entradas de host DNS na Sophos Firewall.

Validate server certificate verifica o certificado do servidor LDAP remoto. O Client certificate opcional especifica um certificado que a firewall utiliza para estabelecer uma ligação segura com o serviço LDAP; o Google Secure LDAP requer explicitamente o certificado gerado pelo Google. Em caso de erros de TLS, corrija primeiro o nome, o DNS, a hora, a validade e a cadeia de certificação, em vez de desativar a verificação do certificado do servidor como primeira medida.

Configurar grupo e servidor LDAP

Preparar grupo local

Abra Authentication > Groups e selecione Add.
Introduza um Group name exclusivo, por exemplo LDAP-Benutzer.
Selecione o Group type adequado ao método de início de sessão previsto. Normal requer o início de sessão do utilizador; Clientless controla o acesso com base num endereço IP.
Defina as políticas necessárias de utilizador, acesso remoto e início de sessão e guarde com Save.

Em Surfing quota e Access time, escolha deliberadamente os limites necessários. A Sophos utiliza Unlimited internet access e Allowed all the time no exemplo de configuração; são políticas de exemplo, não um requisito para LDAP. Para um acesso piloto restrito, são mais adequados a duração de utilização efetivamente necessária e o período de acesso autorizado. Mantenha os restantes campos nos valores predefinidos apenas se estes corresponderem à sua política de acesso.

O grupo será usado posteriormente como Default group. Por si só, não concede ou bloqueia tráfego; a decisão depende das respetivas políticas e das regras do serviço. Nas políticas de utilizador e nas VPN de acesso remoto, exceto SSL VPN, as definições específicas do utilizador têm precedência sobre as políticas de grupo. Esta regra de precedência não se aplica à SSL VPN de acesso remoto: um utilizador pode aceder aos recursos de todas as políticas de túnel completo e de túnel dividido aplicáveis a si ou aos seus grupos. Por isso, uma política de utilizador mais restritiva não anula automaticamente permissões mais amplas concedidas pelos grupos para SSL VPN. Isto não constitui uma garantia geral de que todos os esquemas LDAP representam da mesma forma a pertença a vários grupos; a atribuição de grupos e os recursos efetivamente acessíveis devem ser verificados na fase piloto. A lógica de grupo completa, incluindo a fase piloto, as exceções específicas do utilizador e o grupo principal, está disponível em Gerir grupos de utilizadores da Sophos Firewall com segurança.

Criar a ligação e configurar o bind

Abra Authentication > Servers e selecione Add.
Em Server type, selecione LDAP server.
Atribua um Server name exclusivo, por exemplo LDAP-Firma.
Introduza o IP ou o nome de domínio do servidor em Server IP/domain. Para Validate server certificate, utilize o nome indicado no certificado do servidor e que a firewall consegue resolver.
Selecione a Version suportada pelo servidor, 2 ou 3. O Google Secure LDAP requer a versão 3.
Configure Connection security e Port em conjunto. Em produção, utilize SSL/TLS ou STARTTLS.
Desative Anonymous login e introduza Bind DN e Password da conta de leitura.
Ative Append base DN apenas se pretender que a firewall anexe a Base DN a um Bind DN incompleto durante o bind.
Se a ligação for segura, decida explicitamente se pretende ativar Validate server certificate. Para servidores LDAP normais, a validação depois de configurar corretamente o nome, o DNS e a cadeia de confiança é a opção segura em produção. O Google Secure LDAP segue o caso especial descrito abaixo. Selecione na lista um Client certificate, se necessário.

Definir base de pesquisa e atributos

Introduza o ponto inicial da pesquisa do utilizador em Base DN. Get base DN pode obter a base de pesquisa disponibilizada pelo servidor.
Em Authentication attribute, configure o atributo com o nome de início de sessão, normalmente uid ou mail.
Introduza Display name attribute e Email address attribute de acordo com o objeto de utilizador, por exemplo cn e mail.
Introduza em Group name attribute o atributo de grupo devolvido no objeto de utilizador. memberOf é a recomendação da Sophos, mas deve corresponder ao esquema e ao formato dos dados devolvidos.
Introduza o Expiry date attribute correspondente ao esquema. Se esse atributo não existir, verifique antes da implementação se o formulário aceita um valor vazio e como são tratadas as contas sem data de expiração.
Execute Test connection e guarde com Save.

Display name attribute e Email address attribute são campos opcionais no servidor LDAP genérico. O nome de apresentação facilita a identificação do objeto de utilizador local; o atributo de e-mail fornece o endereço correspondente. Em contrapartida, o atributo de e-mail é necessário para a criação de grupos LDAP do Google. Um Expiry date attribute indica a expiração da conta, não a duração de uma sessão VPN. A Sophos indica Date no exemplo de configuração geral e expiry para o Google; o nome de atributo adequado depende do respetivo esquema.

Segundo a Sophos, Test connection verifica a ligação e as credenciais de bind. O teste não prova que a Base DN inclui todos os utilizadores nem que uma autorização de grupo ou serviço é aplicada corretamente. Para isso, é necessário um início de sessão real.

Apenas para automatização por API na passagem do SFOS 22 para o SFOS 23: Na referência da API LDAP mudam as linhas documentadas em Status Message Information: para Add LDAP server, de 200/500/502/503 para 200/400/401/403/409/500; para Edit LDAP server, de 200/500/503 para 200/400/401/403/404/500. 409 aparece apenas para Add e 404 apenas para Edit. Os símbolos de apresentação também mudam de Message.LDAP* para Message.CP*. Estas linhas e símbolos da documentação não garantem os códigos ou mensagens efetivamente transmitidos nem estabelecem um mapeamento fixo de 502/503 para 409/404. Para automatização por API, consulte a referência da versão utilizada e valide as respostas reais da firewall de destino antes de adotar um mapeamento. Esta verificação da API é separada; continuam a ser necessários o teste Test connection na GUI e um início de sessão real.

Antes de cada operação automatizada de adição/edição de LDAP: As referências da API para o SFOS 22 e 23 são contraditórias quanto a IntegrationType: o exemplo indica LooseIntegration/TightIntegration e assinala DisplayNameAttribute, EmailAddressAttribute, GroupNameAttribute e ExpiryDateAttribute com o comentário Only For Tight Integration; a tabela de parâmetros descreve ambos os modos, mas permite apenas 1. Não deduza daí que um dos modos é suportado, qual o significado de 1 ou se é permitido omitir atributos condicionais. O exemplo não é um payload pronto a enviar; os seus valores textuais para opções de ativação/desativação e segurança da ligação também não correspondem às codificações das tabelas. Antes de efetuar uma alteração, consulte o esquema ou a referência da API da versão de destino e verifique, em modo só de leitura, a configuração real de destino e uma resposta da API correspondente. Se o mapeamento continuar pouco claro, não execute qualquer automatização baseada nele; utilize antes o procedimento verificado na GUI ou esclareça os requisitos da API com o Suporte Sophos. Os passos na GUI descritos acima mantêm-se separados desta verificação; continuam a ser necessários Test connection e testes reais de identidade, grupos, expiração da conta, se aplicável, e cada serviço utilizado.

Ativar o LDAP para os serviços necessários

Abra Authentication > Services.
Em Firewall authentication methods, mova o servidor LDAP para Selected authentication servers. Se tiver de ser consultado primeiro, coloque-o na primeira posição.
Como Default group, selecione o grupo preparado LDAP-Benutzer e clique em Apply.
Selecione o servidor separadamente para todos os métodos efetivamente utilizados: User portal authentication methods, VPN portal authentication methods, VPN (IPsec/dial-in/L2TP/PPTP) authentication methods, Administrator authentication methods e SSL VPN authentication methods.
Utilize opções de herança como Set authentication methods same as firewall, Same as firewall ou Same as VPN apenas se pretender utilizar a lista de servidores herdada.

Podem ser selecionados, no máximo, 20 servidores por método de autenticação. Se houver vários servidores, a firewall consulta-os pela ordem apresentada. O método de administrador não se aplica ao Super Administrator. Para L2TP e PPTP, a Sophos documenta apenas PAP para LDAP; esta combinação não deve ser introduzida numa nova configuração sem uma avaliação prévia, tanto pelo protocolo como pelo caráter obsoleto desses métodos VPN.

Passos adicionais para inícios de sessão de administrador: Um utilizador autenticado externamente por LDAP é inicialmente criado como utilizador normal no primeiro início de sessão, mesmo que tenha uma função de administrador no diretório. Primeiro, inicie sessão com a conta prevista num serviço autorizado, como o portal do utilizador ou o portal VPN. Depois, com o acesso de administrador local existente, edite o utilizador criado em Authentication > Users, defina User type como Administrator, selecione um Profile limitado às permissões necessárias e guarde com Save. Selecionar o servidor em Administrator authentication methods não é suficiente. Em seguida, verifique o início de sessão no WebAdmin e as ações administrativas permitidas e não permitidas com esta conta; mantenha disponível o acesso local de recuperação já testado.

Configurar o Google Secure LDAP

Antes de configurar a firewall, crie um cliente LDAP na Google Admin Console em Apps > LDAP. Limite as respetivas Access permissions, transfira o certificado e a chave privada e gere credenciais distintas. A palavra-passe deixa de estar visível depois de fechar a caixa de diálogo. Se o nome de utilizador ou a palavra-passe estiverem incorretos ou já não estiverem disponíveis, gere novas credenciais de acesso na Google Admin Console e atualize depois Bind DN e Password na configuração do servidor LDAP da firewall.

O Google pode alterar a interface e os passos da Admin Console. Antes de iniciar a configuração, consulte a documentação atual do Google sobre a criação de clientes LDAP, a transferência do certificado e a geração de credenciais de acesso. A disponibilidade do serviço para a sua edição do Google é explicada em Google Secure LDAP; as permissões de acesso devem corresponder à área de utilizadores e grupos prevista.

O procedimento documentado pela Sophos na Google Admin Console pode ser seguido desta forma:

Em Apps > LDAP, comece com ADD CLIENT, introduza um nome de cliente LDAP e uma Description e selecione CONTINUE. Um nome exclusivo como Sophos-Firewall-Pilot facilita a identificação posterior.
Limite as Access permissions à área de utilizadores e grupos necessária e confirme com ADD LDAP CLIENT.
Selecione Download certificate. O ZIP contém o ficheiro de certificado .cer e a chave privada .key. Extraia ambos os ficheiros para uma pasta de trabalho protegida e registe a localização para a importação subsequente. A chave privada não deve ser incluída em pedidos de suporte nem em partilhas desprotegidas.
Prossiga com CONTINUE TO CLIENT DETAILS, abra o cartão Authentication e selecione GENERATE NEW CREDENTIALS. Registe Username e Password de forma segura antes de selecionar CLOSE; estes valores serão utilizados posteriormente como Bind DN e Password, e não as credenciais de um administrador do Google.

As credenciais de acesso do Google não substituem o certificado de cliente. Para esta variante, a Sophos Firewall necessita tanto do certificado com a chave privada como das credenciais de bind geradas.

Em seguida, ative o cliente em Service status com ON for everyone e guarde com SAVE. Este estado do serviço ativa o cliente, mas não substitui as Access permissions definidas anteriormente.

Antes de importar o certificado, verifique em Administration > Time se a firewall está a obter a hora correta por NTP. Segundo a Sophos, uma hora definida manualmente de forma incorreta pode causar a falha da importação de certificados. Em seguida, em Certificates > Certificates > Add, selecione o formato CER (.cer) e importe tanto Certificate como Private key do pacote transferido do Google. O certificado pode aparecer como não fidedigno porque o próprio Google o assina; a Sophos confirma que o Google LDAP continua a funcionar. Esta indicação refere-se ao certificado de cliente e não à validação do certificado do servidor LDAP.

Ao importar, atribua um nome exclusivo ao certificado. Através de Choose File, selecione o ficheiro .cer extraído para Certificate e o ficheiro .key correspondente para Private key, confirme cada seleção com Open e, por fim, selecione Save. Só depois de guardar será possível selecionar este certificado em Client certificate no servidor LDAP.

Ao servidor LDAP aplicam-se os seguintes valores:

Server IP/domain: ldap.google.com
Version: 3
Connection security: SSL/TLS
Port: 636
Anonymous login: desativado
Bind DN e Password: as credenciais LDAP do Google geradas
Append base DN: desativado
Client certificate: o certificado importado do Google
Base DN: introduza ou obtenha com Get base DN
Authentication attribute: UID
Display name attribute: CN
Email address attribute: mail
Group name attribute: memberOf
Expiry date attribute: expiry

mail é necessário para a criação de grupos LDAP do Google. As instruções da Sophos para o Google Secure LDAP não definem explicitamente Validate server certificate na respetiva lista de valores. Daí não se pode concluir que seja obrigatório ativar ou desativar a opção; a decisão deve seguir o procedimento geral de TLS e a sua cadeia de confiança. A indicação de que um certificado de cliente do Google não é fidedigno não é motivo para desativar a verificação do certificado do servidor remoto.

Verifique a ligação ao Google com Test connection e guarde o servidor com Save. Em seguida, prepare um grupo LDAP local conforme descrito acima e selecione o servidor do Google em Authentication > Services para os serviços necessários. Também no caso do Google, a criação do objeto de servidor, por si só, ainda não torna nenhum serviço utilizável; o início de sessão piloto verifica depois a identidade, o grupo e a autorização.

Verificar o início de sessão e a atribuição de grupos

A validação para aceitação inclui a ligação, a identidade e a autorização:

Test connection deve confirmar a ligação e as credenciais de bind.
Em Authentication > Services, verifique a lista de servidores, a ordem e a herança de cada método utilizado. O Default group pertence a Firewall authentication methods.
Inicie sessão no serviço pretendido com um utilizador piloto. No primeiro início de sessão, a firewall cria localmente o utilizador autenticado externamente.
Em Authentication > Users, verifique se o utilizador e o grupo aparecem conforme o esperado.
Realize um teste positivo para cada grupo de diretório relevante. Além disso, verifique com um utilizador sem uma atribuição de grupo local adequada se o Default group esperado se aplica.
Verifique não só o início de sessão, mas também a política ou regra de teste pretendida. Para SSL VPN, teste os recursos permitidos e bloqueados, tendo em conta as políticas de utilizador e de grupo aplicáveis; não deduza as permissões efetivas apenas a partir de uma política de utilizador restritiva. Em seguida, utilize uma palavra-passe incorreta como teste negativo.
Para o início de sessão, a autorização e a contabilização de utilizadores, consulte access_server.log; para problemas do portal VPN, consulte também vpnportal.log.
Se um atributo de expiração for usado, inclua uma conta de teste com estado de expiração conhecido.

Se os valores do esquema não estiverem claros, um administrador poderá consultar o objeto de utilizador em modo só de leitura a partir de um sistema de administração Linux ou diretamente do servidor LDAP:

ldapsearch -LLL -x -H ldaps://ldap.example.net:636 \
  -D 'cn=svc-sophos,ou=service,dc=example,dc=net' -W \
  -b 'ou=people,dc=example,dc=net' \
  '(uid=max.muster)' '*' '+'

Este procedimento de diagnóstico opcional não é um comando SFOS e não deve ser executado na Advanced Shell. O exemplo pressupõe LDAPS e confiança na CA do servidor no sistema que executa o comando; STARTTLS requer um comando devidamente adaptado. -W solicita a palavra-passe de bind de forma interativa. Adapte o filtro (uid=max.muster) ao Authentication attribute configurado. '*' e '+' podem apresentar muitos atributos normais e operacionais com dados pessoais. Antes de anexar ou partilhar o resultado num pedido de suporte, os dados devem ser anonimizados.

Isolar erros por sintoma

Sem ligação: Verifique o encaminhamento, o DNS, a porta e Connection security. Em seguida, verifique Bind DN, palavra-passe e Anonymous login.
Erro de TLS ou certificado: Verifique o nome do certificado do servidor, a resolução DNS, a hora da firewall, a validade e a cadeia da CA. Não desative a verificação do certificado como primeira medida.
Test connection funciona, mas o utilizador não é encontrado: Compare a Base DN, Authentication attribute e o nome de início de sessão introduzido.
O início de sessão funciona, mas o grupo está errado: Verifique Group name attribute e o respetivo valor devolvido, o mapeamento para o grupo local e Default group. memberOf é uma recomendação, mas não garante o mapeamento para todos os esquemas.
O servidor foi criado, mas não é usado: Verifique a seleção, a ordem e a herança do serviço afetado em Authentication > Services.
O bind do Google Secure LDAP falha: Verifique individualmente a versão 3, a porta 636, Anonymous login desativado, Append base DN desativado, o estado do serviço do cliente, as credenciais e o certificado de cliente do Google.
A pesquisa é lenta ou devolve contas indesejadas: Limite a Base DN à subárvore necessária.
O início de sessão funciona, mas a política esperada não é aplicada: Verifique separadamente as definições específicas do utilizador, a política de grupo, o mapeamento de grupos e a regra de firewall ou VPN aplicável. Para SSL VPN, inclua todas as políticas de utilizador e de grupo aplicáveis e os recursos efetivamente permitidos; uma política de utilizador restritiva, por si só, não é suficiente. O modelo de diagnóstico completo é apresentado em Resolver sistematicamente falhas de autenticação.
O início de sessão no portal funciona, mas no WebAdmin não: Em Authentication > Users, verifique a função de administrador atribuída manualmente e o Profile. Em seguida, verifique a seleção do servidor em Administrator authentication methods e as regras de acesso ao dispositivo aplicáveis. Não abdique do acesso local de recuperação antes de testar o novo método.

Reverter com segurança

Em caso de falha na implementação, reponha primeiro a seleção, a ordem e a herança de servidores previamente documentadas para cada método afetado. Em Firewall authentication methods, reponha também o Default group anterior. Realize um teste positivo e um teste negativo com o método de autenticação anterior e verifique os registos relevantes.

Elimine o novo servidor e o novo grupo LDAP apenas quando já não forem utilizados em nenhum serviço ou política. Não elimine utilizadores LDAP criados automaticamente com Purge AD users: a ajuda do SFOS 22 documenta essa função apenas para o Active Directory. Se esses utilizadores tiverem de ser removidos, confirme previamente com o Suporte Sophos o procedimento suportado para a sua configuração.