Configurar o Microsoft Entra ID SSO para o Sophos Firewall Captive Portal

Com o SSO Microsoft Entra ID para Captive Portal, o Sophos Firewall pode autenticar utilizadores no Microsoft Entra ID através do browser antes que as regras de firewall baseadas no utilizador entrem em vigor. Isto é particularmente interessante para redes BYOD, zonas de convidados ou parceiros, dispositivos sem deteção transparente de AD ou ambientes onde o STAS não se adapta a todos os clientes.

É importante diferenciar: Captive Portal não é VPN Portal nem Remote Access. O utilizador já está na rede local ou Wi-Fi e autentica-se no navegador para que a firewall possa associar o tráfego seguinte a uma identidade de utilizador. Para acesso remoto com Sophos Connect, o artigo separado Configurar Microsoft Entra ID SSO para Sophos Connect e Portal VPN é o adequado.

Se o Microsoft Entra ID SSO já estiver configurado para VPN Portal ou Sophos Connect, não é automaticamente necessário criar um desenho Entra completamente novo. Em muitos casos, pode reutilizar-se o mesmo objeto de servidor Microsoft Entra ID na firewall. O Captive Portal continua a precisar da Captive portal URL correta como Redirect URI, da atribuição em Authentication > Services e de um teste separado da regra de utilizador posterior.

Quando o Portal Cativo com Entra ID SSO faz sentido

O portal cativo com SSO do Entra ID faz sentido se os utilizadores fizerem login no Microsoft 365 de qualquer maneira e o firewall precisar de uma identidade de utilizador para determinadas redes.

Aplicações típicas:

• Redes BYOD ou WiFi sem adesão ao domínio.
• Convidados ou utilizadores externos com acesso controlado a alguns destinos.
• Regras de Internet baseadas no utilizador sem STAS ou SATC.
• Redes onde a autenticação transparente não é fiável.
• Cenários de transição onde a autenticação local do AD deve ser reduzida.

Para clientes Windows totalmente geridos num domínio clássico, o Captive Portal não é automaticamente a melhor solução. Nesse caso, STAS, AD SSO ou outros procedimentos transparentes podem ser mais ergonómicos, porque os utilizadores não precisam de iniciar ativamente um login no browser. O Captive Portal é sobretudo uma solução alternativa ou específica para dispositivos não geridos.

Portal cativo separado, portal VPN e portal do utilizador

Com o Entra ID SSO, os termos do portal são rapidamente confundidos. A separação é crucial para a configuração.

• Captive Portal: Os utilizadores da rede local iniciam sessão no browser para que sejam aplicadas as regras baseadas na identidade. O Entra ID SSO é utilizado para o login no browser e a associação do utilizador.
• Portal VPN: Os utilizadores de acesso remoto descarregam o Sophos Connect ou configurações VPN. O Entra ID SSO é utilizado aqui para o acesso remoto e o login no portal.
• Portal do utilizador: Este portal contém funções para o utilizador, como OTP ou opções pessoais mais antigas. Consoante o ambiente, pode continuar a ser relevante para tokens ou opções do utilizador.

Uma visão geral dos portais está disponível em Portais Sophos: SophosID, Central, Suporte e acesso ao firewall. No Captive Portal, deve verificar-se sobretudo a partir de que zona de origem o serviço local da firewall pode ser alcançado e qual regra de firewall processa depois o tráfego real do utilizador. A configuração clássica sem o processo específico da Microsoft é explicada em Configurar e testar o Sophos Firewall Captive Portal, desde o Device Access e DNS até à regra de utilizador e Live users. Para o Entra ID SSO, acrescentam-se depois o registo da aplicação, o Redirect URI e as verificações OAuth/OIDC deste artigo.

Requisitos

Antes da configuração, estes pontos devem ser esclarecidos:

• Sophos Firewall com uma versão SFOS compatível com Microsoft Entra ID SSO.
• Um tenant comercial do Microsoft Entra. A Sophos Firewall não suporta esta integração SSO para tenants Microsoft 365 GCC High.
• Inquilino do Microsoft Entra com permissão para registo de aplicações, URIs de redirecionamento, permissões de API, consentimento de administrador e segredo do cliente.
• FQDN e certificado para o portal cativo para que os utilizadores não vejam avisos desnecessários do navegador.
• Acessibilidade dos pontos de extremidade de login da Microsoft na rede do cliente afetado.
• O Captive Portal é permitido em Administration > Device access para a zona correta.
• Os utilizadores ou grupos são mantidos de forma limpa no Microsoft Entra ID.
• As regras de firewall usam os utilizadores ou grupos esperados.
• Um utilizador de teste e acesso alternativo estão disponíveis.
• O horário e o NTP no firewall e nos clientes estão corretos porque o OAuth/OIDC depende do tempo.
• Se Atribuição necessária estiver ativa no Microsoft Entra ID, os utilizadores ou grupos necessários serão atribuídos à Aplicação Empresarial.

⚠️ O Captive Portal é uma área de login na firewall. Só deverá estar acessível nas zonas onde for realmente necessário. O acesso ao dispositivo e a ACL de serviço local são controlos de segurança, não apenas configurações de ligação.

Proteger o acesso à Sophos Firewall: configurar corretamente o acesso ao dispositivo é adequado para reforçar os serviços locais da firewall. Neste design, o MFA é implementado no Microsoft Entra ID, por exemplo, através do Acesso Condicional. O MFA local da Sophos Firewall não substitui o fator de login da Microsoft com Entra ID SSO. Geralmente, isto é melhor do ponto de vista do utilizador, porque é utilizado o mesmo MFA do Microsoft 365, mas deve ser cuidadosamente planeado e testado no inquilino.

Planear a arquitetura antes da configuração

Antes da configuração técnica, deve decidir qual tarefa o portal cativo deve resolver especificamente. Caso contrário, rapidamente terá um login que funciona, mas não aciona uma regra de firewall adequada.

Questões importantes de design:

• Qual zona usa o Portal Cativo?: O acesso ao dispositivo e a origem da regra dependem da zona.
• Qual grupo de utilizadores tem permissão para fazer login?: O grupo Entra deve corresponder à regra de firewall posterior.
• Quais objetivos podem ser alcançados após o login?: O portal cativo não substitui a segmentação limpa.
• Por quanto tempo as sessões devem ser válidas?: Sessões muito longas diluem a alocação de utilizadores e sessões muito curtas interrompem as operações.
• O que acontece em caso de interrupção da Entra ou da Internet?: É necessário que haja uma alternativa clara para trabalhos críticos.
• Como o login é acionado?: Os utilizadores precisam de um URL de portal cativo acessível ou de um redirecionamento limpo.

O Captive Portal não deve ser usado como substituto de VLANs, zonas ou regras mínimas de firewall. O firewall conhece melhor o utilizador após o login, mas a arquitetura da rede ainda deve permanecer limpa. Configurar zonas e interfaces do Sophos Firewall é adequado para a lógica básica de zonas.

Criar servidor Microsoft Entra ID

A configuração consiste em duas partes: Primeiro, é preparado um registo da aplicação no Microsoft Entra ID. Esta aplicação é então registada como um servidor de autenticação no firewall Sophos.

Preparar o registo da aplicação no Microsoft Entra ID

Um registo de aplicação separado para o firewall deve ser criado no Microsoft Entra ID. Isso significa que URIs de redirecionamento, permissões e segredos do cliente permanecem claramente separados de outras aplicações.

Processo típico:

1. Abra o centro de administração do Microsoft Entra.
2. Abra Registos de aplicações > Novo registo.
3. Dar um nome descritivo, por exemplo Sophos-Firewall-SSO.
4. Como regra, selecione o próprio inquilino como tipo de conta compatível.
5. Use a plataforma Web.
6. Anote ID da aplicação (cliente) e ID do diretório (inquilino).
7. Crie um segredo do cliente em Certificados e segredos e guarde imediatamente o respetivo valor em segurança.
8. Em API permissions > Microsoft Graph > Delegated permissions, adicione User.Read.All e Group.Read.All.
9. Apenas se pretender importar grupos com o assistente da firewall, adicione também Group.Read.All em Application permissions.
10. Execute Grant admin consent para estas permissões.
11. Em Enterprise applications > [aplicação da firewall] > Properties, defina preferencialmente Assignment required? como Yes e atribua apenas os utilizadores ou grupos autorizados.

Sem as permissões API e o consentimento de administrador corretos, a firewall não consegue processar devidamente utilizadores ou grupos após o login Microsoft. Se Assignment required? ficar em No, todos os utilizadores do tenant podem tentar iniciar sessão nos serviços de utilizador da firewall; os grupos, policies e regras da firewall continuam a determinar o acesso real. A atribuição obrigatória reduz, portanto, a superfície de login, mas não substitui uma autorização restritiva na firewall.

Segundo a Microsoft, a atribuição através de grupos requer Entra ID P1 ou P2 e não inclui grupos aninhados. Por isso, teste com um membro direto do grupo e não apenas com um utilizador de um subgrupo.

Criar ou reutilizar o servidor Entra ID na Sophos Firewall

A Microsoft documenta separadamente o App Registration, os Redirect URIs, as atribuições da aplicação e o Conditional Access. Consulte estas fontes primárias se os rótulos ou requisitos do tenant mudarem no portal Entra.

Direcione o Conditional Access para a Enterprise Application e avalie primeiro a política no modo Report-only com um utilizador piloto. Antes de a ativar, verifique o resultado com What If e os registos de início de sessão do Entra e exclua as contas de acesso de emergência documentadas. Mantenha aberta uma sessão de administração da firewall e disponível o método de autenticação anterior até testar com êxito um utilizador permitido, um recusado e o MFA, evitando assim um bloqueio causado por uma política incorreta.

O caminho do menu no Sophos Firewall é:

Authentication > Servers

Processo básico:

1. Abra Add.
2. Selecione Microsoft Entra ID SSO como Server type.
3. Atribuir um nome descritivo, por exemplo Entra-SSO-Firewall.
4. Introduza o Application (client) ID da aplicação Entra.
5. Introduza o Directory (tenant) ID.
6. Introduza Client secret.
7. Defina conscientemente o Fallback user group e mantenha-o o mais restritivo possível.
8. Execute Test connection.
9. Guarde.

O grupo de fallback aplica-se quando o grupo Entra de um utilizador não existe na firewall. Não deve receber acesso amplo e não constitui acesso de emergência nem autenticação alternativa durante uma falha do Entra.

Em Redirect URI, indique o FQDN ou endereço IP de produção; a firewall gera os URLs de serviço que devem ser copiados sem alterações para o Entra ID. Test connection verifica a conectividade de rede, as Application permissions e a validação do certificado TLS.

⚠️ Client secrets são dados de acesso produtivos. Data de expiração, rotação e responsabilidade devem ser documentadas. Um secret expirado muitas vezes parece um problema normal de login para o utilizador, mas na verdade é um problema de configuração ou operação.

Para uma rotação com pouca interrupção, crie um novo secret antes da expiração, introduza a respetiva Value na firewall e execute Test connection, seguido de um login no Captive Portal. Mantenha o secret anterior válido como retorno até ambos os testes serem bem-sucedidos e só depois o elimine no Entra ID. Nunca inclua valores de secrets em capturas de ecrã, tickets ou exportações de configuração.

Insira URIs de redirecionamento corretamente

Copie sem alterações para a App Registration do Microsoft Entra ID o URI de redirecionamento gerado pela firewall. O protocolo, nome do host, porta, caminho e até a barra final têm de coincidir exatamente. O certificado do portal não faz parte do URI, mas deve ser válido para o mesmo nome do host e ser considerado fidedigno pelos clientes.

O Sophos Firewall apresenta os URLs de serviço necessários no servidor Entra ID. O URL do Captive Portal é particularmente relevante para este artigo. Se WebAdmin ou Remote Access com Entra ID SSO também forem utilizados, estes serviços terão URLs próprios:

• URL da consola de administração Web: Entra ID SSO para WebAdmin Console.
• URL do portal cativo: Entra ID SSO para Portal Cativo na rede local.
• Portal VPN e URL de acesso remoto: Entra ID SSO para Portal VPN e Sophos Connect.

Se o mesmo servidor Entra ID já for usado para Remote Access, adicionar a Captive portal URL às Redirect URIs existentes na aplicação Entra. O Captive Portal deve ainda assim ser testado separadamente, porque o caminho de login, Device Access, a correspondência de grupos e a regra firewall posterior têm erros típicos diferentes de Sophos Connect ou VPN Portal.

Definir método de autenticação do portal cativo

Depois de criar o servidor Entra, o método de autenticação do Captive Portal deve apontar para o servidor correto.

A área relevante está em:

Authentication > Services

Para verificar:

1. Abra a área Firewall authentication methods.
2. Adicione ou arraste o servidor Microsoft Entra ID para a posição correta.
3. Mantenha outros servidores de autenticação apenas se eles servirem como alternativa deliberada.
4. Aplique a alteração com Aplicar.
5. Faça um login de teste com um único utilizador.

A Sophos Firewall permite apenas um servidor Microsoft Entra ID por método de autenticação. Por isso, não é possível acumular vários tenants ou aplicações Entra na mesma lista Firewall authentication methods.

Se vários métodos de autenticação estiverem ativos em paralelo, deve ficar claro qual servidor é responsável por qual grupo de utilizadores. Para o mesmo utilizador deve ser usada, sempre que possível, apenas uma fonte de autenticação. Numa versão de firmware afetada por NC-167128, a firewall pode rejeitar a sessão com no permission se um utilizador mudar do Entra ID SSO para o login no AD local e depois reutilizar um token Entra anterior. Este funcionamento misto é mais difícil de testar e só deve ser utilizado e documentado de forma consciente.

Além disso, deve verificar em Authentication > Web authentication como o Captive Portal é aberto no navegador. HTTPS é importante para o Entra ID SSO. A opção Use insecure HTTP instead of HTTPS não deve ser ativada porque o fluxo Entra-OAuth sobre HTTP não é suportado adequadamente e seria desnecessariamente inseguro.

O seguinte é útil para a operação:

1. Abra o Captive Portal numa nova janela do browser.
2. Mantenha a janela do portal cativo aberta durante a sessão.
3. Faça com que os utilizadores saiam conscientemente através do portal cativo se a associação for encerrada.
4. Após fazer login, verifique em Current activities > Live users se o utilizador está visível.

As opções de logout automático por inatividade ou ao fechar o separador do navegador não se aplicam atualmente ao Microsoft Entra ID SSO. Em dispositivos partilhados, a janela do portal permanece, por isso, aberta até o utilizador terminar explicitamente a sessão; fechar o separador não é considerado um fim de sessão fiável.

Dependendo da interface e do certificado, a URL padrão https://<Firewall-IP>:8090 também pode ajudar nos testes. Um FQDN limpo com um certificado adequado é muito mais agradável para uma operação produtiva.

Verifique o acesso ao dispositivo e a acessibilidade do portal

Captive Portal é um serviço local da firewall. Uma regra de firewall normal por si só não permite esse acesso. A acessibilidade é controlada em Administration > Device access para a respetiva zona.

Deve verificar:

• O portal cativo só é permitido nas zonas obrigatórias.
• Isso significa que WebAdmin e SSH não são acidentalmente também amplamente acessíveis.
• O certificado e o FQDN correspondem ao URL do utilizador.
• O DNS na rede do cliente resolve o nome do portal corretamente.
• Regras de exceção de ACL de serviço local só são definidas quando são realmente necessárias.

Se o Portal Cativo não estiver acessível a partir de uma rede, não deverá criar primeiro uma regra de Permissão normal. A causa geralmente é acesso ao dispositivo, ACL de serviço local, DNS, certificado ou mapeamento de zona incorreto.

Considerar o login da Microsoft e o filtro Web

O cliente deve aceder às páginas de login da Microsoft e aos recursos relacionados durante o login. Caso contrário, em redes restritivas, o fluxo SSO pode parar num ponto que parece aos utilizadores um erro da firewall ou do browser.

Para verificar:

• A resolução DNS para domínios de login da Microsoft funciona.
• HTTPS para pontos de extremidade de login da Microsoft é permitido.
• Filtro Web, inspeção TLS ou proxy não bloqueiam a página de login.
• O tempo no firewall e no cliente é plausível.
• Os cookies do navegador não são inutilizados por uma política rigorosa.

Em ambientes restritivos, configure como hosts FQDN a lista completa documentada pela Sophos para o SFOS 22, em vez de a deduzir de alguns pedidos observados:

• *.aadcdn.microsoftonline-p.com
• *.login.live.com
• login.microsoftonline.com
• *.login.microsoftonline.com
• *.logincdn.msftauth.net
• *.microsoftonline-p.com
• *.microsoftonline.com
• *.msauth.net
• aadcdn.msftauth.net
• login.microsoft.com
• account.activedirectory.windowsazure.com
• *.aadcdn.msauthimages.net
• *.aadcdn.msftauthimages.net
• *.aadcdn.msftauth.net
• browser.events.data.msn.com
• ent-nfc-api.msn.com
• img-s-msn-com.akamaized.net
• ntp.msn.com
• edge-consumer-static.azureedge.net
• msedge.b.tlu.dl.delivery.mp.microsoft.com

Crie explicitamente os objetos e a regra no SFOS:

1. Aceda a Hosts and services > FQDN host e selecione Add. Para cada entrada acima, indique um Name exclusivo, introduza o valor listado em FQDN e guarde o objeto.
2. Aceda a Hosts and services > FQDN host group e selecione Add. Indique um Name, utilize Add new item, adicione como membros todos os hosts FQDN criados no passo 1 e guarde o grupo.
3. Aceda a Rules and policies > Firewall rules > IPv4, selecione Add firewall rule > New firewall rule e defina Action como Accept. Limite Source zones e Source networks and devices ao segmento de cliente afetado, defina Destination zones como WAN, selecione o grupo de hosts FQDN em Destination networks e apenas DNS e HTTPS em Services. Coloque a regra na posição necessária, ative Log firewall traffic e restrinja utilizadores, horário, origem e destino tanto quanto o fluxo de início de sessão permitir.

Depois de guardar, confirme que cada host FQDN resolve endereços atuais e que o grupo contém todos os 20 objetos. Inicie uma sessão de teste a partir da rede de clientes delimitada e verifique se o contador de correspondências da regra aumenta e se o respetivo Rule ID e a ação Accept aparecem no Log Viewer. Se o contador permanecer em 0, verifique a resolução e associação dos objetos, zona/rede de origem, zona de destino, serviços e ordem das regras antes de alargar a regra. O modo Direct Web Proxy requer ainda exceções URL com expressões regulares; a lista FQDN, por si só, não as substitui.

Se o filtro da web, um proxy ou inspeção TLS entrar em vigor antes do login, esses alvos não deverão ser descriptografados ou bloqueados desnecessariamente.

Criar a exceção do Direct Web Proxy

Para o Direct Web Proxy, crie a exceção correspondente conforme descrito em Exceções Web:

Sobre a origem dos padrões: Esta lista é um exemplo adaptado com base na documentação da Sophos para o SFOS 22, não uma reprodução literal de todos os padrões. Nessa documentação, o oitavo padrão, para msauth.net, aparece como ^([A-Za-z0-9.-]*\.)?.msauth.net\.?/ (citação da fonte, não recomendada como modelo para copiar). Aqui mantém-se, em vez disso, ^([A-Za-z0-9.-]*\.)?msauth\.net\.?/: a adaptação local remove o ponto adicional não escapado antes de msauth e escapa o ponto entre msauth e net. Na sintaxe regex habitual, um ponto não escapado representa normalmente qualquer caráter exceto uma quebra de linha, enquanto \. representa um ponto literal. Isto explica apenas a sintaxe; não constitui uma correção confirmada pelo fabricante nem comprova compatibilidade testada com o motor regex da Sophos. Os restantes 13 padrões permanecem inalterados. Antes da utilização em produção, os padrões têm de ser verificados na versão do SFOS em utilização, com um login Entra permitido e um URL que não corresponda aos padrões; se o comportamento não for claro, peça primeiro esclarecimentos à Sophos, em vez de adotar sem verificação o padrão da fonte que suscita dúvidas.

1. Abra Web > Exceptions e selecione Add.
2. Introduza um nome descritivo e selecione URL pattern matches.
3. Utilize Search e Add para cada um dos seguintes 14 padrões regex deste exemplo adaptado:

• login\.microsoftonline\.com\.?/
• ^([A-Za-z0-9.-]*\.)?login.live.com\.?/
• aadcdn\.msftauth.net\.?/
• ^([A-Za-z0-9.-]*\.)?aadcdn\.microsoftonline-p\.com\.?/
• ^([A-Za-z0-9.-]*\.)?login.microsoftonline.com\.?/
• ^([A-Za-z0-9.-]*\.)?logincdn.msftauth.net\.?/
• ^([A-Za-z0-9.-]*\.)?aadcdn.msauthimages.net\.?/
• ^([A-Za-z0-9.-]*\.)?msauth\.net\.?/
• ^([A-Za-z0-9.-]*\.)?aadcdn.msftauthimages.net\.?/
• ^([A-Za-z0-9.-]*\.)?microsoftonline\.com\.?/
• ^([A-Za-z0-9.-]*\.)?microsoftonline-p.com\.?/
• ^([A-Za-z0-9.-]*\.)?aadcdn.msftauth.net\.?/
• ^([A-Za-z0-9.-]*\.)?account.activedirectory.windowsazure.com\.?/
• login\.microsoft\.com\.?/

4. Selecione todos os checks e actions para estes padrões.
5. Guarde a exceção.

Confirme que a Web Exception guardada está ativada. Durante um início de sessão de teste, verifique nos registos web/proxy se o URL Microsoft solicitado corresponde ao padrão pretendido e se a exceção é aplicada; caso contrário, compare caráter a caráter o nome do host e o caminho registados com a expressão regular de uma única barra invertida e verifique o âmbito e a ordem da exceção.

Limite a exceção tanto quanto possível às redes dos clientes e ao fluxo de login Entra; não a transforme numa exceção geral para serviços Microsoft. Valide ambos os sentidos: um login Entra permitido deve ser concluído, enquanto um URL Microsoft não relacionado que não corresponda aos padrões deve continuar a seguir a política Web e TLS normal. Se esse teste negativo também for isento, reduza o âmbito antes da implementação.

Se a Proteção Web ou Inspeção TLS estiver ativa, o login com um utilizador de teste deverá ser observado no visualizador de log. Às vezes, o problema não é o Portal Cativo em si, mas uma política web, uma exceção TLS ou uma rede de cliente que não atinge totalmente os pontos finais da Microsoft.

Teste grupos de utilizadores e regras de firewall

Após um login bem-sucedido no portal cativo, a regra de firewall real deverá ver o utilizador ou grupo no tráfego. Este é o teste prático mais importante.

Processo típico:

1. Verifique os utilizadores no Microsoft Entra ID.
2. Compare UPN, endereço de e-mail e associação ao grupo.
3. Verifique o grupo Entra no Sophos Firewall.
4. Ative Match known users e Use web authentication for unknown users na regra de utilizador.
5. Faça login no portal cativo com utilizador de teste.
6. Em seguida, acione o tráfego real do utilizador, por exemplo, HTTPS para um destino permitido.
7. No Log Viewer, verifique se o utilizador, grupo, zona de origem, rede de origem e ID da regra correspondem à regra esperada.

Um login bem-sucedido no navegador apenas comprova a autenticação. Isso não prova que a regra do utilizador posterior se aplica. Se o contador de regras permanecer em 0 ou nenhum utilizador estiver visível no visualizador de log, deverá usar o fluxo de A regra do Sophos Firewall não funciona: verifique as causas.

Correspondência de grupos e limitação anterior de Primary Group

Para regras de utilizador, o grupo Entra pretendido tem de estar presente na firewall. Após o login, verificar em Current activities > Live users e no Log Viewer a que grupo o utilizador foi associado e que Rule ID processa o tráfego.

Na SFOS 20.0 GA Build 222 existia uma limitação conhecida: com NC-167130, o acesso à Internet através de um grupo Entra secundário não funcionava; a regra tinha de conter o Primary Group ou o utilizador individual. A Sophos indica SFOS 21.5 MR2 Build 323 e SFOS 22.0 MR1 Build 490 como versões corrigidas. Nos builds atuais, o Primary Group já não é um requisito geral de design.

Antes de uma implementação, deve registar o seguinte para cada utilizador de teste:

• Grupo Entra: O grupo de destino e a associação do utilizador são conhecidos.
• Grupo no Firewall Sophos: O mesmo grupo é importado ou mapeado corretamente.
• Regra de firewall: O grupo pretendido está incluído na condição de utilizador ou grupo.
• Tráfego de teste após o login: O Log Viewer mostra o utilizador, o grupo, a Rule ID e a ação esperada.
• Build anterior afetado: Utilizar o Primary Group ou uma regra de teste específica para o utilizador e planear a atualização.

Isso não afeta o Sophos Connect VPN com Microsoft Entra ID SSO. Para acesso remoto, o processo separado para Microsoft Entra ID SSO para Sophos Connect e Portal VPN deve, portanto, ser verificado.

Validação após implementação

Para a validação, não basta verificar se aparece a página de login da Microsoft.

• Abrir o URL do Captive Portal a partir da rede do cliente: O browser apresenta o login Entra esperado ou o redirecionamento da Sophos.
• Login com utilizador permitido: Login bem-sucedido, utilizador aparece no firewall.
• Login com utilizador não permitido: O acesso é negado de forma compreensível.
• Teste da regra de grupo: O utilizador de teste corresponde à regra de utilizador esperada.
• Tráfego de utilizadores após login: regra de firewall correta correspondente à referência do utilizador.
• Fluxo da sessão: Após um tempo limite, é necessário fazer login novamente.
• Login da Microsoft bloqueado: O visualizador de logs ou os logs da web mostram um motivo compreensível.
• Cenário alternativo: Teste o método de autenticação anterior documentado; o Fallback user group por si só não autentica utilizadores durante uma falha do Entra.

Especialmente em redes BYOD, deve testar com vários browsers e dispositivos. Modos de navegação privada, cookies de terceiros bloqueados, logins antigos guardados ou várias contas Microsoft no mesmo dispositivo podem produzir resultados diferentes.

Reposição segura

Antes das alterações, registe a ordem em Authentication > Services > Firewall authentication methods, as definições em Authentication > Web authentication e as regras de firewall afetadas. Uma captura de ecrã ou exportação da configuração evita ter de reconstruir o estado anterior de memória.

Se o login Entra interromper o serviço, reponha primeiro o método de autenticação anterior na sua posição original. Reponha apenas Match known users e Use web authentication for unknown users nos valores registados antes da implementação. Em seguida, teste um login pelo método anterior, Current activities > Live users e tráfego real que deva corresponder à regra.

Não elimine imediatamente a aplicação Entra, o objeto de servidor, os grupos importados ou o client secret: WebAdmin, VPN Portal ou Remote Access também podem utilizá-los. Remova a Captive portal URL da App Registration apenas depois de confirmar que nenhum serviço ou outro nó da firewall a utiliza.

Solução de problemas

O portal cativo não está acessível

Primeiro verifique Administration > Device access para a zona afetada. Em seguida, verifique DNS, certificado, FQDN do portal, ACL de serviço local e mapeamento de zona. Se o acesso for para o próprio firewall, uma regra de firewall normal não será o primeiro ponto de verificação.

O login da Microsoft começa, mas não volta

Compare URI de redirecionamento, FQDN, certificado e porta. A URL exata que o Sophos Firewall usa para o Captive Portal deve ser armazenada no Microsoft Entra ID. As regras de inspeção por proxy ou TLS também podem interferir na devolução.

Quando a Microsoft mostra o erro AADSTS50011, o URI de redirecionamento no registo da aplicação geralmente não corresponde ao URL que o firewall está usando. Em seguida, o protocolo, FQDN, porta e caminho devem ser comparados com exatidão.

Um erro interno aparece após o login da Microsoft

Um 500 Internal Server Error ou um erro genérico semelhante após um login bem-sucedido da Microsoft geralmente indica falta de permissões do Microsoft Graph, falta de consentimento do administrador ou um problema com o segredo do cliente. Em seguida, deve verificar as permissões da API, o consentimento do administrador, a validade do segredo e a atribuição da aplicação empresarial no Microsoft Entra ID.

Se oauth_sso_captive.log apresentar x509: certificate signed by unknown authority, deve primeiro ler-se a cadeia de certificados Microsoft alcançada pela firewall e importar uma Root CA ou Intermediate CA comprovadamente em falta a partir de uma fonte fidedigna:

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

Depois executa-se novamente Test connection. Apenas quando a cadeia da CA já estiver corrigida e o erro persistir, o reinício documentado pela Sophos do serviço Captive SSO, local ao nó, constitui um último passo opcional numa janela de manutenção:

service oauth_sso_captive:restart -ds nosync

Em seguida repetem-se Test connection e um novo login no Captive Portal. O reinício do serviço não substitui a verificação do certificado nem um Admin Consent em falta.

Nome de utilizador e palavra-passe não funcionam diretamente

Entra ID SSO é um navegador e fluxo OAuth/OIDC. Os utilizadores não fazem login diretamente no firewall com credenciais clássicas, mas são redirecionados para a Microsoft. Se um cliente ou fluxo suportar apenas nome de utilizador e palavra-passe sem redirecionamento do navegador, esse método não será adequado.

MFA não aparece ou aparece de forma diferente do esperado

Com o SSO do Entra ID, o MFA é controlado no Microsoft Entra ID. O MFA da firewall local não é o ponto de controlo correto para este fluxo de SSO. Se o MFA for necessário, deverá verificar o Acesso Condicional, os grupos de utilizadores e as exclusões, além de testar utilizadores no Microsoft Entra ID.

O utilizador vê no permission ou é rejeitado após operação prolongada

Este erro corresponde a NC-167128 no SFOS 21.0 GA Build 169: se o mesmo utilizador usar primeiro o Entra ID SSO, depois o AD local na rede interna e, por fim, reutilizar o token Entra anterior, pode surgir no permission. O problema está corrigido a partir do SFOS 21.5 MR2 Build 323 ou do SFOS 22.0 MR1 Build 490.

Na versão afetada, devem ser eliminados primeiro os cookies do navegador. Se o problema ocorrer no Sophos Connect, deve ser executado Force SSO re-login; o caminho está descrito em Configurar o Microsoft Entra ID SSO para o Sophos Connect e o VPN Portal. A longo prazo, é mais simples utilizar sempre o Entra ID ou o AD local para o mesmo utilizador e atualizar para uma versão de firmware corrigida.

O login funciona, mas a regra do utilizador não corresponde

Então o portal cativo provavelmente não é mais o único problema. Verifique a zona de origem, a rede de origem, o grupo de utilizadores, a posição da regra e o visualizador de log. Muitas vezes, uma regra mais geral está acima da regra do utilizador ou o tráfego vem de uma rede diferente da esperada.

Verificar também se o grupo Entra pretendido está importado e se o utilizador lhe foi associado na firewall. Apenas na SFOS 20.0 GA Build 222, afetada por NC-167130, a regra tem de conter o Primary Group ou o utilizador individual para este erro.

Apenas utilizadores individuais são afetados

Compare UPN, endereço de e-mail, nome de exibição, associação ao grupo e grupo importado. Com o SSO do Entra ID, não deve presumir que o nome visível e o identificador técnico sejam idênticos. Se o endereço de e-mail e o UPN divergirem historicamente, surgirão facilmente erros de mapeamento.

Que registos ajudam?

Para o Captive Portal com Entra ID SSO, o ficheiro oauth_sso_captive.log é particularmente relevante. Também ajudam o Log Viewer com o módulo Authentication, o ficheiro access_server.log e, consoante o problema subsequente, os registos Web, da firewall ou de autenticação. A correspondência dos ficheiros mais importantes encontra-se em Resolução de problemas da Sophos Firewall: serviços e registos.

Lista de verificação

• O caso de uso do portal cativo é claro: BYOD, convidados, dispositivos não geridos ou substitutos.
• O FQDN e o certificado do portal cativo estão limpos.
• A aplicação Microsoft Entra ID com URI de redirecionamento, ID do cliente, ID do inquilino e segredo do cliente está documentada.
• As permissões da API do Microsoft Graph e o consentimento do administrador são definidos.
• As atribuições de aplicações empresariais são verificadas se Atribuição necessária estiver ativa.
• O Segredo do Cliente possui data de validade, proprietário e processo de rotação.
• O URI de redirecionamento do portal cativo foi assumido pelo firewall e inserido exatamente no Entra ID.
• Authentication > Services usa o servidor Entra correto para Captive Portal.
• Authentication > Web authentication usa HTTPS e configurações apropriadas da janela do navegador.
• Administration > Device access permite Captive Portal apenas nas zonas necessárias.
• Os endpoints de login da Microsoft estão acessíveis a partir da rede do cliente.
• A filtragem da Web e a inspeção TLS não bloqueiam o fluxo de SSO.
• O MFA e o Acesso Condicional são planeados e testados no Microsoft Entra ID.
• A correspondência entre o grupo Entra e o grupo da firewall foi verificada.
• O grupo Entra pretendido está importado e é realmente avaliado para o utilizador de teste.
• O utilizador de teste pode fazer login e atingir a regra de firewall esperada.
• O visualizador de log mostra utilizador, ID de regra e ação.
• oauth_sso_captive.log e access_server.log são conhecidos por casos de suporte.
• O fallback para falha do Entra ou Portal está documentado.

Perguntas frequentes