Configurar Per-Connection AD SSO para hosts multiutilizador na Sophos Firewall

Vários utilizadores trabalham no mesmo Remote Desktop Session Host, mas a Sophos Firewall vê apenas um IP de servidor em todas as ligações. O Per-Connection AD SSO resolve precisamente este caso especial para tráfego Web: o Direct Web Proxy autentica separadamente cada ligação HTTP e HTTPS com Kerberos ou NTLM.

A função não se limita ao Windows RDS: um servidor Linux multiutilizador também pode utilizar este modelo de ligação, desde que os seus clientes suportem o Direct Web Proxy e Kerberos ou NTLM. Este exemplo acompanha um piloto Windows RDS; os comandos Windows e a distribuição por GPO não constituem um guia para Linux. Os hosts fora da lista Multi-user hosts mantêm a autenticação baseada em IP anteriormente configurada.

O limite é tão importante como a função. Apenas as ligações que o navegador ou a aplicação envia explicitamente para o proxy recebem uma identidade de utilizador. DNS, RDP, SMB e outro tráfego fora do proxy proveniente do mesmo IP de servidor permanecem sem autenticação. Se estes protocolos também tiverem de ser controlados por utilizador, o SATC para Remote Desktop Services é mais adequado.

⚠️ Assim que um endereço IP é adicionado a Multi-user hosts, deixa de utilizar outros métodos de autenticação baseados em IP. STAS, Captive Portal, Clientless User e AD SSO transparente deixam de estar disponíveis para esse IP. Por isso, deve começar-se por testar com exatamente um servidor piloto e documentar o percurso de autenticação existente.

Per-Connection AD SSO em nove passos

1. Decidir se apenas HTTP e HTTPS devem realmente ser tratados por utilizador através de um proxy explícito.
2. Verificar o Active Directory, a importação de grupos, o DNS, a hora e a adesão da firewall ao domínio.
3. Preparar um FQDN da firewall que possa ser resolvido e um HTTP-SPN correspondente para Kerberos.
4. Avaliar primeiro o âmbito e o impacto na segurança; depois ativar AD SSO para a zona LAN necessária em Administration > Device access e selecionar Apply. Limitar separadamente Web proxy ao host piloto com uma exceção ACL específica, se suportada; uma exceção Accept não restringe permissões de zona. Se a permissão necessária for inaceitável, interromper a implementação e obter um desenho suportado de âmbito restrito.
5. Criar o servidor RDS como objeto de host IP com o endereço exato.
6. Ativar o Per-Connection AD SSO para este host em Authentication > Web authentication.
7. Configurar os navegadores e as aplicações com suporte de proxy para o FQDN da firewall e a porta 3128.
8. Colocar uma regra dedicada ao host, com registo de logs, antes das regras de utilizador concorrentes e manter Match known users desativado.
9. Verificar separadamente duas sessões RDS em paralelo, resultados diferentes de Web Policy e tráfego fora do proxy.

Per-Connection AD SSO, STAS ou SATC?

Os três métodos fornecem contexto de utilizador, mas resolvem tarefas diferentes.

• STAS é adequado para clientes Windows normais, quando um IP de cliente pertence normalmente a um único utilizador. A firewall recebe uma associação entre utilizador e IP a partir dos eventos de início de sessão do Windows.
• Per-Connection AD SSO é adequado para hosts multiutilizador quando apenas é necessário distinguir ligações HTTP e HTTPS encaminhadas explicitamente através do proxy. Não é necessário um agente SATC no servidor RDS, mas todas as aplicações têm de utilizar o Direct Web Proxy de forma fiável.
• SATC é adequado para sistemas Windows RDS suportados quando outros tipos de ligação das sessões individuais dos utilizadores também precisam de uma identidade. Para tal, é necessário Sophos Server Protection no Session Host. O guia atual da Sophos não confirma a possibilidade de uma nova implementação Citrix; antes de alterar instalações Citrix existentes, deve consultar-se o Sophos Support.

O STAS clássico na Sophos Firewall não consegue distinguir vários utilizadores atrás do mesmo IP de RDS. Por isso, Per-Connection AD SSO e SATC não são variantes mais cómodas do STAS, mas sim modelos de funcionamento próprios. O SATC também só associa processos baseados em utilizadores; as ligações geradas por serviços de sistema continuam a precisar de uma regra própria sem Match known users. Se uma aplicação não suportar um proxy explícito ou se for necessário aplicar regras por utilizador a protocolos não Web, deve parar aqui e avaliar o SATC.

Exemplo e valores a substituir

O procedimento utiliza este exemplo:

• Host multiutilizador: RDS01
• Endereço IP: 10.20.30.40
• FQDN da firewall e destino do proxy: fw01.corp.example
• Porta do Direct Web Proxy: 3128
• Grupos AD: RDS-Web-Standard e RDS-Web-Restricted
• Uma conta piloto por grupo, com resultados de Web Policy intencionalmente diferentes

10.20.30.40 deve ser substituído pelo IP fixo do servidor piloto, tal como é visto pela firewall. Não devem aparecer outros sistemas atrás deste endereço através de NAT. fw01.corp.example é um nome de documentação e tem de ser substituído pelo FQDN real da firewall, resolúvel internamente. A parte correspondente ao host deve ter, no máximo, 15 caracteres e estar em minúsculas, para que o hostname, o nome NetBIOS, o objeto de computador AD e o SPN correspondam entre si.

A porta 3128 é a predefinição do Direct Web Proxy. Se o ambiente utilizar outra porta de escuta, a firewall, o ficheiro PAC ou a GPO, os navegadores e os testes têm de utilizar o mesmo valor. Os grupos do exemplo servem apenas para tornar os testes de aceitação mais claros; os nomes dos grupos e as Web Policies têm de corresponder à estrutura de permissões do próprio ambiente.

Preparar os pré-requisitos

Verificar o Active Directory e a adesão ao domínio

A firewall precisa de um servidor Active Directory funcional, de grupos importados e de uma adesão ao domínio bem-sucedida. Ligar o Active Directory à Sophos Firewall explica LDAPS, a base de pesquisa, a importação de grupos e os pré-requisitos gerais de AD SSO.

Se o servidor AD ainda não estiver configurado, selecionar o tipo Active Directory em Authentication > Servers > Add. Introduzir o nome do servidor, o IP ou FQDN acessível do DC, o domínio NetBIOS, o domínio AD e a base de pesquisa do próprio ambiente. Para corp.example, a base de pesquisa é dc=corp,dc=example. Encriptar a ligação com SSL/TLS na porta 636 ou STARTTLS na porta 389 e preparar a verificação do certificado de acordo com o procedimento AD indicado no artigo ligado. Introduzir a conta de leitura/adesão com os direitos descritos abaixo, executar Test connection e guardar com Save. Não substituir um servidor AD já utilizado apenas para o piloto nem alterar as respetivas credenciais sem verificação. Se o domínio impuser vinculação de canal LDAP estrita ou assinatura LDAP, esclarecer a compatibilidade no procedimento AD antes da implementação; a ajuda da Sophos para servidores AD indica uma limitação neste âmbito. Não desativar um requisito de proteção de todo o domínio para resolver problemas.

Na importação de grupos, a seleção de uma unidade organizacional (OU) seleciona automaticamente todos os grupos nela contidos. Attach to all the Groups atribui as políticas comuns selecionadas a cada grupo importado pelo assistente. Antes de concluir, verificar por isso a lista de grupos alargada pela seleção da OU e o âmbito destas políticas; aceitar apenas os grupos efetivamente necessários e as atribuições de políticas pretendidas.

Para o piloto, abrir Import no servidor AD em Authentication > Servers > Manage, iniciar o Import group wizard com Start e selecionar a Base DN adequada. Para o domínio de exemplo corp.example, é dc=corp,dc=example; devem substituir-se os componentes do domínio, não a sintaxe LDAP. Selecionar RDS-Web-Standard e RDS-Web-Restricted, verificar a atribuição comum de políticas e o resumo, concluir o assistente e fechar com Close. Em seguida, verificar em Authentication > Groups se ambos os grupos estão realmente presentes. Uma adesão ao domínio bem-sucedida, por si só, não importa os grupos necessários para as políticas.

Para a consulta LDAP normal, basta uma conta com direitos de leitura. Já a adesão ao domínio e a criação do SPN requerem uma conta Domain Admin ou uma conta com direitos devidamente delegados. A conta configurada também tem de permitir uma nova adesão posterior, porque HA, servidores AD adicionais ou atualizações podem voltar a desencadeá-la. Não se deve utilizar permanentemente uma conta Domain Admin sem restrições para este fim sem necessidade.

Em Authentication > Services > Firewall authentication methods, selecionar o servidor AD previsto e colocá-lo na ordem correta. Quando existem vários servidores, a firewall verifica-os de cima para baixo. Test connection no servidor AD confirma apenas as credenciais e a acessibilidade, não a autenticação posterior com Kerberos ou NTLM no navegador.

Na mesma área, selecionar deliberadamente a Default group e guardar com Apply. Se o grupo AD necessário não estiver importado, um utilizador autenticado com sucesso pode ficar no grupo predefinido em vez de receber a política do grupo pretendido. Os utilizadores de uma OU que não pertençam a um grupo do diretório podem aparecer na Open group. Se um utilizador pertencer a vários grupos, o primeiro grupo correspondente pode determinar a política; por isso, deve verificar-se não só a importação, mas também a ordem e a associação efetiva. Para o piloto, não utilizar um grupo predefinido com permissões amplas como substituto de uma importação em falta. No primeiro novo início de sessão, verificar a associação efetiva ao grupo em Authentication > Users; um objeto de utilizador não tem de estar visível antes desse início de sessão.

Verificar FQDN, DNS, SPN e hora

O Kerberos só funciona se os clientes utilizarem o FQDN da firewall como destino do proxy. Um endereço IP do proxy não é suficiente. Num cliente piloto Windows, estas verificações de leitura são úteis:

Resolve-DnsName fw01.corp.example
setspn -Q HTTP/fw01.corp.example
w32tm /query /status

O HTTP-SPN, por extenso Service Principal Name, associa o FQDN do proxy ao objeto de computador AD da firewall. setspn -Q deve devolver exatamente uma associação correspondente. Se não houver resultados ou se houver vários, a situação tem de ser esclarecida antes da implementação.

O sufixo DNS configurado no campo Hostname não é automaticamente o sufixo AD: durante a adesão ao domínio, a firewall constrói o nome de computador AD e o SPN a partir do seu nome NetBIOS e do domínio AD. Se o domínio DNS e o domínio AD forem diferentes, comparar o FQDN registado no objeto de computador AD com o destino do proxy planeado. O exemplo pressupõe um SPN correspondente a fw01.corp.example; a simples introdução deste nome em Admin and user settings não o comprova. Primeiro, esclarecer em conjunto o DNS e o SPN para o destino real do proxy e só depois distribuir a configuração do proxy. Não criar SPNs adicionais por tentativa.

A resposta DNS tem de corresponder à firewall prevista. O cliente, o Domain Controller e a firewall também precisam de uma hora compatível com o funcionamento do Kerberos. Os comandos não alteram nada. Não corrigir o SPN, a adesão ao domínio ou a configuração da hora por tentativa; primeiro, comprovar o erro efetivo.

Identificar o suporte de proxy e as exceções

Cada navegador e cada aplicação cujo tráfego Web deva receber um utilizador tem de utilizar o proxy explícito e suportar Kerberos ou NTLM; no exemplo Windows RDS, isto é feito através da autenticação integrada do Windows. Antes da implementação, verificar pelo menos:

• Os navegadores em cada sessão RDS suportada
• As aplicações com uma pilha HTTP própria
• As atualizações do Windows e de software
• Os serviços que são executados no contexto do sistema em vez de numa sessão de utilizador
• Os destinos presentes no ficheiro PAC ou na lista de bypass do proxy

O tráfego que contorna o proxy permanece, como esperado, sem ID de utilizador. Para as ligações de máquina necessárias, planear uma regra própria, com âmbito restrito e sem associação a utilizadores. Uma regra Any abrangente enfraqueceria o efeito de segurança das políticas de utilizador e Web.

Configurar Per-Connection AD SSO

1. Preparar o FQDN da firewall e AD SSO

Em Administration > Admin and user settings, introduzir o FQDN previsto para a firewall e guardar com Apply. Em seguida, em Authentication > Web authentication, selecionar a opção Kerberos & NTLM em If Active Directory (AD) SSO is configured e guardar também com Apply. O NTLM é tecnicamente suportado como fallback; o Kerberos é mais rápido e mais seguro e deve funcionar de forma fiável no piloto. Como cada ligação ao proxy pode desencadear uma autenticação, antes de uma implementação mais alargada devem também observar-se os erros de autenticação, os tempos de resposta e a carga da firewall e do AD com tráfego representativo. Não deduzir daí um multiplicador de carga fixo nem uma capacidade de utilizadores garantida.

Se os dispositivos finais não estiverem devidamente configurados para Kerberos ou se o navegador não suportar autenticação Kerberos, é utilizado automaticamente NTLMv2 como fallback. Ao contrário do Kerberos, o NTLMv2 não necessita de um FQDN como destino do proxy. No entanto, este fallback de compatibilidade não garante uma autenticação bem-sucedida: os canais de autenticação descritos abaixo têm de estar inicializados e o percurso de autenticação efetivo tem de ser verificado com as contas piloto.

No Log Viewer, em Authentication, têm de aparecer estas mensagens de sucesso após a inicialização de AD SSO:

• Kerberos authentication initialized successfully
• NTLM authentication channel established successfully

A firewall só disponibiliza os métodos quando ambos os canais funcionam. Cannot initialize Kerberos authentication ou Cannot establish NTLM authentication channel são sinais para parar, não instruções para reiniciar um serviço sem diagnóstico.

2. Restringir as permissões de Device Access

A Sophos exige ativar AD SSO para a zona LAN necessária em Administration > Device access e selecionar Apply como pré-requisito para Kerberos/NTLM. Avaliar primeiro o âmbito da permissão de zona e o impacto na segurança; não abrir toda a LAN sem essa análise. Desativar AD SSO em todas as zonas impede Kerberos/NTLM, e uma exceção ACL de AD SSO limitada a um host não substitui este pré-requisito. Adicionar uma exceção Accept não restringe uma permissão de zona existente. Se a permissão necessária for inaceitável, interromper a implementação e obter junto do responsável pelas ACL ou do Sophos Support um desenho suportado e de âmbito restrito para a compilação instalada. Separadamente, limitar a acessibilidade de Web proxy a partir da origem ao host piloto através de uma Local service ACL exception rule específica, se suportada. Uma exceção Accept não restringe uma permissão Web proxy já ativa para toda a zona; essa permissão abrangente não pode permanecer ativa para um acesso realmente limitado ao host. Não ativar outras zonas nem serviços desnecessários. A configuração completa é explicada em Device Access e Local Service ACL.

O acesso ao Web Proxy tem um efeito secundário importante: um host autorizado pode aceder aos serviços HTTP e HTTPS da firewall através do proxy, mesmo que a respetiva zona não esteja autorizada na matriz normal de serviços locais. Por isso, testar negativamente o acesso ao WebAdmin, User Portal e a outros destinos locais a partir do host piloto. Se esta exposição não for aceitável na própria rede, não ativar o desenho em produção.

Em Web > General settings, verificar o Web proxy listening port efetivo e as portas de destino permitidas. Alterar a predefinição 3128 apenas se for possível ajustar de forma consistente o ficheiro PAC, a GPO e todas as aplicações geridas.

3. Criar o host multiutilizador

Criar um novo objeto de host no seguinte caminho:

Hosts and services > IP host > Add

Para o exemplo, são utilizados estes valores:

1. Name: RDS01
2. IP version: IPv4
3. Type: IP
4. IP address: 10.20.30.40

Guardar com Save e verificar se o objeto contém o IP exato do piloto antes de o selecionar na lista multiutilizador.

No primeiro teste, não introduzir um intervalo inteiro nem uma sub-rede. Caso contrário, muitos sistemas poderão perder simultaneamente a autenticação baseada em IP que utilizavam. Após testes de aceitação individuais bem-sucedidos, os vários hosts posteriormente aprovados podem ser reunidos de forma controlada num grupo de hosts.

4. Ativar Per-Connection AD SSO

Aceder a esta área:

Authentication > Web authentication > Authentication settings for direct web proxy

Em seguida:

1. Ativar Use per-connection AD SSO authentication for multi-user hosts.
2. Em Multi-user hosts, adicionar o objeto RDS01 com Add new item.
3. Guardar com Apply.

A partir deste momento, STAS, Captive Portal, Clientless User e AD SSO transparente deixam de estar disponíveis para 10.20.30.40. Por isso, realizar a alteração numa janela de manutenção e não utilizar uma sessão RDS existente como único teste.

Correspondência opcional com a API para automatização

Quem pretender automatizar este passo na interface gráfica encontra a entidade DirectWebProxyAuthentication na referência da API para SFOS 22.0 e 23.0. Esta entidade estabelece a seguinte correspondência com o interruptor e a lista multiutilizador; esta correspondência não constitui um pedido completo executável.

• DirectWebProxyAuthentication > PerConnectionAuth corresponde ao interruptor para ativar ou desativar Per-Connection AD SSO. O parâmetro está documentado como um SCALAR não obrigatório e permite exclusivamente Enable ou Disable. A notação com barra no exemplo da referência indica alternativas, não um terceiro valor permitido.
• DirectWebProxyAuthentication > MultiUserHosts > Host descreve a lista de nomes dos hosts multiutilizador, ou seja, no exemplo, o nome do objeto de host RDS01 criado anteriormente, não o respetivo endereço IP. Host não é obrigatório e está documentado como um ARRAY com o tipo de dados STRING. São permitidos vários valores e, segundo a referência, os valores duplicados são ignorados. A referência indica um máximo de 1500 caracteres, mas não esclarece se este limite se aplica a cada valor ou à lista completa.

As colunas Default estão vazias: daí não se pode deduzir um valor predefinido documentado nem o efeito de omitir campos. A secção da operação também não descreve se uma lista enviada acrescenta entradas às existentes ou as substitui, nem como se removem entradas. Por isso, não interpretar a omissão nem uma lista vazia como uma forma segura de reverter a alteração; antes de automatizar, é necessário esclarecer o comportamento concreto de atualização e remoção para o build utilizado.

A tabela de estados contém 200 e 500. Estes valores de referência não confirmam o estado de transporte HTTP efetivo nem o processamento bem-sucedido de utilizadores e políticas. Os campos de mensagens remetem para JavaScript; a secção da operação fornecida não apresenta mensagens de resposta literais.

Mesmo numa alteração posterior autorizada através da API, continuam a aplicar-se os pré-requisitos acima e o piloto de âmbito restrito com um único host. Antes da alteração, guardar em segurança as definições efetivas e manter disponível um acesso de gestão independente. Depois, voltar a consultar o interruptor e a lista multiutilizador completa exatamente na firewall alterada e comparar com o estado pretendido; em seguida, realizar os testes positivos e negativos de proxy, utilizadores, políticas, tráfego fora do proxy e serviços locais descritos abaixo. Uma resposta de configuração aceite não substitui estes testes de aceitação. Para reverter, restaurar o estado anterior guardado, sem daí deduzir uma sintaxe de eliminação da API que não esteja comprovada.

5. Distribuir o Direct Web Proxy

Definir o proxy do navegador ou do sistema através de GPO, ficheiro PAC ou aplicação gerida para este valor:

fw01.corp.example:3128

Para Kerberos, tem de ser utilizado exatamente o FQDN que corresponde ao SPN. Um endereço IP como destino do proxy, uma forma abreviada que não possa ser resolvida ou outro alias conduz frequentemente a fallback para NTLM ou a um pedido de credenciais. Manter deliberadamente reduzidas as entradas de bypass e documentá-las, porque cada ligação que contorna o proxy não recebe uma identidade Per-Connection.

A configuração geral do listener, do PAC, das regras e do rollback encontra-se em Configurar o Direct Web Proxy com um ficheiro PAC. Este artigo apenas complementa essa configuração com a autenticação multiutilizador.

6. Posicionar uma regra de firewall própria

Em Rules and policies > Firewall rules, criar uma regra de saída própria, com um nome claro, para RDS01. Tem de ficar antes das regras que abrangem o mesmo host com Match known users.

Para este exemplo IPv4, selecionar IPv4 > Add firewall rule > New firewall rule. Definir, por exemplo, RDS01_DirectProxy_Outbound como Rule name e Accept como Action. O nome é de escolha livre; deve permitir identificar o host e a finalidade. Verificar a posição antes das regras de utilizador concorrentes com base na lista completa de regras, não apenas no nome.

O enquadramento seguro:

• Source zones: zona efetiva do RDS, por exemplo LAN
• Source networks and devices: apenas RDS01
• Destination zones: WAN
• Destination networks: apenas os destinos necessários ou, deliberadamente, Any
• Services: HTTP, HTTPS e um serviço TCP próprio para 3128 ou para a porta de escuta do proxy efetivamente configurada; utilizar Any apenas de forma deliberada. Selecionar apenas a porta de escuta não constitui uma seleção completa de serviços para o Direct Proxy.
• Log firewall traffic: ativado
• Match known users: desativado
• Web filtering > Web policy: selecionar a política preparada com dependência de utilizadores ou grupos

As Web Policies podem distinguir utilizadores e grupos dentro do tráfego do proxy, mas só produzem efeito quando estão associadas à regra de firewall. Esta distinção pertence à Web Policy, não a Match known users nesta regra de host. Depois de selecionar ou alterar a Web Policy, verificar novamente o interruptor, porque uma dependência de utilizadores pode voltar a ativá-lo.

Guardar com Save, voltar a abrir a regra e verificar Match known users, o registo de logs, a Web Policy e a posição. A regra de host permite o percurso de tráfego previsto; a Web Policy decide, dentro desse percurso, sobre utilizadores e grupos. Por isso, uma identidade corretamente reconhecida não significa automaticamente a permissão correta.

O guia geral de AD SSO também descreve regras de utilizador com Match known users ativado. Esse não é o modelo de regras para o IP multiutilizador aqui registado: o guia específico de Per-Connection exige expressamente uma regra própria com este interruptor desativado. Também não se deve copiar a correspondência de serviços de uma regra HTTP/HTTPS transparente: a porta de escuta do proxy descreve o percurso do cliente para o proxy, enquanto uma ligação separada do proxy para o destino utiliza serviços de destino como HTTP ou HTTPS. Confirmar no piloto, com base nos logs, a Rule ID efetiva e a porta correspondente. Um cliente IPv6 com um destino IPv4 pode precisar de duas regras; este exemplo IPv4 não constitui um guia completo para dual-stack.

Para DNS, atualizações e outras ligações necessárias fora do proxy, criar uma regra de máquina separada. Não acrescentar uma regra genérica de WAN para LAN; o exemplo de entrada apresentado pela Sophos não é necessário para o acesso Web normal de RDS e, sem uma finalidade própria de publicação, criaria uma superfície de ataque desnecessária. A configuração, a ordem e o registo de logs são explicados em Criar corretamente regras de firewall.

Se existir, independentemente do proxy, uma necessidade justificada de acesso de entrada ao host multiutilizador, Match known users também deve estar desativado na respetiva regra própria. Definir de forma restrita a zona de origem e os hosts de origem autorizados, a zona de destino e RDS01, bem como os serviços efetivamente necessários, ativar o registo de logs e verificar a posição antes das regras de utilizador concorrentes. Isto não é uma recomendação para disponibilizar RDP publicamente; para o acesso Web normal, não se cria uma nova regra de entrada.

Realizar testes de aceitação com dois utilizadores RDS

Um único acesso bem-sucedido no navegador apenas comprova que algum tráfego de proxy funciona. Os testes de aceitação propriamente ditos exigem duas sessões em paralelo.

1. Associar duas contas piloto AD a grupos de Web Policy diferentes.
2. Abrir duas novas sessões RDS em RDS01.
3. Verificar a configuração efetiva do proxy em ambas as sessões.
4. Em cada sessão, efetuar um acesso HTTP ou HTTPS permitido e outro intencionalmente avaliado de forma diferente.
5. Em Current activities > Live users, verificar ambos os utilizadores com Client Type Multi-host client.
6. Em Log viewer > Authentication, verificar os utilizadores e Log Comp para Kerberos ou NTLM.
7. Comparar utilizador, política, Rule ID, ação e momento nos logs Web e de firewall.
8. Executar um teste necessário fora do proxy e confirmar que não recebe indevidamente uma identidade de utilizador.
9. A partir do host piloto, identificar os serviços HTTP e HTTPS locais da firewall acessíveis através do proxy. Se um serviço não permitido pelo desenho de segurança estiver acessível, parar a implementação e só continuar com uma medida de proteção adicional comprovada.

Uma comparação significativa utiliza o mesmo destino de teste aprovado em ambas as sessões: uma conta em RDS-Web-Standard pode abri-lo e uma conta em RDS-Web-Restricted é bloqueada pela Web Policy preparada. Registar a data, a hora, o utilizador, o IP de origem, a Rule ID, a política e o resultado. Em seguida, aceder a um destino de controlo que ambos os grupos possam utilizar. Assim, distingue-se uma restrição de grupo intencional de uma falha geral do proxy ou do DNS. Os destinos de teste devem provir da lista de testes aprovada da própria organização; não bloquear um site empresarial em produção apenas para os testes de aceitação.

Só adicionar outros hosts RDS quando ambos os utilizadores forem corretamente distinguidos em simultâneo, os resultados pretendidos das Web Policies forem obtidos e o percurso fora do proxy estiver compreendido. Para os testes de aceitação gerais das regras, é útil Testar regras da Sophos Firewall de forma controlada.

Resolução de problemas

O proxy não está acessível

Verificar a resolução do FQDN, a porta, o resultado do PAC/GPO, a zona de origem e as permissões Web proxy e AD SSO. Um teste bem-sucedido do servidor AD não comprova o acesso ao proxy. Nas rotas SD-WAN, a porta do proxy ou Any tem de corresponder aos critérios de serviço; a própria firewall cria a ligação externa do proxy, pelo que nem todas as características do cliente se aplicam como no tráfego encaminhado normal.

O navegador pede credenciais ou utiliza NTLM

Verificar o destino do proxy, o DNS, o HTTP-SPN, a zona do navegador e a autenticação integrada. O Kerberos necessita do FQDN correspondente, não do IP da firewall. O fallback para NTLM é um sintoma que deve primeiro ser explicado, não um motivo para uma implementação preventiva apenas com NTLM.

Ambas as sessões aparecem como o mesmo utilizador

Verificar se ambos os navegadores utilizam realmente o proxy explícito e se alguma aplicação gera ligações fora da respetiva sessão de utilizador. Um proxy a montante ou NAT também pode alterar o modelo de ligação pretendido. Em Live Users, tem de aparecer o tipo Multi-host client; uma associação normal baseada em IP é um percurso incorreto para este host.

O utilizador está visível, mas a Web Policy não é aplicada

Verificar em conjunto o grupo AD, o Main Group, a ordem das Web Policies, a regra de firewall e a entrada de log. Match known users tem de permanecer desativado na regra de host específica. Uma autenticação visível ainda não comprova que o pedido utiliza a Web Policy ou a Firewall Rule ID esperadas.

Se o utilizador piloto estiver na Default group em vez de no grupo AD importado esperado, verificar primeiro Authentication > Groups, a base de pesquisa e a importação de grupos. Não atribuir uma política de grupo predefinido mais abrangente para ocultar o erro. Após uma correção controlada, verificar com um novo início de sessão se a associação e ambos os testes de políticas estão corretos.

O tráfego não Web não apresenta um utilizador

Este é o comportamento esperado. O Per-Connection AD SSO identifica apenas HTTP e HTTPS através do Direct Web Proxy. Para o tráfego de máquina necessário, aplica-se uma regra sem associação a utilizadores. Se for necessário distinguir RDP, SMB, tráfego de bases de dados ou outro tráfego fora do proxy por sessão, mudar para SATC.

O SSO deixa de funcionar após uma atualização ou um failover HA

O AD SSO pode precisar de uma nova adesão ao domínio após uma atualização, quando são utilizados vários servidores AD ou em HA. Por isso, a conta com direitos delegados de adesão tem de continuar válida. Após um failover controlado, testar com uma nova ligação ao proxy e ambas as contas piloto; não pressupor que as ligações existentes ao proxy ou os tickets Kerberos continuam sem interrupções. Em qualquer modo HA, cada nó guarda apenas os logs do tráfego que ele próprio processou. Por isso, para um evento, verificar o nó que estava ativo ou que o processava nesse momento.

Numa atualização direta de SFOS 21.5 ou anterior para SFOS 22.0 GA Build 411, também pode estar em causa o Known Issue NC-176853: o AD SSO com NTLM e Kerberos pode falhar imediatamente após a atualização, fazendo com que as políticas baseadas em identidade não encontrem correspondência. A Sophos indica SFOS 22.0 MR1 Build 490 como versão de correção. O procedimento interno relativo a KBA-000048429 descreve o diagnóstico e a solução alternativa. A Known Issues List não menciona Per-Connection AD SSO separadamente; por isso, esta ocorrência só é relevante se o percurso AD SSO subjacente falhar após esta atualização específica. Guardar o build de firmware, o momento e os logs, consultar a KBA para o build afetado e não contornar o problema com regras abrangentes ou uma mudança de autenticação.

Ler os logs relevantes

Na Advanced Shell, estes ficheiros são relevantes:

cd /log
tail -n 200 nasm.log
tail -n 200 access_server.log
tail -n 200 awarrenhttp.log

nasm.log mostra problemas de NTLM, Kerberos e possíveis problemas de KVNO. access_server.log ajuda na autenticação e autorização, e awarrenhttp.log no Web Proxy. awarrenhttp_access.log só é criado com debug temporariamente ativado e não faz parte do primeiro passo normal. Antes de reiniciar serviços ou alargar o debug, guardar primeiro o intervalo de tempo, o utilizador, o destino, a regra e os logs existentes.

Rollback

Uma reversão correta não repõe apenas o proxy, mas também o modelo de autenticação anterior.

1. Documentar a lista multiutilizador atual, as exceções de Device Access, as regras, a Web Policy e a distribuição do proxy.
2. Remover RDS01 de Multi-user hosts e guardar com Apply.
3. Reverter de forma controlada a GPO do proxy, o ficheiro PAC ou a configuração da aplicação.
4. Restaurar a associação anterior de STAS, Clientless ou Captive Portal apenas se tiver sido previamente documentada e for adequada para este IP.
5. Após verificar outras dependências, remover a exceção ACL do piloto ou as permissões temporárias de zona para AD SSO e Web Proxy, ou repô-las exatamente no estado anterior.
6. Desativar ou remover as regras específicas de host e de máquina assim que o percurso de substituição estiver confirmado.
7. Voltar a testar com novas sessões de navegador e RDS e, em HA, em ambos os papéis operacionais.

Lista de verificação

• O Per-Connection AD SSO destina-se apenas a tráfego HTTP/HTTPS através de proxy explícito.
• O host piloto tem um IP fixo e exclusivo, sem outros sistemas atrás dele.
• AD, grupos, adesão ao domínio, FQDN, DNS, SPN e hora foram verificados.
• Pré-requisito de zona de AD SSO e impacto na segurança verificados; zona LAN necessária ativada e Apply selecionado, acesso Web proxy limitado separadamente ao host piloto sem permissão abrangente do proxy. Se a permissão de zona for inaceitável, interromper a implementação e obter um desenho suportado de âmbito restrito.
• Os navegadores e as aplicações utilizam fw01.corp.example:3128 ou os valores de substituição do próprio ambiente.
• A regra específica de host tem o registo de logs ativado e Match known users desativado.
• O tráfego fora do proxy foi planeado como tráfego de máquina ou o desenho foi alterado para SATC.
• Dois utilizadores em paralelo, políticas diferentes e o acesso de gestão foram testados positiva e negativamente.
• O failover HA e as atualizações têm um procedimento documentado de nova adesão e repetição de testes.
• O rollback da lista multiutilizador, da distribuição do proxy, de Device Access, das regras e da autenticação anterior está documentado.

Perguntas frequentes