Sophos Firewall: migrar eDirectory antes do SFOS 23

O SFOS 23.0 deixa de suportar o servidor de autenticação eDirectory nativo. Por isso, é necessário migrar para um tipo de autenticação suportado antes do upgrade para o SFOS 23.0 ou posterior. Se permanecer uma configuração de servidor eDirectory na firewall, o upgrade do firmware falha. Um caminho de destino validado é, portanto, um pré-requisito do upgrade; criar apenas um backup da configuração antiga não substitui a migração.

Uma configuração de servidor eDirectory existente gera um alerta no Control center e um banner em Authentication > Servers. Os backups e as importações de configuração podem conter essa configuração, mas o restauro ou a importação não a migra.

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, remover a configuração do servidor eDirectory nativo e o caminho STAS do eDirectory anterior que já não sejam necessários, 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.

Inventariar a automação XML e os documentos antigos de operações eDirectory

O inventário inclui também scripts, integrações e coleções Postman que utilizam o tipo nativo da API XML EdirServer ou se baseiam nas instruções antigas para adicionar, editar ou eliminar um servidor eDirectory. Para cada tarefa, registam-se os responsáveis, o evento de acionamento ou o agendamento, a versão e a build da firewall, o objeto de servidor a que se dirige, a operação de leitura ou escrita e os serviços dependentes. Verificar também os modelos guardados e as tarefas de recuperação executadas com pouca frequência; os segredos permanecem no Secret Store protegido e não são copiados para o inventário.

O catálogo da API XML para SFOS 22 contém a entrada eDirectory nativa e os documentos de operações Add eDirectory server / Edit eDirectory server e Delete eDirectory server. Estas entradas não constam do catálogo do SFOS 23. Isto é evidência documental, não uma prova, testada por nós, da remoção de uma operação da API em tempo de execução, nem uma garantia de um código de erro específico. Por isso, os documentos antigos ou as coleções guardadas não constituem autorização para continuar a enviar esses pedidos no SFOS 23. As entradas para servidores LDAP genéricos continuam presentes no catálogo. Um LDAP server genérico suportado não é removido apenas por consultar o mesmo diretório.

As tarefas afetadas são migradas para o tipo de destino suportado escolhido, e não através da simples alteração do nome EdirServer num payload antigo:

Em API help da build instalada, verificar se e de que forma o objeto de destino e a operação necessária são suportados. As tags do objeto, os atributos, a operação de escrita explícita e o transporte têm de ser compatíveis. O guia Controlar o acesso à API e verificar pedidos XML em segurança explica a autorização das origens, as permissões da conta, os limites de versão e a verificação das respostas. Se o suporte continuar por esclarecer, não executar a tarefa em produção e esclarecer a situação com o suporte.
Documentar os objetos de destino e as associações de grupos e serviços para a tarefa de substituição. Antes da execução piloto controlada, suspender as tarefas de escrita antigas para que não provoquem alterações duplicadas nem voltem a criar uma configuração de servidor nativo já removida. Guardar de forma protegida os modelos salvaguardados, os agendamentos e o estado da configuração necessários para o caminho de reversão.
Na janela de manutenção, testar primeiro uma consulta de leitura suportada e inofensiva e, depois, apenas a pequena alteração autorizada. Comparar a resposta XML e o estado com o objeto real no WebAdmin e com o Audit Trail; uma resposta HTTP de sucesso, por si só, não é suficiente. Testar também, com contas reais, o início de sessão, o grupo efetivo e as políticas afetadas. Só depois desta validação ativar a tarefa de substituição e observar as suas próximas execuções regulares.
Se ocorrerem alterações inesperadas em objetos, grupos ou políticas, suspender a tarefa de substituição e reverter de forma controlada as alterações registadas. Voltar a autorizar a tarefa antiga apenas no caminho SFOS 22 ainda suportado, com a configuração nativa existente e um caminho de reversão validado; não a iniciar no SFOS 23 como solução de emergência. Após o upgrade do firmware, aplicam-se os limites suportados de reversão e restauro descritos mais abaixo. Antes da autorização para eliminação e upgrade, o inventário tem de confirmar que nenhuma tarefa de produção continua a depender do caminho nativo EdirServer ou dos seus documentos antigos de operações.

Documentar a ligação nativa do SFOS 22

O Novell eDirectory é um serviço de diretório compatível com X.500. O tipo de servidor nativo eDirectory continua a funcionar no SFOS 22.0 MR2, mas o limite do SFOS 23 impede a sua utilização como nova arquitetura de destino. Antes da migração deve documentar-se integralmente a ligação existente.

Em Authentication > Servers, abrir o servidor eDirectory existente e documentar pelo menos o seguinte:

Server name, endereço IP do servidor e porta
Bind DN como Distinguished Name completo em sintaxe LDAP e o responsável pelo Password correspondente
Connection security: Simple envia as credenciais sem cifragem; em produção usar SSL/TLS ou STARTTLS
o estado de Validate server certificate e qualquer Client certificate selecionado
Base DN como ponto inicial da pesquisa de utilizadores; Get base DN pode obter o valor disponibilizado pelo servidor
o resultado de Test connection, um login real e o grupo resultante

Um caminho Simple existente é uma falha de segurança, mas não deve ser alterado às cegas durante a migração. DNS, nome do certificado, confiança na CA e a porta TLS prevista devem funcionar primeiro. Test connection confirma apenas ligação e credenciais. Também se registam a seleção e a ordem em Authentication > Services e testa-se um serviço real. A password de Bind e outros segredos não devem constar de screenshots nem da documentação de migração.

O segundo caminho legado é o STAS compatível com eDirectory para a identificação transparente de utilizadores. No SFOS 22, o STAS utiliza Novell eDirectory como Domain Type em General > Monitored Domains e o modo EDIRECTORY em STA Agent. Este caminho não deve ser confundido com a autenticação LDAP encriptada: a porta LDAP segura 636 não é suportada na configuração Novell eDirectory do STAS. O comportamento registado como NCL-1392 não indica versões afetadas ou corrigidas nem uma solução alternativa. STAS para Sophos Firewall descreve o planeamento suportado, a substituição e a validação de ponta a ponta deste caminho de identidade.

O inventário da migração deve, por isso, incluir também os servidores STAS, os grupos de collectors, as redes monitorizadas e os collectors registados na firewall. Um servidor LDAP genérico pode substituir a autenticação de utilizadores, mas não este caminho de identidade STAS transparente. É necessário um método separado e validado antes de retirar o caminho STAS legado.

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 servidor LDAP genérico trata da autenticação, mas não da identificação transparente fornecida pelo caminho STAS do eDirectory anterior. Por isso, os utilizadores anteriormente identificados de forma automática precisam de um fluxo de SSO ou de início de sessão planeado separadamente. 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. Quando se seleciona mais do que um servidor, a firewall encaminha os pedidos pela ordem apresentada. Cada método de autenticação permite selecionar no máximo 20 servidores de autenticação; durante a operação paralela, o servidor antigo e o novo têm de ser planeados dentro deste limite. 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 nem prova que o novo caminho de identidade funciona. Uma reversão após o upgrade de firmware também deve seguir os procedimentos de reversão de firmware e restauro suportados pela Sophos. Por isso, o caminho de reversão do eDirectory deve ser validado antes do upgrade, em vez de se confiar apenas no ficheiro de backup.

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 a configuração do servidor eDirectory nativo que já não é necessária e retirar o caminho STAS do eDirectory anterior. Um LDAP server genérico recém-adicionado que consulta o mesmo diretório permanece configurado.
Verificar em Authentication > Servers, Authentication > Services, na configuração STAS e no inventário que nenhum serviço de produção ainda depende do caminho eDirectory nativo.
Criar um novo backup encriptado da configuração limpa.
Registar a versão de destino e a build exatas e compará-las com os limites de migração descritos aqui e com o guia geral Atualização de firmware da Sophos Firewall: preparação e boas práticas. Só depois se deve iniciar o upgrade.

O servidor de autenticação eDirectory nativo é descontinuado no SFOS 23; antes é necessário migrar para um tipo de autenticação suportado. A autorização para o upgrade em produção deve corresponder sempre à versão de destino e à build exatas.

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 LDAP genérico valida o início de sessão, mas não substitui o caminho de identidade STAS do eDirectory anterior. A identificação transparente deve ser migrada e testada separadamente.
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 é tratado como o único caminho de reversão do eDirectory: Um ficheiro de backup não migra o caminho de identidade nem substitui uma reversão de firmware suportada. A reversão deve ser totalmente documentada e validada antes do upgrade.