Saltar para o conteudo
Avanet

Configurar o Microsoft Entra ID SSO para o WebAdmin do Sophos Firewall

Sophos Firewall

O Microsoft Entra ID SSO no WebAdmin exige quatro definições coerentes: um grupo Entra ou uma função da aplicação, um perfil Device Access local, o Web admin console URL exato como Redirect URI e o servidor Entra em Administrator authentication methods. Só esta cadeia transforma um utilizador autenticado com êxito no Entra num administrador da firewall com as permissões previstas.

Se o ambiente utiliza TACACS+ em vez de OAuth para a administração central de dispositivos, aplica-se o procedimento separado TACACS+ para administradores da Sophos Firewall. Ao contrário do Entra Role Mapping, o TACACS+ não atribui automaticamente o perfil local neste fluxo.

⚠️ Antes da ativação: Mantenha aberta uma sessão de administrador local existente, teste o admin local a partir da rede de gestão e conheça o acesso pela consola ou Device Console. O SSO e o Entra MFA não justificam disponibilizar amplamente o WebAdmin a partir da zona WAN. Enquanto o início de sessão piloto, as permissões ou o acesso local de recuperação não funcionarem, o Entra não deve ter prioridade em produção.

WebAdmin SSO em oito passos

  1. Verificar o FQDN do WebAdmin, DNS, certificado, hora do sistema e acesso restrito a partir da rede de gestão.
  2. Preparar os perfis de administrador necessários em Profiles > Device access.
  3. Criar no Microsoft Entra ID uma aplicação single-tenant dedicada com um administrador piloto, uma função da aplicação ou Security Group e um Client Secret monitorizado.
  4. Criar um servidor do tipo Microsoft Entra ID SSO em Authentication > Servers ou ampliar o servidor existente.
  5. Definir User type como Administrator e mapear as funções ou os grupos Entra para os perfis locais pela ordem correta.
  6. Introduzir o Web admin console URL apresentado pela firewall exatamente como Redirect URI da aplicação Entra e concluir Test connection com êxito.
  7. Ativar o servidor Entra em Authentication > Services > Administrator authentication methods, movê-lo para cima e selecionar Apply.
  8. Numa janela privada do browser, testar separadamente um administrador piloto, um utilizador não mapeado, as permissões efetivas e o fallback local.

A funcionalidade está disponível desde o SFOS 19.5 GA Build 197. O procedimento e as limitações aqui descritos correspondem ao SFOS 22.

O que cada camada controla

O WebAdmin SSO combina vários controlos que podem ser facilmente confundidos:

  • Device Access e Local Service ACL determinam a partir de que redes a consola WebAdmin está acessível.
  • Microsoft Entra ID autentica o utilizador e fornece informações de funções ou grupos no token.
  • O Role mapping na firewall atribui o primeiro valor correspondente do token a um perfil de administrador local.
  • O perfil Device Access determina que menus o administrador não pode utilizar, pode consultar ou pode alterar.
  • Administrator authentication methods ativa o servidor Entra para o início de sessão no WebAdmin.

Uma regra de firewall normal não disponibiliza o WebAdmin. Da mesma forma, uma página de início de sessão acessível ainda não concede permissões de administrador. O artigo Device Access e Local Service ACL no Sophos Firewall explica o acesso seguro a partir da rede.

Se não existir um Role mapping correspondente, a autenticação no Entra ID pode ser bem-sucedida. No entanto, o SFOS cria a conta apenas como utilizador normal e recusa o acesso ao WebAdmin. Não se trata de um erro do browser, mas de uma associação de permissões administrativas em falta.

Grupos Entra ou funções da aplicação

O SFOS suporta ambas as variantes:

  • Os Security Groups são simples quando a organização já gere permissões através de grupos com nomes claros. O nome do grupo tem de corresponder exatamente no mapeamento.
  • As App roles aplicam-se especificamente à aplicação da firewall. O mapeamento utiliza o Value exato da função, e não apenas o nome apresentado.

Para novas integrações administrativas, as funções específicas da aplicação são fáceis de acompanhar. Os Security Groups continuam a ser uma alternativa adequada quando as associações a grupos já são aprovadas, verificadas e documentadas de forma consistente. Os dois modelos não devem ser combinados sem controlo.

O SFOS avalia os mapeamentos de cima para baixo e utiliza a primeira correspondência. As atribuições Full Access e Read-only têm, por isso, de ser mutuamente exclusivas. Se for detetada uma sobreposição, corrigem-se primeiro as atribuições no Entra e voltam a testar-se ambas as funções. A ordem do mapeamento não deve servir como modelo de permissões.

Planear o exemplo e os pré-requisitos

O exemplo seguinte utiliza valores de documentação. Estes devem ser substituídos pelos valores do próprio ambiente:

  • FQDN do WebAdmin: fw01.example.com
  • Aplicação Entra: Sophos Firewall - FW01 - WebAdmin
  • App role Full Access: sfosAdminFull
  • App role Read-only: sfosAdminReadOnly
  • Perfil local Full Access: Administrator
  • Perfil local Read-only: Entra-WebAdmin-ReadOnly

example.com é um domínio reservado para exemplos. O FQDN de produção deve resolver para a firewall correta a partir da rede de gestão e corresponder ao certificado WebAdmin utilizado. Para separar os ciclos de permissões e alterações, a solução mais clara é uma aplicação Entra dedicada com o seu próprio objeto de servidor na firewall para cada integração WebAdmin. É possível partilhar uma aplicação, mas isso associa administradores e utilizadores de VPN e portais às mesmas atribuições da aplicação.

Antes da alteração, devem também estar confirmados os seguintes pontos:

  • Um segundo administrador local ou o admin local funciona independentemente do Entra ID.
  • A palavra-passe, o processo de recuperação e o acesso por consola da conta de emergência estão documentados. Se este caminho ainda não tiver sido verificado, o artigo Recuperar a palavra-passe de administrador do Sophos Firewall ajuda a prepará-lo em segurança.
  • A sessão de administrador existente permanece aberta durante a alteração.
  • A firewall tem a hora correta e alcança os endpoints Microsoft necessários por DNS e HTTPS.
  • O FQDN do WebAdmin utiliza um certificado fidedigno com a cadeia completa.
  • O WebAdmin só está acessível a partir de redes de gestão, por VPN ou de origens especificamente autorizadas.
  • O proprietário e a data de expiração do Client Secret estão documentados.
  • Os utilizadores do mesmo domínio não são sincronizados simultaneamente através de Active Directory e Microsoft Entra ID. Os dois servidores podem existir, mas antes da alteração tem de estar definido que diretório gere estes utilizadores na firewall.

Os artigos Configurar a hora do sistema e NTP e Importar e atribuir certificados ajudam com a hora e os certificados.

Preparar os perfis Device Access

Os perfis são criados antes da mudança para SSO, para que cada valor do Entra aponte imediatamente para permissões definidas. A estrutura geral e a validação segura dos perfis de administrador locais são explicadas em Configurar administradores e perfis Sophos Firewall em segurança; aqui apresenta-se apenas o mapeamento específico do Entra.

Para acesso total, pode ser utilizado o perfil integrado Administrator. Deve ficar limitado ao menor número de pessoas necessário. Para operações, auditoria ou helpdesk, é normalmente preferível um perfil próprio:

  1. Abrir Profiles > Device access.
  2. Selecionar Add.
  3. Introduzir, por exemplo, Entra-WebAdmin-ReadOnly como nome.
  4. Definir Read-only em cada menu necessário.
  5. Manter as áreas desnecessárias como None.
  6. Atribuir Read-write apenas quando a tarefa exigir realmente permissões de escrita.
  7. Guardar o perfil e compará-lo novamente com a função efetiva da equipa.

Um nome Read-only não torna, por si só, o perfil protegido contra escrita. O que conta são as definições None, Read-only e Read-write na matriz de permissões. Os submenus podem ser configurados de forma mais restrita através da função de expansão.

Preparar a aplicação Entra e as funções de administrador

Se já existir uma aplicação Entra bem documentada para VPN ou Captive Portal, o mesmo servidor Entra ID também pode ser utilizado para o WebAdmin. O Redirect URI, as funções de administrador e os testes continuam, ainda assim, a ser específicos de cada serviço. A base comum da aplicação e do servidor é explicada em Entra ID SSO para Sophos Connect e VPN Portal; para utilizadores locais no browser aplica-se o procedimento separado Entra ID SSO para Captive Portal.

Numa aplicação partilhada, todos os grupos autorizados de administradores, VPN e portais têm de ser atribuídos antes de ativar Assignment required e todos os serviços utilizados devem ser testados em seguida. Para permissões administrativas, mudanças de segredo e implementações independentes, uma aplicação WebAdmin dedicada com o seu próprio objeto de servidor Entra é mais fácil de gerir.

Para uma nova integração, a configuração atual da Sophos inclui:

  1. Criar em Microsoft Entra ID > App registrations uma aplicação single-tenant dedicada para a firewall.
  2. Adicionar as permissões delegadas do Microsoft Graph User.Read.All e Group.Read.All.
  3. Para a importação de grupos, adicionar também Group.Read.All como Application Permission.
  4. Conceder Admin Consent para as permissões.
  5. Criar um Client Secret em Certificates & secrets, guardar imediatamente o Value em segurança e monitorizar a data de expiração.
  6. Criar em App roles, por exemplo, sfosAdminReadOnly e apenas quando necessário sfosAdminFull.
  7. Na Enterprise Application associada, em Users and groups, atribuir o administrador piloto ou um grupo piloto controlado à função correspondente.
  8. Numa aplicação WebAdmin dedicada, ativar Assignment required como controlo de acesso adicional e atribuir apenas os administradores piloto ou os grupos de administradores previstos. Trata-se de uma recomendação de segurança da Avanet, não de um requisito técnico do SFOS.

Em vez de App roles, podem ser utilizados Security Groups dedicados, como SFOS-FW01-WebAdmin-Full e SFOS-FW01-WebAdmin-ReadOnly. Grupos gerais de TI ou Microsoft 365 são demasiado abrangentes para permissões de administrador da firewall e dificultam revisões posteriores.

Neste início de sessão, o MFA é imposto pelo Identity Provider. O Sophos Firewall MFA não pode ser aplicado adicionalmente ao mesmo fluxo Entra SSO. Por isso, o Conditional Access deve ser testado especificamente para a aplicação da firewall, e não apenas de forma geral para Microsoft 365. O artigo MFA para Sophos Firewall explica as diferenças em relação ao Sophos OTP.

Configurar o servidor Entra ID na firewall

Em Authentication > Servers, abre-se um servidor Microsoft Entra ID existente ou cria-se um novo com Add > Microsoft Entra ID SSO.

Configurar o servidor e o Redirect URI

  1. Introduzir um Server name inequívoco.
  2. Inserir o Application (client) ID da App Registration.
  3. Inserir o Directory (tenant) ID.
  4. Introduzir o Client secret Value anteriormente guardado.
  5. Escolher conscientemente o Fallback user group. Este controla os serviços de utilizador e não substitui um perfil de administrador.
  6. Em Redirect URI, verificar ou definir manualmente o FQDN do WebAdmin.
  7. Copiar integralmente o Web admin console URL apresentado.

O Redirect URI não deve ser construído manualmente a partir do hostname, da porta e de um suposto caminho de callback. Na aplicação Entra, abra App registrations > [nome da aplicação] > Authentication > Add a platform > Web e adicione exatamente o URL apresentado pelo SFOS.

Se uma única firewall for configurada através do Sophos Central, o hostname da firewall tem de ser definido manualmente. O URL Central Reverse SSO apresentado automaticamente não é o WebAdmin Redirect URI da appliance.

Em seguida, execute Test connection. O teste verifica a ligação de rede, as permissões da aplicação e a validação do certificado TLS. Enquanto falhar, a autenticação dos administradores não deve ser alterada.

Mapear funções ou grupos para perfis

  1. Definir User type como Administrator. A definição User ativa apenas serviços de utilizador e não é suficiente para o WebAdmin.
  2. Em Role mapping, selecionar o Identifier type:
    • Roles para o App Role Value exato, por exemplo sfosAdminReadOnly;
    • Groups para o nome exato do grupo Entra.
  3. Em Value, introduzir o valor da função ou o nome do grupo sem alterações.
  4. Em Profile, selecionar o perfil local, por exemplo Entra-WebAdmin-ReadOnly.
  5. Adicionar outros mapeamentos e verificar conscientemente a ordem.
  6. Guardar.

Os mapeamentos são avaliados de cima para baixo e aplica-se a primeira correspondência. As associações a sfosAdminFull e sfosAdminReadOnly têm, por isso, de ser mutuamente exclusivas. Perante uma associação dupla, corrige-se primeiro a atribuição no Entra e volta a testar-se o piloto, em vez de utilizar a ordem como regra de permissões. A ordem da lista deve, ainda assim, ser documentada, pois determina o perfil aplicado sempre que houver uma correspondência múltipla inesperada.

Ativar o Entra SSO para administradores

O servidor Entra ID só se torna um método de início de sessão no WebAdmin depois de ser atribuído ao serviço de administradores:

  1. Abrir Authentication > Services.
  2. Aceder a Administrator authentication methods.
  3. Selecionar o servidor Microsoft Entra ID.
  4. Mover o servidor para cima na lista.
  5. Manter a autenticação local existente como fallback deliberado para administradores locais.
  6. Selecionar Apply.

Só pode ser selecionado um servidor Microsoft Entra ID por método de autenticação. As definições em Administrator authentication methods não se aplicam ao superadministrador predefinido admin. Esta conta continua, portanto, a ser um acesso de emergência local e não é substituída por um mapeamento de funções Entra.

Testar o início de sessão e as permissões em segurança

Um diálogo Entra bem-sucedido não constitui, por si só, um teste aprovado. A firewall tem de aplicar o perfil correto, recusar um utilizador não autorizado e continuar a oferecer uma forma de acesso local.

Teste positivo com administradores piloto

  1. Manter aberta a sessão de administrador local existente.
  2. Abrir o FQDN WebAdmin documentado numa janela privada do browser.
  3. Iniciar sessão através do Entra ID com o administrador piloto Read-only.
  4. Concluir o Entra MFA e o Conditional Access conforme planeado.
  5. Verificar se apenas os menus autorizados estão visíveis e se as ações de escrita estão realmente indisponíveis.
  6. Em Authentication > Users, confirmar que a conta foi criada como administrador com o perfil esperado.
  7. Se for necessário Full Access, testar um administrador piloto separado com a função Full Access.

O teste Full Access não é realizado com a mesma conta que deve receber simultaneamente Read-only. Duas contas de teste distintas mostram se as funções, a ordem dos mapeamentos e os perfis locais estão realmente separados.

Teste negativo e de fallback

  • Um utilizador não atribuído à Enterprise Application não pode concluir com êxito o fluxo SSO.
  • Um utilizador atribuído mas não mapeado não pode obter acesso ao WebAdmin.
  • Um administrador Read-only não pode guardar alterações à configuração.
  • O admin local tem de continuar a funcionar a partir da rede de gestão prevista.
  • O acesso a partir de uma rede não autorizada tem de falhar logo em Device Access ou Local Service ACL.

Se o teste negativo conceder acesso, a atribuição, a associação ao grupo ou a ordem dos mapeamentos não está correta. A fase piloto deve então permanecer parada; o problema não é contornado com uma função mais abrangente ou uma autorização WAN.

Operação, remoção de permissões e HA

O Entra SSO transfere a identidade e o MFA para o Identity Provider. As permissões de administrador efetivamente aplicadas localmente continuam a ter de ser controladas na firewall.

Concluir conscientemente as alterações de função

Quando um utilizador Entra se torna administrador da firewall, o SFOS aplica a alteração no início de sessão seguinte. O processo inverso não é automático: se um administrador for rebaixado no Entra para utilizador normal, o objeto de administrador local permanece inicialmente na firewall.

Procedimento seguro para uma despromoção:

  1. Confirmar um segundo administrador local e o caminho de recuperação.
  2. Remover a função ou o grupo de administrador no Entra ou ajustar a atribuição da aplicação.
  3. Em Authentication > Users, eliminar de forma controlada o objeto de administrador local em causa.
  4. Só permitir um novo início de sessão se o utilizador continuar a necessitar de serviços de utilizador. O SFOS volta a criar a conta como utilizador com base no token atual.
  5. Testar negativamente um novo início de sessão no WebAdmin e não assumir que as sessões existentes foram terminadas automaticamente.

Se a conta deixar de poder utilizar qualquer serviço da firewall, não deve ser novamente atribuída. A remoção de um grupo, por si só, não deve ser documentada como revogação imediata de permissões de administrador locais já ativas.

Monitorizar o segredo, os logs e as alterações

  • Monitorizar a data de expiração do Client Secret, com proprietário e antecedência definida.
  • Verificar os Entra Sign-in Logs por aplicação, utilizador, MFA e Conditional Access.
  • Utilizar oauth_sso_webadmin.log na firewall para analisar o fluxo WebAdmin SSO.
  • Acompanhar alterações de administradores, perfis e autenticação no Audit Trail.
  • Rever regularmente e em conjunto os grupos de administradores, App roles e perfis Device Access.

Na Advanced Shell, o seguinte comando apenas de leitura apresenta as últimas entradas do serviço WebAdmin SSO:

tail -n 200 /log/oauth_sso_webadmin.log

A associação geral dos ficheiros de log e as formas seguras de leitura estão descritas em Serviços e logs do Sophos Firewall.

Planear a limitação de HA

Num cluster HA, o Entra ID SSO não funciona atualmente para o WebAdmin do dispositivo Auxiliary. O acesso direto ao peer, a recuperação e a manutenção necessitam, por isso, de um procedimento local. Um mapeamento Entra para HAProfile não elimina esta limitação do produto.

Antes de um teste HA, são documentados ambos os caminhos de gestão, as credenciais locais e as funções. Depois de uma alteração de função, voltam a ser verificados separadamente o acesso ao Primary, a gestão local do peer e o SSO.

Resolução de problemas

O início de sessão Entra funciona, mas o WebAdmin recusa o acesso

Normalmente, falta um mapeamento de administrador adequado. Verificar User type: Administrator, o Identifier Type, o valor exato da função ou o nome do grupo e o perfil atribuído. Uma conta criada como utilizador normal em Authentication > Users mostra que nenhum mapeamento de administrador correspondeu.

O administrador recebe o perfil errado

O Role mapping é avaliado de cima para baixo. Verificar as associações a grupos e App roles da conta, remover atribuições duplicadas e voltar a testar a ordem com um novo início de sessão. Não tornar simplesmente o perfil restritivo mais permissivo.

O Redirect termina numa página de erro

Comparar, caráter a caráter, o Web admin console URL da firewall com o Redirect URI em App registrations > Authentication > Web. O FQDN, a porta, o caminho, o DNS e o certificado WebAdmin fazem parte do mesmo teste. Numa configuração através do Central, não utilizar o URL Reverse SSO.

Test connection falha

Verificar a acessibilidade de login.microsoftonline.com e graph.microsoft.com, DNS, hora do sistema, Tenant ID, Client ID, Client Secret, permissões do Microsoft Graph e Admin Consent. Um Redirect URI novo não corrige um segredo expirado.

Se oauth_sso_webadmin.log apresentar x509: certificate signed by unknown authority, poderá faltar uma Root CA ou Intermediate CA para a cadeia de certificados Microsoft efetivamente apresentada. A cadeia vista pela firewall é lida na respetiva Advanced Shell:

openssl s_client -connect login.microsoftonline.com:443 -showcerts

Um computador de teste pode servir para comparação, mas não prova que cadeia é vista pela própria firewall. Importar apenas uma CA comprovadamente em falta e proveniente de uma origem fidedigna. Não utilizar um certificado de servidor como CA nem reiniciar um serviço SSO como primeiro passo de resolução do problema.

O SSO funciona no Primary, mas não no Auxiliary

Trata-se de uma limitação de HA documentada. O WebAdmin do Auxiliary requer acesso local testado. Uma nova função Entra, uma autorização Device Access mais ampla ou outro Redirect URI não eliminam esta limitação.

Lista de verificação

  • O admin local, um segundo administrador e o acesso por consola funcionam.
  • O WebAdmin só está acessível a partir das redes de gestão ou origens previstas.
  • O FQDN, DNS, certificado e hora do sistema estão corretos.
  • A App Registration, as permissões, o Admin Consent e a expiração do segredo estão documentados.
  • Numa aplicação WebAdmin dedicada, Assignment required está ativo e só o grupo de administradores piloto está atribuído; numa aplicação partilhada, todos os grupos autorizados de administradores, VPN e portais estão incluídos e testados.
  • Os perfis Device Access contêm as permissões pretendidas.
  • User type: Administrator e o Role mapping estão ordenados corretamente.
  • O Web admin console URL exato está introduzido como Entra Redirect URI.
  • Test connection é concluído com êxito.
  • O Entra está ativo em Administrator authentication methods.
  • Os testes Read-only, Full Access, negativo e de fallback local foram aprovados.
  • Os Entra Sign-in Logs e oauth_sso_webadmin.log foram verificados.
  • A remoção de funções, a mudança do segredo e a limitação de HA estão documentadas operacionalmente.