Sophos Firewall: migrar eDirectory antes do SFOS 23

O SFOS 23.0 deixa de suportar o servidor de autenticação eDirectory nativo. Se permanecer uma configuração de servidor eDirectory nativo na firewall, o upgrade de firmware para SFOS 23.0 ou posterior falha. Antes do upgrade, é por isso necessário ter um servidor de autenticação suportado a funcionar e remover por completo as configurações nativas de servidor eDirectory e SSO.

O eDirectory continua a funcionar no SFOS 22.0 MR2. Este período deve ser utilizado para uma operação paralela controlada: adicionar a nova fonte, validar utilizadores e grupos com contas reais, migrar os serviços de autenticação de forma controlada e eliminar o eDirectory apenas quando o caminho de reversão já não for necessário. Os serviços SSO do Entra ID associados são tratados em conjunto. A visão geral do MR2 enquadra as restantes alterações desta versão.

Processo resumido

Inventariar todas as dependências do eDirectory em servidores, grupos, serviços, regras, VPN e SSO.
Preparar um backup atual, um administrador local e um acesso à consola documentado.
Escolher LDAP genérico, Active Directory, RADIUS ou Microsoft Entra ID SSO como destino, consoante o caso de utilização.
Adicionar o novo servidor de autenticação em paralelo e validar a ligação, os utilizadores e os grupos.
Associar deliberadamente os grupos e as políticas à nova fonte.
Migrar de forma controlada os serviços em Authentication > Services e testá-los com contas reais; tratar em conjunto os serviços SSO do Entra ID associados.
Só depois da validação completa, eliminar todas as configurações nativas de servidor eDirectory e SSO, criar outro backup e iniciar o upgrade para SFOS 23.

Esta migração não se faz com um único interruptor. A firewall utiliza servidores de autenticação por serviço e numa ordem definida. Além disso, as permissões dependem frequentemente de grupos que podem manter o mesmo nome visível depois da migração, mas não têm automaticamente a mesma associação nem o mesmo efeito.

O que depende atualmente do eDirectory

Antes da primeira alteração, tem de ficar claro onde o eDirectory é realmente utilizado. O inventário deve incluir pelo menos estas áreas:

Em Authentication > Servers encontram-se os servidores eDirectory e, se aplicável, vários destinos de diretório.
Em Authentication > Services define-se, para cada serviço, que servidores são consultados e por que ordem.
Em Authentication > Groups, as políticas de grupo, Default Group e a ordem dos grupos podem determinar as permissões efetivas de um utilizador. No Active Directory, juntam-se Main Group e outras associações.
As regras de firewall, as políticas Web e Application, e Traffic Shaping podem fazer referência a utilizadores ou grupos.
VPN Portal, SSL VPN, Remote Access IPsec, User Portal e Captive Portal têm caminhos de início de sessão e autorização próprios.
MFA e os inícios de sessão administrativos podem depender dos grupos e da ordem de autenticação.
Os reports baseados em utilizadores e a identificação transparente de utilizadores continuam a exigir uma associação fiável entre o utilizador e a ligação.

Uma captura de ecrã da ordem atual dos servidores, serviços e grupos é muitas vezes mais útil do que uma simples lista de nomes. Para cada grupo importante, deve também registar-se pelo menos um utilizador de teste positivo e outro negativo. Assim, é possível verificar mais tarde não só quem obtém acesso, mas também quem é corretamente rejeitado.

Escolher o método de destino adequado

Não existe um substituto universal 1:1 para todos os ambientes eDirectory. Uma organização pode continuar a utilizar o diretório existente através de LDAP, migrar as identidades para outro diretório ou combinar vários métodos de autenticação consoante o serviço.

Manter o eDirectory existente através de LDAP genérico

Se o próprio eDirectory permanecer em utilização, a Sophos Firewall pode consultá-lo para inícios de sessão de utilizadores através do tipo de servidor suportado LDAP server. Este método não altera automaticamente a árvore do diretório, mas exige uma nova configuração LDAP com a Base DN e os atributos de início de sessão e de grupo adequados.

A limitação importante é que o SSO nativo do eDirectory deixa de estar disponível a partir do SFOS 23. O servidor LDAP genérico trata da autenticação, mas não da identificação transparente de utilizadores. Por isso, os utilizadores anteriormente identificados de forma automática precisam de um novo fluxo de SSO ou de início de sessão. A descrição completa dos campos está disponível em Ligar um servidor LDAP genérico ao Sophos Firewall.

Active Directory

O Active Directory é adequado quando os utilizadores já existem num domínio Windows ou são deliberadamente migrados para esse domínio. Nesse caso, é necessário importar os grupos, voltar a verificar Main Group e as políticas, e implementar separadamente qualquer identificação transparente de utilizadores necessária. Ligar Active Directory à Sophos Firewall explica LDAPS, a importação de grupos e os testes dos serviços.

O STAS comunica de forma transparente os inícios de sessão do domínio Windows à firewall, mas não converte a configuração SSO do eDirectory existente. Se este caminho de identidade for necessário, deve ser planeado como uma migração separada através de STAS para Sophos Firewall.

RADIUS

O RADIUS é adequado quando já existe um serviço de autenticação central ou um gateway MFA. O servidor RADIUS tem de fornecer à firewall as informações necessárias para cada serviço; o modelo de grupos de um diretório não é transferido automaticamente. O método MFA tem de ser compatível com o serviço: por exemplo, o VPN Portal não suporta MFA RADIUS baseado em challenge. Shared Secret, o atributo de grupo, os timeouts e outras limitações são abordados em Configurar um servidor RADIUS no Sophos Firewall.

Microsoft Entra ID SSO

O Microsoft Entra ID SSO pode ser útil para os cenários documentados de portais, administradores e Remote Access. No entanto, não substitui de forma geral todas as consultas de nome de utilizador e palavra-passe nem fornece identificação transparente de utilizadores na LAN. No Remote Access, os serviços relacionados têm de ser coordenados: VPN Portal e SSL VPN utilizam o mesmo servidor Entra; com um ficheiro de aprovisionamento, isto também se aplica a IPsec. Redirect URIs, grupos, Conditional Access e os serviços suportados são descritos em Microsoft Entra ID SSO para Sophos Connect e VPN Portal.

A arquitetura de destino pode ser mista. Por exemplo, o LDAP pode inicialmente autenticar utilizadores do eDirectory existente, enquanto o Remote Access é migrado mais tarde, de forma específica, para RADIUS ou Entra ID SSO. O essencial é que cada serviço utilizado disponha de um caminho de destino testado antes de eliminar o eDirectory.

Proteger o ambiente antes da primeira alteração

Antes do cutover, devem estar preparados os seguintes elementos:

Um backup da Sophos Firewall atual e encriptado.
Um administrador local cujo início de sessão não dependa do eDirectory nem da nova fonte externa. Em Authentication > Services, Local tem de continuar selecionado em Administrator authentication methods.
Um acesso à consola documentado ou outro método de acesso de emergência à firewall.
Capturas de ecrã ou um inventário escrito da ordem dos servidores, serviços e grupos.
Pelo menos uma conta de teste por grupo importante e uma conta que não deve obter acesso.
Uma janela de manutenção, uma pessoa responsável pela decisão e um critério de reversão claro.

O acesso WebAdmin é migrado em último lugar. Antes disso, deve confirmar-se que Local continua selecionado e que o início de sessão local funciona numa janela privada do browser. Assim, mantém-se um acesso independente caso a nova autenticação externa ou a respetiva resolução de grupos não funcione como esperado.

Preparar o servidor de destino em paralelo

Primeiro, adiciona-se o novo servidor. Durante a configuração inicial do servidor, a seleção de eDirectory existente permanece inalterada; apenas no teste piloto se altera exatamente um método de autenticação fácil de controlar.

Exemplo: ligar o eDirectory como servidor LDAP genérico

Em Authentication > Servers > Add, uma configuração piloto poderia ter o seguinte aspeto:

Server type: LDAP server
Server name: EDIR-LDAP-PILOT
Server IP/domain: edir01.example.net
Version: 3
Connection security: SSL/TLS
Port: 636
Bind DN: cn=sfos-bind,ou=service,o=Example
Base DN: ou=users,o=Example
Authentication attribute: por exemplo, uid, depois de verificar o objeto de utilizador
Group name attribute: por exemplo, groupMembership, depois de verificar o objeto de utilizador
Validate server certificate: ativado depois de configurar a CA emissora como fidedigna na firewall

edir01.example.net, Bind DN e Base DN são valores de exemplo e têm de corresponder à árvore de diretório local. Com a validação de certificados ativa, o FQDN configurado tem de corresponder ao certificado do servidor e ser resolvido pela firewall. A conta de bind precisa apenas de acesso de leitura à área necessária do diretório.

O objeto de utilizador real determina que atributos de início de sessão e de grupo são adequados. Num ambiente eDirectory, por exemplo, cn ou uid podem ser relevantes para o início de sessão e groupMembership para os grupos. Estes são candidatos a verificar, não valores universais.

Um objeto de utilizador pode ser consultado em modo read-only a partir de um sistema de administração Linux:

LDAPTLS_CACERT='/secure/path/edir-ca.pem' \
ldapsearch -LLL -x \
  -H 'ldaps://edir01.example.net:636' \
  -D 'cn=sfos-bind,ou=service,o=Example' -W \
  -b 'ou=users,o=Example' -s sub \
  '(|(cn=max.muster)(uid=max.muster))' \
  dn objectClass cn uid mail groupMembership

Este comando não deve ser executado na Advanced Shell da Sophos Firewall. -W pede a palavra-passe de bind de forma interativa para que não fique guardada no histórico da shell. O caminho de LDAPTLS_CACERT, o FQDN, as DNs, o filtro e os atributos solicitados têm de ser adaptados ao ambiente local. Se o cliente OpenLDAP local já confiar na CA através do respetivo Trust Store ou de ldap.conf, LDAPTLS_CACERT pode ser omitido. Caso contrário, a variável aponta para um pacote legível de certificados CA em formato PEM.

Um resultado possível poderia ter o seguinte aspeto:

dn: cn=Max Muster,ou=users,o=Example
cn: Max Muster
uid: max.muster
mail: max.muster@example.net
groupMembership: cn=VPN-Mitarbeitende,ou=groups,o=Example

Este é um exemplo de leitura, não um esquema eDirectory garantido. Se groupMembership estiver ausente ou o diretório devolver outros valores, é necessário identificar o atributo real e adaptar a configuração da firewall em conformidade. Em seguida, validam-se separadamente Test connection, um início de sessão real e o grupo resultante.

Voltar a associar grupos e políticas

Um início de sessão bem-sucedido não é suficiente se o utilizador acabar depois no grupo errado. Supondo que o grupo atual VPN-Mitarbeitende pode utilizar SSL VPN e acede a aplicações internas através de uma regra de utilizador, após a migração é necessário responder pelo menos a estas perguntas:

O utilizador de teste aparece em Authentication > Users com o grupo efetivo esperado? No Active Directory, Main Group e as outras associações são verificadas separadamente.
O novo grupo está presente e na posição correta em Authentication > Groups?
A configuração de SSL VPN ou IPsec faz referência ao novo grupo efetivo?
O utilizador continua a corresponder à regra de firewall pretendida e não a uma regra mais geral?
A política MFA pretendida continua a ser aplicada?

Nomes de grupos visíveis iguais em duas fontes não garantem a mesma associação nem a mesma prioridade de grupo efetiva. No Active Directory, a ordem dos grupos e Main Group podem influenciar VPN, MFA e outras políticas. Os princípios básicos são explicados em Ativar MFA para Sophos Firewall.

Migrar serviço a serviço

Em Authentication > Services, os servidores de autenticação são selecionados por serviço. Por isso, nem tudo é migrado ao mesmo tempo. No entanto, os serviços SSO do Entra ID associados são planeados e validados como um caminho conjunto.

Escolher primeiro um serviço fácil de controlar e um utilizador piloto.
Selecionar o novo servidor para esse serviço e definir deliberadamente a sua posição na ordem dos servidores.
Aplicar a alteração e testar um início de sessão correto e outro deliberadamente incorreto.
Verificar o utilizador, o grupo, a entrada de log e a política efetivamente aplicada.
Só depois migrar o serviço seguinte.

Começa-se com um serviço piloto deliberadamente escolhido e fácil de controlar. Depois, seguem-se as áreas realmente utilizadas, como Firewall authentication methods, User portal authentication methods, VPN portal authentication methods, SSL VPN authentication methods e Remote Access IPsec. No Entra ID SSO, os serviços Remote Access associados descritos acima são migrados de forma coordenada. Devido ao risco de bloqueio, Administrator authentication methods é migrado em último lugar. A visão geral dos portais da Sophos Firewall explica que portais funcionam separadamente e têm de estar acessíveis.

Se existir o mesmo nome de utilizador nos servidores antigo e novo, a ordem dos servidores pode ocultar uma associação incorreta de grupos. Para um teste controlado, pode selecionar-se temporariamente apenas o novo servidor no serviço piloto escolhido. Depois, o início de sessão real e Authentication > Users mostram se a nova fonte devolve o utilizador associado ao grupo esperado.

Validar com ligações reais

Test connection confirma a acessibilidade e as credenciais do servidor. A validação só termina quando o serviço real e as permissões associadas funcionam.

Para cada grupo relevante, a validação deve demonstrar pelo menos o seguinte:

Um utilizador autorizado consegue iniciar sessão no portal ou serviço VPN previsto.
Um utilizador não autorizado é rejeitado ou recebe apenas a política restrita prevista.
Em Authentication > Users, o utilizador e o grupo estão corretos.
O Log Viewer mostra um evento de autenticação rastreável.
As políticas de firewall, Web e VPN correspondem à regra esperada.
Os destinos internos estão acessíveis através do caminho de tráfego previsto.
MFA e as funções administrativas comportam-se conforme planeado.

Firewall Rule Testing e Log Viewer permite verificar que Rule ID é aplicada a um utilizador e ao respetivo tráfego. A identificação transparente de utilizadores ou o SSO são testados separadamente; um início de sessão LDAP bem-sucedido não confirma este caminho.

Caminho de reversão durante a fase piloto

Enquanto a firewall ainda utilizar o SFOS 22.0 MR2 e o eDirectory não tiver sido eliminado, a configuração anterior permanece disponível como caminho de reversão controlado. Se um teste piloto falhar, revertem-se todos os valores alterados para esse teste: a seleção e a ordem dos servidores em Authentication > Services, Default Group e a ordem dos grupos, bem como os membros VPN e as referências MFA e de políticas afetados. Em seguida, voltam a verificar-se o início de sessão, o grupo e a política.

O backup protege a configuração da firewall, mas não é uma migração automática de identidades. Os backups e as importações de configuração não convertem nem migram a configuração eDirectory que contêm. Por isso, um backup deste tipo não é um caminho de reversão funcional para o eDirectory após o upgrade.

Eliminar o eDirectory e autorizar o upgrade para SFOS 23

O eDirectory só é eliminado após um período de observação definido previamente. Durante esse período, todos os caminhos de início de sessão utilizados em produção, cada grupo importante, as ligações VPN em uso e os processos administrativos têm de ter funcionado sem erros, pelo menos uma vez, através da nova fonte e em condições realistas. Erros de autenticação, grupo ou política por resolver impedem a autorização para eliminação.

Para concluir a migração:

Verificar que o eDirectory já não está selecionado em nenhum método de autenticação.
Voltar a comparar com o inventário as dependências de grupos, VPN, políticas, MFA, administradores e SSO.
Eliminar da firewall todas as configurações nativas de servidor eDirectory e SSO do eDirectory. Um LDAP server genérico recém-adicionado que consulta o mesmo diretório permanece configurado.
Verificar em Authentication > Servers, Authentication > Services e no inventário que não resta nenhuma configuração ou dependência nativa do eDirectory.
Criar um novo backup encriptado da configuração limpa.
Consultar o guia geral Atualização de firmware da Sophos Firewall: preparação e boas práticas, bem como as notas atuais de release, upgrade e Known Issues do SFOS 23. Só depois se deve iniciar o upgrade.

A Sophos confirmou que o upgrade falha quando permanece uma configuração de servidor eDirectory nativo e que esta tem de ser removida antes do SFOS 23. Antes do upgrade em produção, devem também ser consultadas as notas finais de release, upgrade e Known Issues do SFOS 23 para obter mais detalhes.

Problemas comuns

Test connection é bem-sucedido, mas o utilizador fica no grupo errado: Verificar a Base DN, os atributos de início de sessão e de grupo no objeto de utilizador real, bem como a ordem dos grupos.
O teste piloto parece funcionar, mas pode ainda estar a utilizar o eDirectory: Selecionar temporariamente apenas o novo servidor para o serviço piloto controlado e verificar depois o utilizador, o grupo e a política.
O User Portal funciona, mas a VPN não: Verificar separadamente o método de autenticação e o grupo de permissões de cada portal e serviço VPN.
O início de sessão LDAP funciona, mas a identificação transparente não: O SSO nativo do eDirectory deixa de estar disponível a partir do SFOS 23. O LDAP genérico valida o início de sessão, mas não fornece identificação transparente.
Após a alteração do grupo, é aplicada outra regra de firewall: Comparar o grupo efetivo, a ordem dos grupos e as referências diretas a utilizadores ou grupos nas políticas. No Active Directory, verificar também Main Group e outras associações.
O backup é planeado como caminho de reversão posterior para o eDirectory: No SFOS 23, a configuração eDirectory incluída não é migrada; o caminho de reversão tem de funcionar antes do upgrade.