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.

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 com exatamente um servidor piloto e documentar o percurso de autenticação existente.

Per-Connection AD SSO em nove passos

Decidir se apenas HTTP e HTTPS enviados através de um proxy explícito devem ser processados por utilizador.
Verificar o Active Directory, a importação de grupos, o DNS, a hora e o Domain Join da firewall.
Preparar um FQDN resolúvel para a firewall e um HTTP-SPN adequado para Kerberos.
Permitir AD SSO e Web proxy apenas para a zona de origem necessária ou o host piloto.
Criar um objeto de host IP exato para o servidor RDS.
Em Authentication > Web authentication, ativar Per-Connection AD SSO para esse host.
Configurar navegadores e aplicações compatíveis com proxy para o FQDN da firewall e a porta 3128.
Colocar uma regra própria para o host, com registo, antes de regras de utilizador concorrentes e manter Match known users desativado.
Testar separadamente duas sessões RDS simultâneas, 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 necessidades diferentes.

STAS é adequado para clientes Windows normais quando um IP de cliente pertence tipicamente a um único utilizador. A firewall recebe um mapeamento 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 enviadas 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 RDS ou Citrix quando outros tipos de ligação das sessões individuais também necessitam de uma identidade. Para isso, é necessário o Sophos Server Protection no Session Host.

O STAS na Sophos Firewall clássico não consegue distinguir vários utilizadores atrás do mesmo IP de RDS. Por conseguinte, Per-Connection AD SSO e SATC não são variantes mais cómodas do STAS, mas modelos operacionais distintos. Se uma aplicação não suportar um proxy explícito ou se protocolos que não sejam Web tiverem de ser regulados por utilizador, deve parar-se aqui e avaliar o SATC.

Exemplo e valores substituíveis

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

O endereço 10.20.30.40 deve ser substituído pelo IP fixo do servidor piloto, tal como é visto pela firewall. Não podem existir outros sistemas por trá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 do host deve ter no máximo 15 carateres e ser escrita em minúsculas, para que o nome de host, o nome NetBIOS, o objeto de computador AD e o SPN coincidam.

A porta 3128 é a predefinição do Direct Web Proxy. Se o ambiente utilizar outro Listening Port, a firewall, o ficheiro PAC ou GPO, os navegadores e os testes têm de utilizar o mesmo valor. Os grupos de exemplo destinam-se apenas a tornar o teste de aceitação compreensível; os nomes de grupos e as Web Policies devem corresponder à estrutura de permissões existente.

Preparar os requisitos

Verificar Active Directory e Domain Join

A firewall necessita de um servidor Active Directory funcional, grupos importados e um Domain Join bem-sucedido. Ligar o Active Directory à Sophos Firewall explica LDAPS, base de pesquisa, importação de grupos e os requisitos gerais do AD SSO.

Para uma consulta LDAP normal, é suficiente uma conta com permissões de leitura. O Domain Join e a criação do SPN exigem, por outro lado, uma conta Domain Admin ou uma conta com permissões devidamente delegadas. A conta guardada também tem de permitir um rejoin posterior, porque HA, servidores AD adicionais ou atualizações podem voltar a desencadeá-lo. Não deve ser utilizada desnecessariamente e de forma permanente uma conta Domain Admin sem restrições.

Em Authentication > Services > Firewall authentication methods, deve selecionar-se 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 o posterior início de sessão Kerberos ou NTLM no navegador.

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 Windows piloto, estas verificações só 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 válida. Nenhum resultado ou vários resultados têm de ser esclarecidos antes da implementação.

A resposta DNS deve apontar para a firewall prevista. O cliente, o Domain Controller e a firewall também necessitam de uma hora compatível com Kerberos. Os comandos não alteram nada. Não se deve corrigir o SPN, Domain Join ou a configuração da hora com base em suposições; primeiro é necessário comprovar o erro real.

Inventariar a compatibilidade com proxy e as exceções

Todos os navegadores e aplicações cujo tráfego Web deve receber um utilizador têm de utilizar o proxy explícito e suportar a autenticação integrada do Windows. Antes da implementação, deve verificar-se pelo menos:

navegadores em todas as sessões RDS suportadas
aplicações com a sua própria pilha HTTP
atualizações do Windows e de software
serviços executados no contexto do sistema em vez de numa sessão de utilizador
destinos incluídos no ficheiro PAC ou na lista de bypass do proxy

O tráfego que contorna o proxy permanece, como previsto, sem ID de utilizador. Para ligações de máquina necessárias, deve ser planeada uma regra própria, estritamente limitada e sem dependência do utilizador. Uma regra Any ampla reduziria o efeito de segurança das políticas de utilizador e das Web Policies.

Configurar Per-Connection AD SSO

1. Preparar o FQDN da firewall e o AD SSO

Em Administration > Admin and user settings, deve introduzir-se o FQDN previsto para a firewall. Depois, em Authentication > Web authentication, junto de If Active Directory (AD) SSO is configured, deve selecionar-se Kerberos & NTLM. O NTLM é tecnicamente suportado como fallback, mas o Kerberos deve funcionar de forma fiável em instalações maiores, porque o Per-Connection AD SSO pode gerar muitos pedidos de autenticação adicionais.

Após a inicialização do AD SSO, devem surgir no Log Viewer, em Authentication, as seguintes mensagens de sucesso:

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 interromper o processo, não um convite para reiniciar um serviço sem diagnóstico.

2. Restringir o Device Access

Em Administration > Device access, AD SSO e Web proxy têm de estar permitidos para o percurso de origem previsto. Para um IP piloto fixo, uma Local service ACL exception rule direcionada é geralmente mais restrita do que uma permissão para toda a zona LAN. No entanto, uma exceção Accept adicional não restringe uma permissão de zona que já esteja ativa; num desenho realmente restrito, a permissão ampla tem de permanecer desativada. Device Access e Local Service ACL explica toda a configuração.

O acesso ao Web Proxy tem um efeito secundário importante: um host autorizado pode alcançar serviços HTTP e HTTPS da firewall através do proxy, mesmo que a respetiva zona não esteja autorizada na matriz Local Service normal. Por isso, deve efetuar-se um teste negativo do WebAdmin, User Portal e de outros destinos locais a partir do host piloto. Se esta exposição não for aceitável na rede, o desenho não deve ser ativado em produção.

Em Web > General settings, devem verificar-se o Web proxy listening port real e as portas de destino permitidas. A porta predefinida 3128 só deve ser alterada se o ficheiro PAC, a GPO e todas as aplicações geridas puderem ser ajustados de forma consistente.

3. Criar o host multiutilizador

Deve criar-se um novo objeto de host no seguinte caminho:

Hosts and services > IP host > Add

Para o exemplo, são utilizados estes valores:

Name: RDS01
IP version: IPv4
Type: IP
IP address: 10.20.30.40

No primeiro teste, não deve ser introduzido um intervalo inteiro nem uma sub-rede. Caso contrário, muitos sistemas poderão perder simultaneamente a autenticação baseada em IP que utilizavam. Depois de uma aceitação individual bem-sucedida, vários hosts aprovados podem ser agrupados de forma controlada num grupo de hosts.

4. Ativar Per-Connection AD SSO

Deve aceder-se à seguinte área:

Authentication > Web authentication > Authentication settings for direct web proxy

Em seguida:

Ativar Use per-connection AD SSO authentication for multi-user hosts.
Em Multi-user hosts, adicionar o objeto RDS01.
Guardar com Apply.

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

5. Distribuir o Direct Web Proxy

Deve configurar-se o proxy do navegador ou do sistema através de GPO, ficheiro PAC ou aplicação gerida com este valor:

fw01.corp.example:3128

Para Kerberos, tem de ser utilizado exatamente o FQDN correspondente ao SPN. Um endereço IP como destino do proxy, uma forma abreviada que não seja resolúvel ou outro alias originam frequentemente fallback para NTLM ou um pedido de credenciais. As entradas de bypass devem ser mantidas deliberadamente reduzidas e documentadas, porque cada ligação que contorna o proxy não recebe uma identidade Per-Connection.

A configuração geral de listener, PAC, regra e rollback está descrita em Configurar o Direct Web Proxy com um ficheiro PAC. Este artigo acrescenta apenas a autenticação multiutilizador.

6. Posicionar uma regra própria da firewall

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

Configuração segura:

Source zones: zona RDS real, por exemplo LAN
Source networks and devices: apenas RDS01
Destination zones: WAN
Destination networks: apenas os destinos necessários ou, de forma consciente, Any
Services: um serviço TCP próprio para 3128 ou para o proxy-Listening Port efetivamente configurado; Any apenas de forma consciente
Log firewall traffic: ativo
Match known users: desativado
Web filtering > Web policy: selecionar a Policy preparada dependente do utilizador ou do grupo

As Web Policies conseguem distinguir utilizadores e grupos no tráfego proxy, mas só atuam depois de serem atribuídas à regra da firewall. Esta diferenciação deve ser feita na Web Policy, e não em Match known users desta regra de host. Depois de selecionar ou alterar a Web Policy, deve voltar a verificar-se o interruptor, porque uma dependência de utilizador pode reativá-lo.

Para DNS, atualizações e outras ligações necessárias fora do proxy, deve criar-se uma regra de máquina separada. Não deve ser adicionada uma regra WAN-para-LAN genérica; o exemplo de entrada apresentado pela Sophos não é necessário para o acesso Web RDS normal e, sem um objetivo de publicação próprio, aumentaria desnecessariamente a superfície de ataque. Criar corretamente regras da firewall explica a estrutura, ordem e registo.

Testar com dois utilizadores RDS

Um único pedido bem-sucedido no navegador apenas prova que existe algum tráfego proxy funcional. A verdadeira aceitação requer duas sessões em simultâneo.

Atribuir duas contas piloto AD a grupos diferentes de Web Policy.
Abrir duas novas sessões RDS em RDS01.
Verificar a configuração de proxy efetiva em ambas as sessões.
Em cada sessão, iniciar um pedido HTTP ou HTTPS permitido e outro deliberadamente avaliado de forma diferente.
Em Current activities > Live users, verificar ambos os utilizadores com Client Type Multi-host client.
Em Log viewer > Authentication, verificar o utilizador e Log Comp para Kerberos ou NTLM.
Comparar utilizador, Policy, Rule ID, ação e hora nos registos Web e da firewall.
Iniciar um teste necessário fora do proxy e confirmar que não recebe incorretamente uma identidade de utilizador.
A partir do host piloto, identificar os serviços HTTP e HTTPS locais da firewall acessíveis através do proxy. Se estiver acessível um serviço que o desenho de segurança não permite, a implementação deve ser interrompida e só deve continuar com uma medida de proteção adicional comprovada.

Só se devem adicionar outros hosts RDS quando ambos os utilizadores forem corretamente distinguidos em simultâneo, os resultados pretendidos da Web Policy ocorrerem e o percurso fora do proxy estiver compreendido. Para a aceitação geral de regras, consulte Testar regras da Sophos Firewall de forma controlada.

Resolução de problemas

O proxy não está acessível

Devem verificar-se a resolução FQDN, a porta, o resultado de 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 ao critério do serviço; a firewall estabelece a própria ligação proxy externa, pelo que nem todas as características do cliente se aplicam como no tráfego encaminhado normal.

O navegador pede credenciais ou utiliza NTLM

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

Ambas as sessões aparecem como o mesmo utilizador

Deve verificar-se se ambos os navegadores utilizam realmente o proxy explícito e se alguma aplicação cria 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, deve aparecer o tipo Multi-host client; um mapeamento normal baseado em IP é o percurso errado para este host.

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

Devem verificar-se em conjunto o grupo AD, Main Group, a ordem da Web Policy, a regra da firewall e a entrada de registo. Match known users tem de permanecer desativado na regra especial do host. Uma autenticação visível ainda não prova que o pedido utiliza a Web Policy ou a Firewall Rule ID esperada.

O tráfego que não é Web não mostra um utilizador

Este é o comportamento previsto. O Per-Connection AD SSO identifica apenas HTTP e HTTPS através do Direct Web Proxy. O tráfego de máquina necessário utiliza uma regra sem dependência do utilizador. Se RDP, SMB, tráfego de base de dados ou outro tráfego fora do proxy tiver de ser distinguido por sessão, deve utilizar-se SATC.

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

O AD SSO pode necessitar de um novo Domain Join após uma atualização, ao utilizar vários servidores AD ou num sistema HA. A conta de join delegada tem, por isso, de permanecer válida. Depois de um failover controlado, deve testar-se com uma nova ligação proxy e ambas as contas piloto; não se deve partir do princípio de que as ligações proxy ou os tickets Kerberos existentes continuam sem interrupção. Em qualquer modo HA, cada nó guarda apenas os registos do tráfego que processou. Para um evento, deve portanto verificar-se o nó que estava ativo ou que o processou nesse momento.

Ler os registos 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 erros 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 aumentar o debug, devem primeiro ser guardados o período, o utilizador, o destino, a regra e os registos existentes.

Reverter a configuração

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

Documentar a lista atual de hosts multiutilizador, as exceções de Device Access, as regras, a Web Policy e a distribuição do proxy.
Remover RDS01 de Multi-user hosts e guardar com Apply.
Reverter de forma controlada a GPO do proxy, o ficheiro PAC ou a configuração da aplicação.
Restaurar o mapeamento STAS, Clientless ou Captive Portal anterior apenas se tiver sido documentado e for adequado para este IP.
Após verificar outras dependências, remover a exceção ACL piloto e as permissões temporárias de zona para AD SSO e Web Proxy, ou repor exatamente o estado anterior.
Desativar ou remover as regras especiais de host e de máquina assim que o percurso substituto estiver confirmado.
Voltar a testar com novas sessões do navegador e de RDS e, em HA, nas duas funções operacionais.

Lista de verificação

O Per-Connection AD SSO destina-se apenas a tráfego HTTP/HTTPS enviado por proxy explícito.
O host piloto tem um IP fixo e inequívoco, sem outros sistemas por trás.
AD, grupos, Domain Join, FQDN, DNS, SPN e hora foram verificados.
AD SSO e Web Proxy estão permitidos apenas para o percurso de origem necessário.
Os navegadores e aplicações utilizam fw01.corp.example:3128 ou os valores substitutos do ambiente.
A regra especial do host tem registo ativo e Match known users desativado.
O tráfego fora do proxy está planeado como tráfego de máquina ou o desenho foi alterado para SATC.
Dois utilizadores simultâneos, Policies diferentes e o acesso de gestão foram testados positiva e negativamente.
Os failovers HA e as atualizações têm um procedimento documentado de rejoin e novo teste.
Está documentada a reversão da lista multiutilizador, distribuição do proxy, Device Access, regras e autenticação anterior.

Perguntas frequentes

O Per-Connection AD SSO pode substituir o SATC?

Apenas quando é necessário avaliar por utilizador exclusivamente HTTP e HTTPS através do Direct Web Proxy. O SATC consegue associar todos os tipos de ligação suportados das sessões de utilizador RDS e é, por isso, necessário quando o tráfego fora do proxy também precisa de uma identidade de utilizador.

Porque deve Match known users estar desativado?

A regra especial da firewall deve ser aplicada primeiro com base no IP do host multiutilizador. Se Match known users estiver ativo, a firewall pode processar o tráfego do host com base num mapeamento IP existente, frequentemente de um utilizador administrativo, e ignorar regras seguintes. Neste desenho, as diferenças entre utilizadores e grupos são avaliadas na Web Policy.

Porque utiliza o navegador NTLM em vez de Kerberos?

Frequentemente, o destino do proxy não corresponde ao HTTP-SPN, o FQDN da firewall não é resolvido corretamente ou o navegador não confia no destino para autenticação integrada. O Kerberos necessita do FQDN como destino do proxy; não funciona com um endereço IP.

O tráfego RDP, SMB ou DNS também recebe uma identidade de utilizador?

Não. O Per-Connection AD SSO aplica-se apenas a ligações HTTP e HTTPS através do Direct Web Proxy. O tráfego restante permanece sem autenticação e necessita de uma regra de máquina adequada ou de outro método, como SATC.