Configurar Microsoft Entra ID SSO para Sophos Connect e Portal VPN

Com o Microsoft Entra ID SSO, a Sophos Firewall pode autenticar utilizadores para o Portal VPN e para o Acesso Remoto através do Sophos Connect contra o Microsoft Entra ID. Para muitas infraestruturas Microsoft 365, isto é mais sensato do que palavras-passe locais separadas na firewall, pois a identidade, o acesso condicional e o MFA são geridos centralmente no fornecedor de identidade.

A vantagem só é real se toda a cadeia for bem planeada: aplicação Entra, URIs de redirecionamento, Portal VPN, Sophos Connect, métodos de autenticação, grupos, Device Access e perfis de cliente devem estar alinhados. Este artigo descreve o processo prático para o Portal VPN, SSL VPN e Acesso Remoto IPsec com o Sophos Connect.

Para a configuração geral do Sophos Connect, comece por Configurar o Sophos Connect na Sophos Firewall. Este artigo complementa os passos específicos de identidade e SSO.

Escolha da versão: Os caminhos de navegação, nomes de campos e ficheiros de registo específicos de cada serviço apresentados até agora neste artigo referem-se ao SFOS 22. Para o SFOS 23.0, utilize a variante OpenID Connect descrita abaixo e os registos aí indicados. As permissões da aplicação, políticas VPN, aprovisionamento, MFA e testes piloto e de recuperação continuam a fazer parte do mesmo processo; a alteração do formulário do servidor, por si só, não concede acesso à VPN. A disponibilidade da ajuda do SFOS 23 não permite deduzir uma data de GA.

O que o Entra ID SSO faz na firewall

A Sophos Firewall integra o Microsoft Entra ID SSO através de OAuth 2.0 e OpenID Connect. A firewall utiliza o Entra ID como servidor de autenticação e pode inscrever utilizadores para vários serviços.

Para o Acesso Remoto, estes serviços são especialmente relevantes:

• Portal VPN
• SSL VPN através do Sophos Connect
• Acesso Remoto IPsec através do Sophos Connect

Para o Captive Portal, aplica-se um processo diferente: o utilizador já se autentica na rede local através do navegador, para que as regras baseadas em utilizadores sejam aplicadas. Este caso é descrito separadamente em Configurar Microsoft Entra ID SSO para o Captive Portal da Sophos Firewall.

O Microsoft Entra ID SSO direto não abrange todos os logins clássicos da firewall. Para o User Portal e o Client Authentication Agent, a Sophos remete para o Microsoft Entra ID Domain Services. Trata-se de uma arquitetura de diretório separada e compatível com AD ou LDAP, não de uma opção adicional no objeto de servidor OAuth/OIDC. Quem necessitar do User Portal ou do CAA não deve, por isso, assumir que a aplicação SSO configurada neste artigo autentica automaticamente esses serviços.

É importante a distinção: a firewall continua a gerir o VPN, políticas, correspondência de grupos de utilizadores e acesso através de regras de firewall. O Entra ID gere a verificação de identidade, SSO e MFA baseado no Entra.

Um servidor Entra ID, vários serviços

O servidor Microsoft Entra ID é criado uma vez na Sophos Firewall em Authentication > Servers. Depois, o mesmo objeto de servidor pode ser selecionado em Authentication > Services para diferentes serviços, por exemplo Portal VPN, SSL VPN, Acesso Remoto IPsec, Captive Portal ou login de administradores.

Isto não significa que todos os serviços funcionem automaticamente da mesma forma. Cada serviço precisa da Redirect URI correta, do método de autenticação correto e de um caminho de teste próprio. Para Portal VPN, SSL VPN e Acesso Remoto IPsec, o URL relevante é VPN portal and remote access URL. Se Captive Portal ou WebAdmin também usarem Entra ID SSO, os respetivos URLs de serviço também devem ser adicionados na aplicação Entra e testados separadamente.

Para o serviço administrativo, são ainda necessárias funções ou grupos Entra, perfis de permissões locais e um acesso de emergência testado. O procedimento separado encontra-se em Configurar o Microsoft Entra ID SSO para o WebAdmin do Sophos Firewall.

Por método de autenticação só pode ser usado um servidor Microsoft Entra ID. Com Sophos Connect Provisioning, Portal VPN, SSL VPN e IPsec devem, por isso, usar conscientemente o mesmo servidor Entra ID, para que o valor gateway, a Redirect URI e o perfil de cliente coincidam.

Quando o Entra ID SSO é adequado

O Entra ID SSO é adequado quando os utilizadores já trabalham com o Microsoft 365 e a organização utiliza o Acesso Condicional ou o Entra-MFA como controlo de segurança central.

Razões típicas:

• Os utilizadores não devem manter palavras-passe de firewall separadas.
• O MFA deve ser gerido através do Entra ID em vez do Sophos OTP.
• O Acesso Remoto deve estar mais ligado ao estado do utilizador, grupos e Acesso Condicional.
• O helpdesk e a equipa de segurança devem gerir processos de identidade centralmente no Entra ID.
• Deve-se reduzir os utilizadores locais da firewall.

Nem todas as infraestruturas devem mudar imediatamente. Em instalações pequenas sem um modelo de grupos Entra bem definido, o MFA próprio da Sophos pode ser mais simples. Para a variante clássica de OTP, veja Ativar MFA para o WebAdmin da Sophos Firewall, Portal VPN e Acesso Remoto.

Pré-requisitos e limitações

Antes da configuração, devem ser cumpridos os seguintes pontos:

• Sophos Firewall com versão SFOS suportada.
• Tenant Microsoft Entra com permissão para criar um registo de aplicação.
• FQDN público para o Portal VPN ou acesso remoto.
• Certificado válido para o nome público.
• O Portal VPN é acessível através da zona necessária.
• Sophos Connect 2.4 ou mais recente no Windows, se o SSO for utilizado no cliente.
• Utilizadores ou grupos estão corretamente presentes no Entra ID.
• A firewall e o Entra ID têm a hora correta.
• URLs de login da Microsoft são acessíveis pelos clientes e, dependendo do caminho do tráfego, pela firewall.

Limitações importantes:

• Para o SSO do Sophos Connect, a Sophos menciona endpoints Windows com o Sophos Connect 2.4 ou mais recente.
• Quando o Microsoft Entra ID SSO é utilizado, o MFA é gerido no fornecedor de identidade. O MFA próprio da Sophos Firewall não pode ser utilizado adicionalmente para este método de autenticação.
• No SFOS 22, apenas um servidor Microsoft Entra ID pode ser selecionado por método de autenticação. No SFOS 23, o limite aplica-se a um servidor IdP OpenID Connect, e não a um servidor Entra adicional a outro fornecedor OIDC.
• Utilizadores do mesmo domínio não devem ser sincronizados simultaneamente através do AD e do Microsoft Entra ID.
• Em clusters HA, atualmente não se deve assumir que o Microsoft Entra ID SSO funciona para o WebAdmin da firewall auxiliar.

⚠️ O Acesso Condicional requer uma versão de firmware corrigida: No SFOS 21.5 GA Build 171, o Sophos Connect podia reutilizar uma sessão SSO existente sem verificar novamente o MFA e outras condições de Acesso Condicional. Desligar e voltar a ligar o túnel VPN nem sempre era suficiente. A Sophos identifica o problema como NC-167126 e não indica uma solução temporária oficial. O problema está corrigido a partir do SFOS 21.5 MR2 Build 323 ou do SFOS 22.0 MR1 Build 490. Se o Acesso Condicional for uma fronteira de segurança, deve-se primeiro atualizar pelo menos para uma destas versões. Force SSO re-login reduz o risco em sistemas anteriores, mas não substitui a correção.

⚠️ Uma atualização para o SFOS 22 pode ativar automaticamente o SSO: Se o Portal VPN, o Acesso Remoto IPsec ou o SSL VPN utilizavam Same as firewall em Authentication > Services antes da atualização, o SFOS 22.0 ou posterior ativa automaticamente o Microsoft Entra ID SSO para estes serviços. Antes da atualização, documentam-se os métodos efetivos. Se o Entra SSO for pretendido, deve depois registar-se na aplicação Entra o VPN portal and remote access URL exato do objeto de servidor Entra e verificá-lo com um login real. Não se deve utilizar o URL reverse SSO do Sophos Fusion (anteriormente Sophos Central). Se o SSO não for pretendido, define-se expressamente o método desejado em vez de aceitar sem verificação o estado herdado.

Planear a arquitetura

Antes da configuração técnica, deve-se decidir quais serviços usarão o SSO.

• Portal VPN: A autenticação no portal deve ser feita através do Entra ID?
• SSL VPN: O SSL VPN deve ser utilizado através do Sophos Connect com Entra SSO?
• Acesso Remoto IPsec: O Acesso Remoto IPsec deve ser utilizado através do Sophos Connect com Entra SSO?
• Ficheiro de provisionamento: Será utilizado um ficheiro de provisionamento automático?
• Grupos: Quais grupos Entra podem usar o VPN?
• MFA: Quais regras de Acesso Condicional e MFA se aplicam ao Acesso Remoto?
• Fallback: O que acontece se o Entra ID ou o acesso à Internet à Microsoft não estiver disponível?

Se for utilizado um ficheiro de provisionamento, o valor gateway definido deve corresponder ao FQDN ou IP que é utilizado na configuração do Microsoft Entra ID na firewall como URI de redirecionamento. Após alterações no Entra ID ou na configuração da firewall, os utilizadores devem importar novamente a configuração atualizada.

Antes da alteração, documente Authentication > Services, ordem dos servidores, grupos e políticas VPN, Device Access e perfis distribuídos. Mantenha um administrador local independente do Entra ID como acesso break-glass protegido, monitorizado e testado separadamente. As licenças Entra exigidas pelas políticas Conditional Access devem estar disponíveis. SFOS 22: A integração SSO não suporta Microsoft 365 Government Community Cloud High (GCC High). A ajuda do SFOS 23 já não apresenta esta limitação; isso não é aqui interpretado como confirmação do suporte para GCC High. Para um tenant deste tipo, o suporte tem de ser esclarecido separadamente antes da implementação.

Preparar a aplicação Entra para a firewall

A Sophos recomenda uma aplicação dedicada. Em App registrations > New registration, crie uma aplicação Accounts in this organizational directory only com plataforma Web e copie Application (client) ID e Directory (tenant) ID. Em API permissions > Microsoft Graph, conceda com Admin Consent as permissões delegadas User.Read.All e Group.Read.All; adicione Group.Read.All como Application permission apenas para importar grupos no SFOS. Crie um Client secret, guarde imediatamente a Value em segurança e planeie expiração e rotação.

Em Enterprise application > Properties, defina Assignment required? como Yes e atribua apenas o grupo piloto/VPN e administradores necessários. Esta atribuição é o primeiro controlo; a política SSL/IPsec continua a ser o segundo. A Microsoft documenta a atribuição de utilizadores e grupos e as regras dos Redirect URIs. O SFOS lê automaticamente os atributos do token; escolha um Fallback user group sem direitos VPN abrangentes para que a ausência de um grupo importado não amplie o acesso.

A atribuição da aplicação baseada em grupos requer Microsoft Entra ID P1 ou P2 e não abrange utilizadores que pertençam apenas através de um grupo aninhado. Sem essa licença ou com grupos aninhados, atribua diretamente os utilizadores piloto; caso contrário, o Entra rejeita o início de sessão embora a pertença ao grupo VPN possa parecer correta.

Criar um servidor Microsoft Entra ID na firewall

SFOS 23.0: OpenID Connect com Microsoft Entra ID

No SFOS 23, o Entra ID é configurado como fornecedor no objeto de servidor OpenID Connect comum. A aplicação Entra existente continua a ser necessária; não se cria uma segunda aplicação apenas porque o formulário mudou de nome. Antes de qualquer alteração, documente o objeto de servidor existente, as suas atribuições a serviços e os URIs de redirecionamento. Uma atualização só é validada depois de repetir os testes do portal e do túnel.

1. Abra Authentication > Servers > Add e selecione OpenID Connect em Server type.
2. Defina Server name e selecione IdP vendor: Microsoft Entra ID.
3. Em Client ID, introduza o Application (client) ID da aplicação Entra e, em Client secret, o valor do respetivo segredo.
4. Em OpenID Connect URLs > Issuer URL, introduza o Directory (tenant) ID. Para este fornecedor, o campo SFOS documentado espera o ID do tenant; não o substitua por um URL de emissor construído manualmente. As restantes definições de URL não se aplicam ao Microsoft Entra ID.
5. Em Redirect URIs, selecione Use firewall URL ou utilize Enter manually para introduzir o FQDN ou endereço IP previsto para a firewall. Se gerir uma única firewall através do Sophos Fusion, defina manualmente o nome do anfitrião; o URL reverse SSO não é um callback da appliance.
6. Abra Show URLs e registe o VPN portal and remote access URL exato como URI de redirecionamento Web na aplicação Entra. Com aprovisionamento, o valor gateway tem de corresponder ao FQDN ou IP da firewall utilizado aqui. As alterações exigem uma nova importação da configuração do cliente.
7. Em User attributes, mantenha os valores predefinidos Display name: name, Username: upn e Email address: email. Só um token efetivamente estruturado de outra forma e suportado justifica atributos diferentes.
8. Mantenha IdP authentication for firewall administrators desativado para serviços exclusivamente destinados a utilizadores VPN e escolha uma Fallback group com permissões restritas. O mapeamento de administradores é um passo separado no artigo sobre o WebAdmin.
9. Execute Test connection, guarde apenas após um teste bem-sucedido e atribua o servidor ao Portal VPN, SSL VPN e, se aplicável, IPsec em Authentication > Services. Execute Apply para cada serviço. O SSL VPN e o Portal VPN utilizam sempre o mesmo servidor; com aprovisionamento, isto também se aplica ao IPsec.

Após uma atualização, verifique também o aviso existente sobre Same as firewall: a ativação automática para métodos VPN herdados aplica-se ao SFOS 22.0 e posterior, incluindo a correspondente mudança para o SFOS 23. Uma migração de servidor documentada não substitui a verificação dos métodos efetivos nem um início de sessão real com controlo do redirecionamento, grupos, MFA e túnel.

SFOS 22: Microsoft Entra ID SSO

O formulário de servidor seguinte, com Directory (tenant) ID, User attribute mapping e Fallback user group, pertence ao SFOS 22. Para o SFOS 23, utilize os campos da variante anterior.

O caminho do menu é:

Authentication > Servers

Procedimento na firewall:

1. Abrir Add.
2. Selecionar a opção Microsoft Entra ID SSO como Server type.
3. Atribuir um nome descritivo ao servidor.
4. Inserir o Application (client) ID da aplicação Entra.
5. Inserir o Directory (tenant) ID.
6. Inserir o Client secret.
7. Verificar ou definir manualmente o FQDN do URI de redirecionamento.
8. Definir o grupo de fallback.
9. Se for necessário SSO para o WebAdmin, planear o mapeamento de funções ou grupos para perfis de administrador.
10. Executar Test connection.
11. Guardar.

Para cenários de SSO apenas para VPN, não é necessário mapeamento de funções de administrador. Nesse caso, o servidor deve ser planeado como um serviço de utilizador, não como um acesso administrativo geral.

⚠️ Os Client Secrets são dados de acesso produtivos. A data de validade, rotação, responsabilidade e documentação devem ser esclarecidas antes do lançamento.

Definir métodos de autenticação

Após criar o servidor Microsoft Entra ID, ele deve ser associado aos serviços adequados em Authentication > Services.

Para o Acesso Remoto, estas áreas são relevantes:

• VPN portal authentication methods
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods
• SSL VPN authentication methods

Se for utilizado um ficheiro de provisionamento, deve ser utilizado o mesmo servidor Microsoft Entra ID para o Portal VPN, IPsec e SSL VPN. Em ficheiros de provisionamento, é importante a mesma seleção de servidor para os métodos de autenticação, para que o perfil do cliente, o portal e o método de Acesso Remoto estejam alinhados.

Sem um ficheiro de provisionamento, o SSL VPN e o Portal VPN continuam a ter de utilizar o mesmo servidor Microsoft Entra ID; para o Acesso Remoto IPsec pode então ser utilizado outro objeto de servidor Entra. Com um ficheiro de provisionamento, o Portal VPN, o SSL VPN e o IPsec têm de apontar para o mesmo objeto. Esta diferença deve ser documentada conscientemente e não inferida apenas após um erro de tenant no diálogo SSO.

Após cada alteração:

1. Selecionar o servidor no método correspondente.
2. Arrastar o servidor para a posição correta, se houver vários servidores.
3. Executar Apply para cada serviço alterado.
4. Utilizar um utilizador de teste antes de implementar amplamente a alteração.

Inserir URIs de redirecionamento no Microsoft Entra ID

Para que o SSO funcione, as URLs da firewall devem ser registadas na aplicação Entra como URIs de redirecionamento.

Procedimento:

1. Abrir Authentication > Servers na firewall.
2. Abrir o servidor Microsoft Entra ID.
3. Copiar as URLs necessárias:
   • URL da consola de administração web, se o SSO do WebAdmin for utilizado
   • URL do portal cativo, se o Captive Portal for utilizado
   • URL do portal VPN e acesso remoto para o Portal VPN, Acesso Remoto IPsec e SSL VPN
4. No Azure Portal, ir para Microsoft Entra ID > App registrations.
5. Abrir a aplicação para a Sophos Firewall.
6. Em Manage > Authentication, adicionar uma plataforma web ou editar a plataforma web existente.
7. Inserir os URIs de redirecionamento copiados.
8. Guardar.

Um erro comum é um nome de host diferente no perfil do cliente, URI de redirecionamento, certificado e DNS público. Estes valores devem ser conscientemente alinhados antes do lançamento.

Se não for o Acesso Remoto, mas sim o Captive Portal a ser protegido, deve-se verificar adicionalmente o processo específico do Captive Portal: Device Access para a zona do cliente, método de autenticação do Captive Portal, grupo de utilizadores e correspondência de regras de firewall posterior.

Permitir Portal VPN através do Device Access

O Microsoft Entra ID SSO para Acesso Remoto utiliza a porta do Portal VPN para comunicar com a firewall. Para acesso a partir da Internet, permita por isso VPN Portal na linha WAN em Administration > Device access. Ative outras zonas apenas se os clientes realmente precisarem de alcançar o portal a partir delas.

Isto não significa que o Portal VPN deva ser aberto mundialmente sem consideração. O Acesso Remoto é uma superfície de ataque publicamente acessível. Para ambientes produtivos, deve-se verificar adicionalmente:

• certificado público válido
• MFA e Acesso Condicional no Entra ID
• limitação de países ou fontes o mais restrita possível, se realista
• registo e revisão das tentativas de login
• desativação clara de utilizadores que não são mais necessários

O fortalecimento dos serviços locais da firewall está descrito em Device Access e Local Service ACL na Sophos Firewall.

Se já ocorrerem muitas falhas de login, origens distribuídas ou bloqueios de contas Entra, Detetar e conter ataques de força bruta ao VPN Portal combina os logs da firewall com a verificação Entra, uma limitação ACL segura e a verificação posterior.

Permitir URLs de login da Microsoft

Os clientes e os caminhos de firewall afetados devem poder alcançar os endpoints do Microsoft Entra ID. Isto inclui várias URLs de login e CDN da Microsoft, como login.microsoftonline.com, login.microsoft.com, *.login.live.com, *.msauth.net e outros domínios Azure/Microsoft Online.

Em ambientes restritivos, não se deve descobrir apenas no lançamento que páginas de login, JavaScript ou endpoints de token estão bloqueados. É sensato:

• Utilizar a lista de permissões de login do Microsoft Entra completa para Hosts FQDN e exceções de proxy.
• Nomear corretamente Hosts FQDN ou Grupos de Hosts FQDN.
• Definir conscientemente a regra de firewall para DNS e HTTPS.
• Em caso de proxy web direto, verificar exceções web adicionais.
• Ativar registo até que o login SSO esteja estável.

Com um Direct Web Proxy, a regra Allow para o FQDN Host Group, por si só, não é suficiente. O artigo associado sobre a lista de permissões contém os padrões URL exatos e descreve o procedimento em Web > Exceptions. Limite a exceção aos padrões de login e CDN necessários.

Verificar grupos e permissões de VPN

O SSO por si só não concede acesso ao VPN. O utilizador também deve ser permitido na configuração de Acesso Remoto adequada.

Importar grupos Entra de forma direcionada

Para importar grupos, a firewall necessita da permissão Microsoft Graph Group.Read.All como Application permission na aplicação Entra, bem como do Admin Consent concedido. Depois abre-se o Assistant for importing groups no servidor Entra em Authentication > Servers. Em vez de importar todos os grupos sem controlo, o assistente pode filtrar, por exemplo, por Display name ou Description.

Durante a importação, é possível definir Surfing quota, Access time, Network traffic e Traffic shaping para todos os grupos ou para grupos individuais. Estas políticas só são atribuídas quando a respetiva função é realmente necessária. A hora da firewall e do Microsoft Entra ID tem de estar sincronizada, caso contrário a própria importação pode falhar.

Se o grupo Entra existir na firewall, o SFOS atribui o utilizador a esse grupo. Se estiver em falta, é utilizado o Fallback user group configurado no servidor Entra. Isto também se aplica quando o servidor Entra é utilizado em Firewall authentication methods; o Default group aí configurado não substitui o grupo de fallback. Após a importação, o novo grupo tem ainda de ser autorizado na respetiva política IPsec ou SSL VPN.

A verificar:

• O grupo Entra foi importado para a firewall ou está corretamente mapeado.
• O grupo está selecionado em Acesso Remoto IPsec em Allowed users and groups.
• O grupo está selecionado em SSL VPN em Policy members.
• As regras de firewall permitem tráfego da zona VPN apenas para os destinos necessários.
• O utilizador não está apenas autenticado, mas também recebe a política esperada.

Se o túnel estiver ligado, mas não houver tráfego, frequentemente a causa não é o SSO, mas sim regras, encaminhamento, DNS ou NAT. Para a análise, veja Testar regra de firewall com Log Viewer, Policy Test e Packet Capture.

Verificar UPN, e-mail e correspondência de grupos

Com o Microsoft Entra ID SSO, deve-se verificar cuidadosamente a identidade do utilizador e a correspondência de grupos. Um login pode ser bem-sucedido no fornecedor de identidade e ainda assim ser incorretamente associado na firewall se o UPN, endereço de e-mail, grupo importado ou identificação local do utilizador não corresponderem.

Isto é especialmente relevante em ambientes onde os utilizadores têm historicamente valores diferentes:

• User Principal Name: max.muster@example.com é frequentemente esperado como o nome de login real.
• Endereço de e-mail: m.muster@example.com pode diferir e confundir na associação ou login no portal.
• Nome de exibição: Max Muster é legível para humanos, mas não adequado como identificação técnica.
• Grupo: VPN-Users deve ser importado para a firewall e utilizado na configuração de Acesso Remoto correta.

Numa migração do Active Directory local para o Entra ID, o formato de login também é determinante. O AD utiliza frequentemente sAMAccountName@domain, enquanto o Entra ID utiliza UserPrincipalName@domain. O SFOS trata cadeias diferentes como objetos de utilizador distintos, mesmo quando pertencem à mesma pessoa. Por isso, o formato deve ser harmonizado antes da migração. Se forem utilizados deliberadamente nomes diferentes, surgem duplicados; os utilizadores AD antigos só são removidos depois de se verificarem regras, grupos, relatórios e o novo login Entra.

O antigo problema conhecido NC-157635 causava falhas no login do portal SSL VPN ou IPsec quando o endereço de e-mail e o UPN eram diferentes. A Sophos corrigiu-o no SFOS 21.0 MR2 Build 349, 21.5 MR1 Build 261 e 22.0 EAP0 Build 274. A verificação dos atributos dos utilizadores continua a ser útil para problemas com contas individuais, pois permite detetar objetos de utilizador locais ou permissões de grupo divergentes.

Procedimento prático de verificação:

1. Abrir o utilizador de teste no Microsoft Entra ID.
2. Comparar UPN e endereço de e-mail.
3. Verificar se o utilizador é membro do grupo VPN planeado.
4. Na firewall, abrir o grupo importado e verificar se o utilizador aparece como esperado.
5. Em Authentication > Services, verificar se o servidor Microsoft Entra ID correto está selecionado para o Portal VPN, SSL VPN e IPsec.
6. Realizar um login de teste e verificar o Log Viewer e oauth_sso_vpn.log.

Se apenas utilizadores individuais forem afetados, é mais provável que seja um problema de atributo ou grupo do que um erro geral do servidor Entra ID. Se todos os utilizadores forem afetados, primeiro verifique Tenant ID, Client ID, Client Secret, URIs de redirecionamento, hora e endpoints da Microsoft.

Para regras de utilizador após um login VPN bem-sucedido, aplica-se adicionalmente: a regra de firewall deve ver o utilizador ou grupo no tráfego real. Se o túnel estiver ativo, mas a regra de utilizador planeada não corresponder, a análise de Regra da Sophos Firewall não está a corresponder: verificar causas é adequada.

Introduzir MFA e Conditional Access de forma controlada

Limite a política à Enterprise Application da firewall e comece com utilizadores piloto ou modo Report-only. Verifique MFA e cada condição com um caso permitido e outro negado nos registos Entra. A Microsoft recomenda planear e avaliar as políticas antes de as impor.

Mantenha pelo menos duas contas de emergência Entra cloud-only, separadas, monitorizadas e excluídas de Conditional Access. Não substituem o administrador local independente da Internet, Entra e aplicação, nem devem ser atribuídas à VPN apenas para testar um bypass. Consulte Manage emergency access accounts.

Testar o Sophos Connect e o aprovisionamento

Para o Sophos Connect, aplica-se: após a configuração do Entra ID ou após alterações na configuração do SSO, a configuração do cliente deve ser importada novamente.

Testar macOS separadamente: Para Microsoft Entra ID SSO com Sophos Connect 2.1 ou posterior no macOS (não 2.0), siga o procedimento de autenticação no navegador em macOS. auto começa no navegador integrado e muda para o navegador do sistema quando os requisitos pertinentes de Conditional Access o exigem; embedded não tem mudança automática. A escolha de system através de um ficheiro .pro aprovado é explicada no esquema de aprovisionamento, não através de alterações manuais a .ovpn ou .scx. Conclua o início de sessão, incluindo MFA, no navegador aberto pelo cliente, regresse ao cliente e verifique o túnel, DNS e acesso. Mudar de navegador não contorna a conformidade do dispositivo: cumpra os requisitos ou contacte a equipa de TI, sem enfraquecer Conditional Access. O teste Windows seguinte continua a aplicar-se ao Sophos Connect 2.4 ou posterior.

Procedimento de teste:

1. Instalar o cliente Sophos Connect atual no Windows.
2. Importar a configuração de provisionamento ou VPN adequada.
3. Verificar se a opção SSO está visível e clicável no cliente.
4. Fazer login com o Entra ID.
5. Acionar o MFA ou Acesso Condicional conforme planeado e verificar o resultado nos logs de login do Entra.
6. Verificar o estado do túnel.
7. Verificar IP VPN, DNS, destinos internos e correspondência de regras de firewall.
8. Num dispositivo partilhado, testar um novo login SSO forçado.

Para o último teste, abra o menu no canto superior direito do cliente Sophos Connect, selecione Force SSO re-login e confirme com OK. Só então o utilizador seguinte terá de iniciar sessão com as próprias credenciais do Entra. Desligar o túnel normalmente não é equivalente. Em dispositivos Windows partilhados, este passo também faz parte de uma mudança de utilizador correta com firmware atualizado.

Registe em cada teste hora, utilizador, tipo de VPN e resultado esperado. Aplicação, utilizador, resultado MFA/Conditional Access e código de erro no Entra devem corresponder a oauth_sso_vpn.log ou ao módulo Authentication do Log Viewer. Antes do rollout, teste no seu ambiente: piloto atribuído e utilizador não atribuído no portal; cada perfil SSL/IPsec usado com IP VPN, DNS e apenas destinos autorizados; utilizador sem grupo VPN; Force SSO re-login num dispositivo partilhado; e login do administrador break-glass pelo caminho restrito. Estes são testes a executar, não resultados alegados.

Para a instalação do cliente no Windows, veja Instalar o cliente Sophos Connect no Windows. Para SSL VPN com o Sophos Connect, veja adicionalmente Configurar SSL VPN com o Sophos Connect no Windows.

Rollback com preservação do estado

Não remova a autenticação anterior antes de piloto e rollback terem sucesso; conserve os perfis antigos sob controlo. Em caso de falha SSO, entre com o administrador local e restaure em Authentication > Services os servidores e a ordem documentados para VPN Portal, SSL VPN e IPsec, selecionando Apply em cada serviço. Reimporte o perfil antigo num dispositivo piloto e teste portal, túnel, DNS e um destino interno autorizado.

Só elimine aplicação Entra, novo servidor, grupos importados e secret depois de acesso e registos confirmarem a recuperação. Se Device Access foi ampliado apenas para SSO, restaure-o depois para não bloquear simultaneamente o caminho VPN recuperado.

Operação e segurança

O Entra ID SSO desloca a segurança do login mais para o fornecedor de identidade. Isto é bom se o Entra ID for gerido corretamente. É problemático se grupos, Acesso Condicional ou segredos de aplicação forem geridos de forma descuidada.

Na operação, estes pontos devem ser verificados regularmente:

• O segredo da aplicação não expira inesperadamente.
• Os grupos Entra contêm apenas utilizadores autorizados.
• O Acesso Condicional aplica-se ao Acesso Remoto.
• Acessos de emergência e de fallback estão documentados.
• O Portal VPN é acessível apenas na medida necessária.
• As versões do Sophos Connect estão atualizadas.
• Perfis de cliente antigos são retirados de circulação após alterações.
• Os logs são verificados cedo em caso de problemas de login.

Para o lado do cliente, deve existir adicionalmente um processo de atualização próprio. O artigo Verificar e atualizar com segurança a versão do cliente Sophos Connect resume quais temas de Windows, macOS, SSO, OTP e provisionamento devem ser verificados antes de um lançamento.

Solução de problemas

SFOS 23.0: Para o fluxo de início de sessão OIDC, utilize /log/oauth_sso_svc.log; os erros de Test connection com x509: certificate signed by unknown authority são analisados em /log/sfos-macro-cfg.log. No Log Viewer, o módulo Authentication continua a ser relevante para o Portal VPN, IPsec e SSL VPN. As referências seguintes a oauth_sso_vpn.log e o reinício específico do serviço pertencem ao SFOS 22.

Depois de corrigir uma cadeia de CA comprovadamente incompleta, repita primeiro Test connection. Apenas se continuar a ser necessário um reinício e for aceitável interromper os serviços de início de sessão OIDC utilizados durante a janela de manutenção, utilize o comando da Advanced Shell documentado pela Sophos para o SFOS 23:

service oauth_sso_svc:restart -ds nosync

Em seguida, verifique novamente Test connection, um novo início de sessão no Portal VPN e o túnel efetivamente utilizado. O reinício do serviço comum não é exclusivo da VPN; os outros serviços utilizados através deste objeto OIDC também devem ser testados novamente em separado. Nenhum reinício substitui a verificação de DNS, hora, permissões ou CA.

O botão SSO não está utilizável no cliente Sophos Connect

Se o cliente indicar que o SSO não está configurado, teste primeiro a ligação ao servidor Microsoft Entra ID na firewall. Depois, em Authentication > Services, verifique se o servidor Entra ID está corretamente definido para SSL VPN ou IPsec e Portal VPN.

O utilizador não pode fazer login no Portal VPN

Nesse caso, o SSO pode funcionar em geral, mas a permissão de VPN pode faltar. Verifique se o grupo Entra está incluído na configuração de Acesso Remoto IPsec em Allowed users and groups ou em SSL VPN em Policy members.

Apenas utilizadores individuais não conseguem fazer login

Nesse caso, primeiro verifique UPN, endereço de e-mail, associação de grupo e grupo importado na firewall. Especialmente para utilizadores com endereço de e-mail diferente, nomes alterados ou contas migradas, a identificação técnica pode parecer diferente do esperado.

A Microsoft relata tenant ou aplicação incorretos

Nesse caso, frequentemente os métodos de autenticação, aplicação Entra, Tenant ID ou a seleção de servidor na firewall não estão alinhados. Especialmente com vários servidores Entra ID, deve-se verificar se o Portal VPN, SSL VPN e IPsec utilizam o mesmo servidor esperado.

Redirecionamento ou login termina em página de erro

Compare FQDN, certificado, DNS público, URI de redirecionamento e valor de gateway do ficheiro de provisionamento. Pequenas discrepâncias no nome de host, porta ou caminho podem interromper o fluxo OAuth/OIDC.

Test connection falha com um erro x509

Se o oauth_sso_vpn.log apresentar o erro x509: certificate signed by unknown authority, pode faltar uma CA de raiz ou intermédia na cadeia de certificados para o Microsoft Entra ID. O problema conhecido NC-176806 foi corrigido no SFOS 22.0 MR2 Build 546; continuam a ser possíveis outras cadeias de certificados incompletas ou erros de TLS.

Na Advanced Shell, pode verificar-se a cadeia fornecida pela Microsoft:

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

1. Verificar a cadeia de certificados e o Issuer na saída.
2. Obter apenas a CA de raiz ou intermédia em falta a partir de uma fonte fidedigna. Não importar um certificado de servidor como CA.
3. Adicionar a CA em Certificates > Certificate Authority e aplicar.
4. Em Authentication > Servers, abrir o servidor Entra ID e executar novamente Test connection.
5. Apenas se o teste continuar a falhar e for aceitável uma breve interrupção dos logins VPN SSO em curso, reiniciar o serviço VPN SSO na Advanced Shell:

service oauth_sso_vpn:restart -ds nosync

Em seguida, executar novamente Test connection. O reinício do serviço é um último passo opcional, não a primeira medida perante um erro x509.

Importação de grupos não funciona

Verifique a hora da firewall, dados do tenant, permissões da aplicação, Client Secret e acessibilidade dos endpoints da Microsoft. Se grupos locais existentes não corresponderem aos grupos Entra, deve-se decidir se eles serão limpos, mapeados ou geridos manualmente.

Ligação estabelecida, mas sistemas internos não estão acessíveis

Nesse caso, a autenticação provavelmente já não é o principal problema. Verifique IP VPN, DNS, regras de firewall, NAT, encaminhamento e sistema de destino. No Log Viewer, deve ser visível qual regra está a afetar o tráfego da zona VPN.

Lista de verificação

• Aplicação Entra com Client ID, Tenant ID e Client Secret está documentada.
• URIs de redirecionamento para Portal VPN e Acesso Remoto estão registados no Entra ID.
• FQDN público, certificado e gateway de provisionamento estão alinhados.
• Portal VPN está conscientemente permitido em Device Access.
• URLs de login da Microsoft são acessíveis.
• Serviços de autenticação utilizam o servidor Entra ID correto.
• Grupos de VPN estão importados e permitidos em políticas SSL/IPsec.
• UPN, endereço de e-mail e associação de grupo foram verificados com um utilizador de teste.
• Sophos Connect 2.4 ou mais recente está em uso no Windows.
• Perfis de cliente foram importados novamente após alterações.
• Entra-MFA e Acesso Condicional foram verificados com um utilizador de teste.
• oauth_sso_vpn.log, Log Viewer e logs do Access Server são conhecidos para solução de problemas.

Perguntas frequentes