Gerir corretamente grupos de utilizadores e a Main Group na Sophos Firewall

Os grupos de utilizadores agregam políticas comuns para utilizadores autenticados. Antes de alterar um grupo, é necessário esclarecer dois aspetos: de onde provém a identidade e se a função afetada avalia apenas a Main Group ou também outros grupos do AD. Só então poderá determinar se deve alterar a ordem dos grupos, a atribuição de uma política ou a própria regra de firewall ou VPN.

Procedimento rápido:

Definir a origem do utilizador e o propósito do grupo.
Criar um grupo local ou importar especificamente o grupo de diretório necessário.
Verificar em Authentication > Services o Default group efetivo ou, no servidor Entra, o Fallback user group.
No AD, documentar a ordem em Authentication > Groups > Reorder e a Main Group esperada.
Terminar a sessão do utilizador piloto e voltar a iniciá-la. Depois, em Authentication > Users > utilizador > Policies, verificar os campos Group e Other group memberships.
Testar a função afetada com um utilizador autorizado e um não autorizado. Em caso de tráfego de rede, verificar também o Firewall Rule ID esperado.

⚠️ Reorder não é uma simples função de ordenação sem consequências. Para utilizadores AD, uma alteração de posição pode modificar a Main Group e, consequentemente, a MFA, as quotas, os horários de acesso, o acesso remoto e outras políticas para muitos utilizadores. Registe previamente a ordem, as políticas de grupo e o procedimento de reposição.

Compreender o modelo de grupos

Um grupo define políticas e configurações comuns. Não substitui a autenticação nem uma regra de firewall. Por isso, um utilizador pode pertencer ao grupo correto e, ainda assim, não obter acesso se faltar a regra esperada, a política de VPN, a zona, a rota ou o caminho de retorno.

Em caso de erro, analise quatro questões separadamente:

A identidade provém da base de dados local, Active Directory, LDAP, RADIUS, Microsoft Entra ID ou de uma atribuição sem cliente?
Qual é a Main Group?
A função afetada suporta outras associações a grupos do AD?
Qual regra ou política processa o tráfego real de dados?

Distinguir grupos locais, importados e sem cliente

Normal e Clientless são tipos de grupo. Importado, por outro lado, descreve a origem de um grupo e não é um Group type próprio.

Um grupo local do tipo Normal é adequado para utilizadores que iniciam sessão. Os utilizadores locais recebem o respetivo grupo no objeto de utilizador. Com uma fonte de utilizadores externa, os registos de utilizadores locais geralmente só são criados no primeiro início de sessão bem-sucedido.

Os utilizadores convidados seguem um fluxo próprio com tempo limitado. Criar e gerir utilizadores convidados com segurança na Sophos Firewall explica o grupo predefinido, a validade, o portal cativo e a limpeza.

Os grupos AD e Entra são importados através do assistente do respetivo servidor. O diretório continua a ser a fonte das associações. Para AD, a Sophos documenta também, como alternativa, a criação manual do grupo tanto no AD como na firewall. Também neste caso é necessário verificar a atribuição ao grupo e as permissões após um novo início de sessão. O processo completo de configuração de AD, LDAPS e importação está descrito em Ligar o Active Directory à Sophos Firewall.

Para o LDAP genérico, Base DN, Authentication attribute, Group name attribute, a ordem dos servidores e Default group têm de ser coerentes entre si. A Sophos recomenda memberOf como atributo de grupo. Ligar um servidor LDAP à Sophos Firewall orienta-o nesta configuração.

Um grupo do tipo Clientless reúne utilizadores sem cliente e as respetivas configurações comuns. Estes utilizadores não iniciam sessão através de um cliente; a firewall controla o respetivo acesso com base no endereço IP. O endereço IP fixo é definido em cada utilizador sem cliente, não no objeto de grupo. Configurar utilizadores sem cliente na Sophos Firewall descreve a atribuição de IP, a regra e o teste negativo.

Não confundir o grupo predefinido com o fallback do Entra

Em Authentication > Services > Firewall authentication methods, Default group define qual grupo um utilizador de um servidor de autenticação externo recebe quando nenhum dos respetivos grupos de diretório está disponível como grupo local. A predefinição de fábrica é Open group. Verifique o valor atual em vez de pressupor que a predefinição continua ativa. Para ambientes de produção, a Avanet recomenda um grupo de fallback dedicado e restritivo, sem permissões inadvertidas de VPN, quotas ou início de sessão.

Descrições divergentes do AD sobre o primeiro início de sessão: O guia de configuração do AD descreve uma inclusão automática no Default group no primeiro início de sessão; em contrapartida, as FAQ do AD referem o Default group apenas quando nenhum grupo AD do utilizador existe na firewall. A visão geral dos servidores AD indica expressamente Open group para os utilizadores que pertencem apenas a uma OU e não pertencem a nenhum grupo de diretório, enquanto a visão geral dos grupos e as FAQ remetem para o Default group configurado. Estas descrições são contraditórias e não demonstram a existência de um grupo especial universalmente aplicável ao primeiro início de sessão, nem qualquer prioridade desse grupo. É necessário distinguir o Default group configurado da predefinição de fábrica Open group.

Antes da implementação, verifique o Default group efetivamente configurado e as permissões que dele são herdadas. Verifique separadamente o primeiro início de sessão com duas contas piloto distintas, criadas para esse fim: uma com um grupo AD já importado na firewall e outra sem nenhum dos seus grupos AD importado na firewall. Para ambas, verifique em Policies os campos Group e Other group memberships, bem como os acessos permitidos e os que deliberadamente não devem ser permitidos. Se a atribuição de grupos for inesperada, interrompa a implementação e esclareça a causa. Não elimine grupos de produção nem alargue as permissões de fallback para realizar estas verificações. Estes são passos de verificação de âmbito limitado, a realizar antes da implementação, e não um relato de um teste efetuado no equipamento.

O Microsoft Entra ID SSO utiliza o Fallback user group separado na configuração do servidor Entra. Este também se aplica se o servidor Entra estiver selecionado em Firewall authentication methods. O grupo predefinido geral não se aplica neste caso.

A ordem dos servidores de autenticação também é relevante. A Sophos Firewall permite no máximo 20 servidores por método de autenticação e encaminha os pedidos na ordem apresentada. Não altere essa ordem como solução alternativa para um problema de grupos antes de verificar o servidor responsável e o respetivo mapeamento.

Planear o exemplo e registar o estado inicial

O exemplo utiliza três grupos com funções distintas:

Local_Contractors: grupo piloto local para alguns colaboradores externos;
SFOS_Internet_Standard: grupo AD importado para acesso normal à Internet;
SFOS_SSLVPN: grupo AD importado para uma política SSL-VPN.

auth-pilot@example.com serve de conta de teste, e a regra LAN-Users-to-WAN, com registo ativado, é utilizada para testar o tráfego. example.com é um domínio reservado para documentação. Substitua nomes e utilizadores pela sua própria convenção de nomenclatura. Um nome relacionado com a função, como SFOS_SSLVPN, permanece compreensível mesmo após uma reorganização.

Anote antes da alteração:

ordem atual dos grupos;
Default group e, se necessário, Fallback user group;
políticas de grupo e substituições específicas de utilizadores;
serviços de autenticação afetados e políticas de VPN;
um acesso de administrador testado e uma segunda via de gestão, caso a Main Group, a MFA ou as restrições de início de sessão sejam afetadas;
utilizadores piloto, Main Group esperada e testes positivos e negativos.

Criar um grupo de utilizadores local

Aceda a Authentication > Groups e clique em Add:

Introduza Local_Contractors como nome do grupo.
Em Group type, selecione Normal.
Selecione apenas as políticas comuns necessárias:
- Surfing quota limita o tempo de utilização por período e ciclo.
- Access time permite ou nega períodos recorrentes.
- Network traffic limita a quantidade de dados transferidos.
- Traffic shaping atribui uma política de QoS com prioridade e limites de largura de banda.
Configure SSL VPN policy, Clientless SSL VPN policy, L2TP, PPTP e IPsec remote access apenas para o acesso efetivamente planeado. PPTP não é adequado para novas implementações; L2TP continua a ser uma opção de compatibilidade limitada, conforme explicado em Acesso remoto L2TP na Sophos Firewall.
Sempre que possível, limite Sign-in restriction às origens necessárias com Selected nodes ou Node range. Selected nodes permite o início de sessão apenas a partir dos endereços IP especificados; Node range permite endereços dentro do intervalo de IP especificado. Any node permite o início de sessão a partir de qualquer rede.
Ative Quarantine digest e MAC binding apenas se o grupo necessitar dessas funções. Quarantine digest envia para a caixa de correio do utilizador um resumo das mensagens de correio eletrónico retidas em quarentena. MAC binding restringe o início de sessão aos dispositivos previstos.
Clique em Save para guardar.

Os nomes dos campos e o seu efeito são determinados pelo produto; a escolha depende do ambiente. Um grupo de acesso à Internet não necessita automaticamente de VPN, quotas ou vinculação MAC. Os grupos com funções claramente definidas são mais fáceis de testar e de reverter.

Atribuir utilizadores locais e identificar substituições

Criar e gerir utilizadores locais normais descreve detalhadamente o nome de utilizador, a palavra-passe, a herança de grupos e os testes de aceitação. Os utilizadores locais podem ser atribuídos a um grupo em Authentication > Users. Na edição de grupos, Show group members mostra os membros; através de Add member(s), adicionam-se os utilizadores locais apropriados. Para identidades geridas externamente, o diretório continua a ser a fonte da associação.

A utilização das definições do utilizador ou do grupo por uma regra ou política depende da seleção efetiva de utilizadores e grupos. No utilizador, em Policies, verifique se foi selecionado um valor próprio em vez da configuração do grupo. Se a política de grupo tiver de voltar a ser aplicada, reponha especificamente o estado de herança previamente documentado e teste novamente apenas a função afetada. Uma substituição continua a ser útil se estiver expressamente documentada uma exceção justificada.

A Sophos distingue dois casos para a seleção na regra ou política afetada:

Apenas o grupo selecionado: A firewall utiliza as definições do grupo, não automaticamente a substituição do utilizador.
O utilizador e o seu grupo selecionados: A firewall utiliza as definições do utilizador.

Um teste piloto limitado torna a diferença visível: para auth-pilot@example.com em Local_Contractors, registe um valor de grupo A e um valor de utilizador diferente B para a mesma definição suportada. A e B representam dois valores de teste deliberadamente planeados no seu ambiente. Numa regra ou política de teste isolada com seleção de utilizadores e grupos, verifique primeiro a seleção efetiva: apenas Local_Contractors significa A; auth-pilot@example.com juntamente com Local_Contractors significa B. Teste o serviço ou o percurso de dados afetado com um novo início de sessão em cada caso; para o tráfego da firewall, verifique também o Firewall Rule ID. Depois, reponha a seleção anteriormente registada e ambas as definições e volte a testar. Não alargue uma regra de produção nem altere a ordem dos grupos para este teste.

Esta seleção não é a ordem da Main Group. Continuam a aplicar-se as limitações do suporte para vários grupos e a combinação das políticas SSL-VPN correspondentes descritas abaixo; isto não estabelece uma prioridade universal das políticas de utilizador para todos os serviços.

A criação completa de políticas de tempo de acesso, quotas de navegação e de tráfego de rede e MFA para a Sophos Firewall é explicada nos respetivos artigos especializados. No objeto de grupo, atribua apenas uma política previamente planeada.

Enquadrar os campos de grupo na API XML

Quem gere grupos de forma automatizada encontra no modelo XML UserGroup como objeto de grupo, GroupDetail como corpo de configuração e GroupMembers com GroupName e UserName como dados de associação. Isto não é uma importação de associações a grupos do AD; para os utilizadores de diretório, o diretório continua a ser a fonte determinante. A autenticação, os invólucros explícitos das operações e a avaliação da resposta XML são abordados em Utilizar a API XML com segurança.

O excerto seguinte mostra apenas a estrutura documentada para os exemplos piloto existentes. Não é um pedido Add/Edit completo nem testado num equipamento; em particular, faltam o invólucro da operação e outros campos de configuração necessários. A omissão de campos não implica que uma alteração preserve os valores existentes.

<UserGroup>
  <GroupDetail>
    <Name>Local_Contractors</Name>
    <LoginRestriction>SelectedNodes</LoginRestriction>
    <NodeList>
      <IPAddress>192.0.2.10</IPAddress>
    </NodeList>
  </GroupDetail>
  <GroupMembers>
    <GroupName>Local_Contractors</GroupName>
    <UserName>auth-pilot@example.com</UserName>
  </GroupMembers>
</UserGroup>

O nome do grupo e o utilizador devem ser substituídos pelos valores do destino local especificamente planeado. 192.0.2.10 é um endereço IPv4 reservado para documentação e deve ser substituído por uma origem de início de sessão permitida e efetivamente necessária. Os nomes dos campos XML permanecem inalterados. A correspondência com os campos da interface é a seguinte:

SurfingQuotaPolicy: Surfing quota; AccessTimePolicy: Access time.
DataTransferPolicy: Network traffic; QoSPolicy: Traffic shaping.
SSLVPNPolicy: SSL VPN policy; ClientlessPolicy: Clientless SSL VPN policy, não o tipo de grupo Clientless.
SophosConnectClient: IPsec remote access através do Sophos Connect Client.

Para LoginRestriction, o exemplo de referência distingue AnyNode, SelectedNodes e NodeRange. AnyNode corresponde a Any node e não limita a origem do início de sessão; não é uma predefinição para resolução de problemas. SelectedNodes utiliza NodeList com as entradas individuais IPAddress. NodeRange utiliza, em alternativa, FromIP e ToIP, por exemplo, de 192.0.2.10 a 192.0.2.20. Ambos os limites do intervalo são também valores de documentação e devem ser substituídos pelo menor intervalo IPv4 necessário, sem alargar as restrições existentes. Embora a tabela assinale FromIP e ToIP como campos obrigatórios, a respetiva descrição limita-os a Node range; daí não resulta uma obrigatoriedade geral para as outras variantes.

A referência da API indica Enable ou Disable para cada um dos campos QuarantineDigest, MACBinding, L2TP, PPTP e SophosConnectClient e documenta Disable como predefinição. Esta é informação de referência, não uma prova do estado do grupo atualmente guardado. Quando QuarantineDigest está ativo, o resumo da quarentena é enviado diariamente por correio eletrónico. PPTP continua excluído de novas implementações; L2TP continua a ser apenas a opção de compatibilidade limitada acima enquadrada.

Limitações do exemplo de referência: O exemplo separa as definições para grupos Normal de um ramo Clientless que apresenta QoSPolicy. No entanto, é contraditório quanto a GroupType: o modelo contém Normal/Clienless, a descrição indica Normal ou Clientless e identifica o tipo de dados como INTEGER. Além disso, o modelo contém marcadores de posição com dois-pontos em vez de conteúdos XML completos. Não se pode deduzir daí uma codificação Clientless corrigida nem uma correspondência numérica. Para uma operação de escrita, utilize um valor lido ou exportado da versão instalada cuja correspondência já esteja estabelecida; caso contrário, utilize o procedimento seguro na interface. Alternativas separadas por uma barra, como Enable/Disable, não são valores únicos a adotar.

O modelo também apresenta After com um Name nele aninhado como indicação de posição. A segunda linha da tabela para Name menciona moveto, mas não comprova uma operação executável de forma autónoma. Uma alteração de posição deve ser tratada como Reorder: pode alterar a Main Group. Registe previamente a ordem, as associações a grupos, o estado atual e pretendido das políticas e o procedimento de reposição; depois, verifique com o utilizador piloto e, em caso de efeito inesperado, reponha a ordem guardada. O modelo não comprova nem o comportamento de substituição ou combinação de GroupMembers nem a semântica de atualização de After ou dos campos omitidos.

Antes de uma operação de escrita Add/Edit de âmbito estritamente limitado, registe o nome de destino e o estado pretendido. Depois, avalie o resultado efetivo da operação XML, volte a ler exatamente o grupo identificado pelo nome e execute os testes positivos e negativos acima descritos no serviço afetado. Para Add e Edit, a referência associa 502 à chave UserGroupRecordExists e 503 à chave UserGroupDuplicateIPInLoginRestriction. Perante um resultado correspondente, verifique primeiro o nome pretendido do grupo existente ou os endereços duplicados em SelectedNodes, respetivamente. Não volte a enviar indiscriminadamente nem alargue LoginRestriction. Estas correspondências comprovam chaves de referência, não mensagens de execução apresentadas e observadas aqui.

Importar grupos de diretórios de forma controlada

Grupos do Active Directory

Aceda a Authentication > Servers e inicie o assistente de importação para o servidor AD configurado. Num cluster HA, a importação tem de ser feita no Primary. O assistente apenas importa os grupos selecionados. Por isso, um grupo criado posteriormente no AD não aparece automaticamente e tem de ser importado numa nova execução do assistente.

Antes da importação, a consulta ao AD tem de funcionar: o servidor necessita dos valores corretos de NetBIOS domain e Domain name, de um ADS username com permissões para pesquisar, ler e consultar associações a grupos, bem como da respetiva Password. Não é necessária uma conta de administrador de domínio para importar grupos. Connection security disponibiliza SSL/TLS como predefinição e STARTTLS como alternativa encriptada; Plaintext transmite as credenciais sem encriptação e não é uma solução segura para produção. O Port tem de corresponder ao tipo de ligação escolhido. Para Validate server certificate, o certificado do servidor AD é carregado em Certificates > Certificates > Add > Upload certificate; Server IP/domain tem de utilizar o CNAME indicado no certificado. Se a firewall não conseguir resolver esse nome, deve verificar a resolução DNS interna ou Network > DNS > DNS host entry. A configuração completa do servidor continua a estar descrita no artigo sobre AD acima indicado.

As Search queries limitam o conjunto de utilizadores abrangidos. Por exemplo, OU=VPN_Users,DC=example,DC=com pesquisa na OU VPN_Users do domínio de documentação example.com; a OU e os componentes do domínio têm de ser substituídos pelo Distinguished Name real. Uma base de pesquisa mais restrita mantém o conjunto de utilizadores controlável, mas não pode excluir os utilizadores previstos. Só os utilizadores abrangidos podem aparecer como Live Users através deste servidor. Test connection verifica a ligação e as credenciais, mas ainda não comprova a atribuição correta de grupos a um utilizador normal. A imposição estrita de LDAP Channel Binding e LDAP Signing não é suportada; um requisito de segurança do AD nesse sentido deve ser esclarecido antes da integração, e não contornado como se fosse um erro de grupos.

O processo de importação propriamente dito decorre da seguinte forma:

No servidor AD previsto, clique em Import e inicie o Import group wizard com Start.
Selecione a Base DN adequada para a pesquisa de grupos. Esta deve abranger os grupos necessários e deve ser distinguida da base de pesquisa de utilizadores.
Selecione apenas os grupos AD previstos, por exemplo, SFOS_Internet_Standard e SFOS_SSLVPN.
Selecione as políticas comuns dos grupos; depois, verifique a seleção e os resultados.
Em Authentication > Groups, verifique ambos os grupos e as respetivas políticas. O assistente importa grupos, não todos os registos de utilizadores ou associações a grupos de imediato.
Em Authentication > Services > Firewall authentication methods, confirme que o servidor AD está selecionado para o serviço previsto. Se, neste procedimento de configuração, o AD tiver de ser consultado primeiro, mova o servidor para a primeira posição e clique em Apply. Num ambiente existente, mantenha a ordem dos servidores previamente planeada, em vez de a alterar indiscriminadamente.

Os grupos AD aninhados não são avaliados. Se um subgrupo tiver de ser aplicado a uma regra de firewall ou política de VPN, esse subgrupo específico deve ser importado. O grupo AD primário de um utilizador também não é adotado como associação normal. Para as políticas, os grupos de segurança explícitos são, por isso, mais adequados do que o grupo predefinido do AD Domain Users.

Isto não se aplica apenas a Domain Users: se, por exemplo, SFOS_Internet_Standard se tornar o grupo AD primário do utilizador, essa associação específica não será adotada como uma associação normal ao AD. Assim, o próximo grupo importado correspondente pode tornar-se a Main Group. A Main Group da firewall é determinada a partir da sua própria lista de grupos e não é o grupo primário no AD.

Após alterações nas associações a grupos do AD, nos grupos importados ou na ordem dos grupos, o utilizador deve iniciar novamente a sessão. Só então a firewall volta a avaliar os grupos e atualiza o objeto do utilizador.

Se STAS e Synchronized User ID estiverem configurados em simultâneo, o servidor de autenticação utiliza o mecanismo do qual receber primeiro o pedido de início de sessão. Se os testes piloto produzirem resultados diferentes, verifique também Client Type, em vez de reordenar imediatamente os grupos ou os servidores.

Grupos Entra

Para a importação de grupos do Entra, o registo da aplicação no Microsoft Graph requer a permissão de aplicação Group.Read.All com Admin Consent. Os relógios da firewall e do Microsoft Entra ID devem estar sincronizados; caso contrário, a ligação pode falhar.

Depois, vá a Authentication > Servers e clique no assistente de importação de grupos do servidor Microsoft Entra ID. É possível importar todos os grupos ou apenas os grupos cujo Display name ou Description corresponda a um filtro. Surfing quota, Access time, Network traffic e Traffic shaping podem ser atribuídos a todos os grupos importados ou a grupos individuais. Os grupos recém-importados devem também ser incluídos nas políticas de acesso remoto IPsec ou SSL VPN utilizadas; a importação, por si só, não concede acesso VPN.

Avaliar corretamente a Main Group e vários grupos

Abra o utilizador em Authentication > Users e desloque-se até Policies:

Group mostra o primeiro grupo correspondente na lista da firewall e, portanto, a Main Group.
Other group memberships mostra outros grupos AD importados do utilizador.

Dois campos adicionais aparecem em Policies apenas quando, para cada um deles, se verificam ambas as condições:

Group SSL VPN policies: O utilizador pertence a vários grupos AD e pelo menos dois desses grupos estão incluídos em políticas de acesso remoto SSL VPN.
Group clientless SSL VPN policies: O utilizador pertence a vários grupos AD e pelo menos dois desses grupos estão incluídos em políticas SSL VPN sem cliente.

Se um destes campos não aparecer, verifique primeiro as associações a grupos do AD, os grupos importados e a sua inclusão na respetiva política de VPN. A associação a vários grupos AD, por si só, não é suficiente para que o campo seja apresentado. Não alargue as permissões de VPN em produção apenas para tornar o campo visível. Além disso, a apresentação do campo não constitui um teste de acesso; a combinação efetiva das permissões é explicada mais abaixo.

Em Authentication > Groups > Reorder, pode alterar a ordem por arrastar e largar. Clique em Close para fechar a caixa de diálogo. Se auth-pilot@example.com pertencer a SFOS_Internet_Standard e a SFOS_SSLVPN, o grupo correspondente que estiver mais acima na lista será definido como a Main Group no próximo início de sessão.

Esta ordem não se aplica apenas ao caso de erro atual. Antes de fazer uma alteração, verifique se a função afetada suporta outros grupos. Caso contrário, uma mudança de posição pode resolver um caso de VPN e, ao mesmo tempo, alterar a MFA, a quota ou os horários de acesso de outros utilizadores.

Funções com suporte para vários grupos AD

A seguinte matriz aplica-se expressamente ao Active Directory. Não deve ser aplicada a LDAP, RADIUS ou Microsoft Entra ID sem verificação prévia.

Podem ser considerados vários grupos AD em:

Firewall rules e SSL/TLS inspection rules;
SD-WAN routes;
Web policies;
IPS e Application control policies;
Policy test;
Remote access SSL VPN;
Clientless SSL VPN.

Em Remote access SSL VPN, as permissões das políticas de utilizador e de grupo correspondentes são combinadas. Se estiver envolvida uma política de túnel completo aplicável, o resultado será um Full Tunnel. Verifique esta combinação com um teste real de cliente.

Em Clientless SSL VPN, são consideradas as permissões de todas as políticas às quais pertença um dos grupos AD do utilizador. Por isso, verifique não só a política esperada, mas também os marcadores ou recursos adicionais disponibilizados por outros grupos.

Os Hotspots têm em conta exclusivamente a Main Group.

Só são consideradas a Main Group ou uma atribuição explícita ao utilizador em:

WAF rules e My policy overrides;
Remote access IPsec VPN, L2TP e PPTP;
Surfing quota, Access time, Network traffic e Traffic shaping;
Quarantine digest, MAC binding e Sign-in restriction;
MFA.

No WAF, L2TP, PPTP e Remote access IPsec, a política de utilizador pode apresentar Enable, embora a permissão resulte apenas de Other group memberships e, por isso, o acesso não seja permitido. Avalie estes serviços com base na Main Group ou numa atribuição direta ao utilizador, e não apenas no que é apresentado.

Nas funções com suporte para vários grupos, a ordem da respetiva regra ou política continua a determinar o resultado. Uma regra de firewall pode ser aplicada através de SFOS_SSLVPN, embora SFOS_Internet_Standard seja a Main Group. Isto não significa que a MFA ou a quota também utilizem SFOS_SSLVPN.

Nas Web policies, existem duas decisões distintas: primeiro, a regra de firewall correspondente determina a política Web. Nessa política, aplica-se a primeira regra que corresponda tanto ao utilizador como ao site. Se o utilizador piloto pertencer aos dois grupos do exemplo e a primeira regra Web bloquear sites de desporto para SFOS_SSLVPN, um site de desporto será bloqueado, mesmo que SFOS_Internet_Standard seja a sua Main Group e uma regra posterior permita notícias para esse grupo. Por outro lado, IPS e Application control utilizam a política da regra de firewall correspondente; a ordem dos grupos não provoca uma combinação adicional destas políticas.

Para a MFA, em vez de selecionar um grupo, pode incluir explicitamente o utilizador ou aplicar a MFA a todos os utilizadores. Uma permissão apenas através de Other group memberships não é suficiente. Os Hotspots no User Portal dependem exclusivamente da Main Group; outro grupo AD não alarga esta lista.

Verificar o efeito dos grupos

Um grupo guardado e um utilizador visível ainda não são uma prova de sucesso:

Termine a sessão atual do utilizador piloto e volte a iniciá-la.
Em Authentication > Users > utilizador > Policies, registe o estado, Group, Other group memberships e possíveis substituições.
Em Current activities > Live users, verifique o nome de utilizador, o IP de origem e Client Type.
Para uma regra de firewall baseada no utilizador, gere o tráfego previsto e verifique o Firewall Rule ID no Log Viewer.
Teste Access Time, Quota, MFA e Remote Access individualmente através do serviço realmente afetado.
Repita o mesmo teste com um utilizador fora do grupo piloto como teste negativo.

Para verificar a quota, abra Authentication > Users > utilizador > View usage. Os dados de utilização só estão disponíveis se uma regra de firewall baseada no utilizador processar o tráfego e Log firewall traffic estiver ativado.

Verificar regras de firewall com Log Viewer, Policy Test e Packet Capture mostra o teste completo de tráfego. Se a escolha do serviço, a identidade ou a Main Group já não estiverem claras, Corrigir erros de autenticação da Sophos Firewall de forma sistemática percorre toda a cadeia de verificação.

Reverter alterações e limpar grupos

Altere apenas uma política de grupo ou uma posição de cada vez. Se o teste piloto produzir um resultado inesperado, reponha a ordem e a atribuição de política registadas, volte a iniciar a sessão do utilizador e repita os testes positivo e negativo.

Os grupos AD são primeiro eliminados no diretório e depois, separadamente, em Authentication > Groups na firewall. Purge AD users não elimina grupos.

Para os utilizadores AD, aplica-se o seguinte:

Elimine primeiro o utilizador no AD. Enquanto existir no diretório, a firewall poderá recriá-lo num início de sessão posterior.
Em Authentication > Users, clique em Purge AD users. Não é necessário selecionar previamente os utilizadores; a firewall verifica o servidor AD e remove apenas os utilizadores já eliminados no diretório.
Em HA, inicie o procedimento no Primary. Os registos são removidos no Primary e no Auxiliary. A limpeza não interrompe Sign-in, Sign-out nem User Accounting.

Uma exportação da configuração contém grupos AD importados e criados localmente, mas não inclui utilizadores de servidores de autenticação externos. Uma cópia de segurança completa, por outro lado, inclui todos os utilizadores e grupos. Tenha esta limitação em conta se o procedimento de reposição não abranger apenas uma única alteração de política.

Eliminar com segurança um grupo identificado pelo nome através da API

Antes de qualquer eliminação, defina o Name exato do grupo de destino e salvaguarde as políticas, a ordem, os membros e as utilizações. O facto de a tabela mais antiga da API assinalar Name como não obrigatório não autoriza uma eliminação sem nome: a descrição exige um nome para identificar o objeto. Verifique previamente os utilizadores efetivos do grupo, as atribuições de VPN, incluindo L2TP/IPsec, a seleção para autenticação externa, as referências em regras de firewall e a utilização como grupo predefinido de convidados. Se o grupo ainda for necessário, execute uma migração expressamente planeada e de âmbito estritamente limitado ou interrompa o procedimento. Não force a remoção, não efetue uma limpeza de utilizadores nem flexibilize os acessos apenas para conseguir concluir a eliminação. A sequência do AD acima descrita e a separação relativamente a Purge AD users mantêm-se.

A referência de eliminação associa linhas de resultados a chaves de mensagens JavaScript relativas a estas dependências. Isto comprova estas categorias de verificação, não os textos apresentados das mensagens em falta nem um erro observado aqui num equipamento. Para a construção do pedido e o tratamento do resultado XML, aplica-se Utilizar a API XML com segurança; a referência de eliminação de grupos não fornece um exemplo de payload, pelo que não se inventa aqui um invólucro Delete. Em caso de rejeição, mantenha o grupo e verifique especificamente a referência indicada no resultado. Mesmo após um resultado de sucesso, volte a ler exatamente o destino, confirme a sua ausência e repita os testes de serviço e de acesso previstos.

Os utilizadores e os grupos partilham o intervalo de IDs internos até 65535. Um número elevado de objetos visíveis, por si só, não comprova um problema de limite. Se um utilizador apresentar um User ID superior a 65535 e não se tornar um utilizador ativo, o comportamento corresponde ao limite de ID de utilizador da Sophos Firewall.

Delimitar os erros por sintoma

Após cada correção, volte a iniciar a sessão do utilizador afetado e verifique Group e Other group memberships. Depois disso, basta um próximo passo direcionado para cada sintoma.

O novo grupo AD não aparece

Volte a iniciar o assistente de importação do servidor AD e, em HA, execute-o no Primary. Em seguida, verifique em Authentication > Groups se o grupo específico necessário está presente. Não crie um grupo de substituição com permissões abrangentes apenas para que o início de sessão funcione.

O utilizador LDAP é colocado no grupo predefinido

Verifique no servidor LDAP Base DN, Authentication attribute e Group name attribute; depois, em Authentication > Services, verifique a ordem dos servidores e Default group. Execute Test connection para o servidor LDAP. O assistente de importação do AD não é responsável por este mapeamento.

O utilizador Entra é colocado no grupo de fallback

Verifique se o grupo Entra foi importado e se o token fornece o grupo esperado. Em seguida, verifique Fallback user group diretamente no servidor Entra. O Default group geral em Authentication > Services não é utilizado para este mapeamento.

O utilizador tem a Main Group errada

Compare as associações a grupos do AD, os grupos importados e a ordem atual. Verifique a nova ordem apenas após o próximo início de sessão e com vários utilizadores representativos.

A regra de firewall é aplicada, mas a MFA ou a quota não

As regras de firewall suportam outros grupos AD, mas a MFA e as quotas não. Em Authentication > Users > utilizador > Policies, verifique a Main Group, possíveis substituições e a atribuição efetiva da política. O efeito da regra não prova que a MFA ou a quota avaliem o mesmo grupo.

A alteração do grupo não produz efeito para apenas um utilizador

Compare os campos de política específicos do utilizador e a seleção efetiva de utilizadores e grupos na regra ou política afetada: selecionar apenas o grupo utiliza os valores do grupo; selecionar o utilizador e o seu grupo utiliza os valores do utilizador. Verifique também as limitações da função quanto à Main Group e ao suporte para vários grupos. Reponha o valor do grupo apenas quando a exceção documentada já não for necessária.

O grupo AD aninhado não é aplicado

Importe o próprio subgrupo necessário e inclua diretamente o utilizador nesse grupo. Importar apenas o grupo superior não é suficiente.