Configurar Sophos Firewall SATC para Remote Desktop Services

Sophos Authentication for Thin Client, abreviado SATC, permite aplicar regras baseadas em utilizadores a Remote Desktop Services. Isto é importante sempre que vários utilizadores acedem à rede ou à Internet através do mesmo Windows Remote Desktop Session Host. Nesses casos, o STAS clássico vê muitas vezes apenas o endereço IP do terminal server. SATC, pelo contrário, fornece à Sophos Firewall informações de utilizador das sessões RDS individuais.

Para clientes Windows normais, o primeiro passo é configurar STAS na Sophos Firewall. SATC não substitui STAS em todos os ambientes, mas é o componente adequado para Remote Desktop Services.

Utilização e planeamento

Quando SATC faz sentido

SATC é adequado quando os utilizadores não passam pela firewall diretamente a partir do seu próprio cliente, mas utilizam aplicações ou browsers num Remote Desktop Session Host.

Cenários típicos:

• Remote Desktop Services com vários utilizadores simultâneos
• terminal servers onde os utilizadores precisam de acesso web ou acesso a aplicações
• regras de firewall baseadas em utilizador para utilizadores RDS
• reporting em que não deve ser visível apenas o endereço IP do servidor RDS
• ambientes em que STAS não é suficiente porque vários utilizadores partilham o mesmo endereço IP de origem

SATC não é o ponto de partida correto para clientes de domínio normais, utilizadores VPN ou cenários puros de Captive Portal. Nesses casos, deve-se primeiro escolher corretamente o modelo de autenticação: STAS, Captive Portal, autenticação VPN, RADIUS ou Microsoft Entra ID SSO.

Num endpoint individual fora do domínio, o Client Authentication Agent pode proporcionar um login deliberado do utilizador. Não substitui SATC num host multiutilizador, porque várias sessões partilham o mesmo IP de origem.

Se num host multiutilizador for necessário distinguir apenas HTTP e HTTPS através de um proxy explícito, o Per-Connection AD SSO através do Direct Web Proxy pode ser suficiente sem um agente SATC. Assim que RDP, SMB ou outro tráfego fora do proxy também necessitar de uma identidade por sessão de utilizador, SATC continua a ser o desenho adequado.

Separar STAS e SATC corretamente

A diferença mais importante é a associação de IP.

• Um cliente Windows pertence normalmente a um utilizador: STAS.
• Muitos utilizadores partilham o mesmo IP de servidor RDS: SATC.
• Utilizadores autenticam-se no browser para que as regras se apliquem: Captive Portal.
• Utilizadores chegam através de Remote Access VPN: autenticação VPN ou Entra ID SSO.
• Tráfego passa por servidores técnicos sem relação com utilizador: regras de firewall normais sem utilizador.

Se um terminal server for representado incorretamente através de STAS ou Clientless User, criam-se rapidamente expectativas erradas. Uma regra parece ser baseada em utilizador, mas na realidade a firewall vê apenas um IP de servidor partilhado. SATC resolve exatamente este problema, mas exige uma configuração própria no Windows Server e na firewall.

Se STAS e SATC forem usados ao mesmo tempo, a separação conceptual sozinha não basta. Citrix XenApp e Windows Server RDS podem fazer com que STAS devolva uma identidade de utilizador incorreta para o mesmo IP de servidor, caso este não esteja excluído. Por isso, os endereços IP dos servidores Citrix/RDS devem ser incluídos na configuração STAS em Login IP Address/Network Subnet mask Exclusion List e Logoff IP Address/Network Subnet mask Exclusion List. Sem esta exclusão, STAS pode continuar a fornecer o seu próprio mapeamento de utilizador, contraditório, precisamente para os IPs de servidor que deveriam usar SATC.

Pré-requisitos

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

• Sophos Server Protection pode ser utilizado no Remote Desktop Session Host.
• O Windows Server funciona como Remote Desktop Session Host.
• É usado Windows Server 2016 ou posterior.
• A Sophos Firewall está acessível.
• Active Directory está ligado à Sophos Firewall.
• Os grupos AD necessários estão importados na firewall.
• Em Administration > Device access, a zona do servidor RDS está permitida na linha Clients.
• O servidor RDS consegue alcançar o IP da firewall através de UDP 6060; qualquer firewall de host ou de rede intermédia permite este caminho.
• As regras de firewall podem trabalhar posteriormente com Match known users.
• Existe uma janela de manutenção para alteração de Registry e reinício do servidor RDS.

A integração AD deve estar corretamente configurada antes de implementar SATC. Se AD ainda não estiver pronto, verificar primeiro Ligar Active Directory à Sophos Firewall.

Limites importantes

SATC tem alguns limites que devem ser conhecidos antes do rollout:

• Standalone SATC: Já não é suportado pela Sophos Firewall.
• Implementação: SATC funciona através do Sophos Server Protection ou do Sophos Fusion Server Core Agent.
• Plataforma: segundo a Sophos, a configuração atual com Sophos Server Protection suporta apenas Windows Remote Desktop Services. A visão geral anterior ainda menciona o Citrix XenApp no contexto do conflito com STAS e o parâmetro CLI continua a chamar-se citrix-ip. Nenhum destes elementos constitui uma confirmação atual de suporte para uma nova implementação Citrix. Uma instalação Citrix existente deve ser confirmada com o Sophos Support antes de qualquer alteração e não deve ser recriada a partir deste guia de RDS.
• Serviços de sistema: SATC associa uma identidade de diretório apenas às ligações criadas por processos de utilizador. Os processos iniciados por serviços de sistema do Windows permanecem sem identidade de utilizador e exigem uma regra de máquina separada e estritamente limitada com Match known users desativado. Esta regra não deve servir de fallback amplo para o restante tráfego RDS.
• Limite de servidores: A Sophos indica até 192 Thin Client Servers na firewall.
• Autenticação por IP de servidor: Se um IP de servidor RDS estiver registado na firewall como Thin Client, SATC funciona como método de autenticação para esse IP. Outros métodos como Clientless User não se aplicam a esse IP.

O último ponto é especialmente importante. Não se devem adicionar IPs de terminal servers produtivos apenas para teste sem compreender o conjunto de regras e o caminho de retorno. Assim que o IP é tratado como origem SATC, mudam as expectativas em relação à associação de utilizadores e ao matching de regras.

Configuração

Visão geral do processo

O processo técnico consiste em cinco partes:

1. Instalar Sophos Server Protection no servidor RDS.
2. Ativar SATC por Registry no servidor RDS.
3. Registar o IP do servidor RDS na Device Console da Sophos Firewall.
4. Verificar servidor AD, grupos e ordem de autenticação na firewall.
5. Validar Device Access, regra de firewall e Live Users.

SATC não deve ser apenas instalado, mas também testado. Uma instalação bem-sucedida no servidor ainda não prova que a firewall verá mais tarde o utilizador correto na regra correta.

Instalar Sophos Server Protection

A instalação é feita através do Sophos Fusion (anteriormente Sophos Central).

Procedimento:

1. Iniciar sessão no Sophos Fusion.
2. Abrir Protect Devices.
3. Em Server Protection, transferir o Windows Server Installer.
4. Instalar o programa de instalação no Remote Desktop Session Host.
5. Verificar se o servidor aparece corretamente no Sophos Fusion.
6. Definir uma janela de manutenção para a ativação de SATC.

SATC faz parte do Sophos Fusion Server Core Agent e, segundo a Sophos, está disponível com qualquer licença Server Protection. Os programas de instalação efetivamente visíveis no Sophos Fusion continuam a depender das licenças existentes. Se Sophos Server Protection já estiver instalado no servidor, também deve ser verificado se o agente está atualizado e se Tamper Protection pode ser desativado de forma controlada e depois novamente ativado.

Ativar SATC por Registry

SATC é controlado no servidor RDS por valores de Registry neste caminho:

HKLM\Software\Sophos\Sophos Network Threat Protection\Application

Antes da alteração, este comando só de leitura mostra que valores SATC já existem:

reg query "HKLM\Software\Sophos\Sophos Network Threat Protection\Application"

Atenção: As alterações de Registry e o reinício subsequente afetam todas as sessões RDS ativas. Documentar os valores atuais, utilizar uma janela de manutenção e desativar Tamper Protection apenas de forma controlada. Depois da alteração, deve ser novamente ativado.

A configuração básica pode ser definida numa linha de comandos administrativa:

reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SendSatcEvents /t REG_DWORD /d 1 /f
reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcDestinationAddr /t REG_SZ /d FIREWALL-IP /f
reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcDestinationPort /t REG_DWORD /d 6060 /f

Substituir FIREWALL-IP pelo endereço IPv4 da Sophos Firewall acessível a partir da zona do servidor RDS. A Sophos documenta UDP 6060 para SATC, por isso 6060 permanece inalterado no exemplo. Não utilizar um endereço WAN público quando o servidor e a firewall comunicam por uma interface interna.

Recomendação da Avanet: Ligar primeiro apenas um host RDS e permitir UDP 6060 exclusivamente entre esse host e a firewall. Assim, um erro fica limitado ao servidor piloto antes de se adicionarem mais Session Hosts.

Depois:

1. Ativar novamente Tamper Protection.
2. Reiniciar o servidor RDS.
3. Após o reinício, verificar se o serviço Sophos está em execução.
4. Executar novamente o comando só de leitura reg query e verificar os valores definidos.
5. Só depois continuar com a configuração da firewall e os testes.

Excluir contas locais e destinos

Por predefinição, contas locais como SYSTEM ou Administrator também podem gerar eventos SATC. Isto normalmente não ajuda em regras de utilizador e pode sujar desnecessariamente os logs.

Com SatcExcludedUsers é possível excluir utilizadores. As entradas são sensíveis a maiúsculas e minúsculas, pelo que os nomes devem reproduzir exatamente a grafia utilizada no sistema.

Exemplo:

reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcExcludedUsers /t REG_MULTI_SZ /d "SYSTEM\0administrator" /f

Com SatcExcludedAddresses é possível excluir destinos para os quais não devem ser enviadas informações SATC à firewall. Isto pode fazer sentido para destinos locais de gestão, atualização ou infraestrutura, mas deve ser documentado explicitamente.

SatcExcludedAddresses é um valor de múltiplas cadeias (MULTISTRING / REG_MULTI_SZ). Ao configurar vários destinos com reg add na linha de comandos do Windows, separar as entradas no argumento de dados /d com \0, não com vírgulas. Os passos de manutenção, proteção contra adulteração, verificação e reversão descritos acima também se aplicam a esta alteração.

Formatos possíveis:

192.0.2.10
192.0.2.10:443
*:443

192.0.2.10 é um endereço de documentação e tem de ser substituído pelo IP real do destino. A segunda entrada aplica-se apenas à porta 443 desse destino, enquanto *:443 abrange essa porta para todos os destinos. Uma exceção tão ampla retiraria praticamente todo o tráfego HTTPS da associação SATC e não é adequada para regras de utilizador normais.

Recomendação da Avanet: Começar sem exceções e adicionar uma apenas após uma conclusão clara nos logs. Atribuir a cada exceção um responsável, uma finalidade e uma data de revisão.

Em caso de latência de rede percetível entre o servidor RDS e a firewall, também é possível definir SatcPendDurationMs. O valor determina durante quanto tempo as ligações TCP IPv4 de saída são retidas, para que a associação do utilizador esteja disponível a tempo. Se o valor de Registry não existir, SATC utiliza 100 milissegundos; 0 desativa apenas este atraso da ligação, não SATC. Alterar o valor apenas perante problemas reais de latência, não por precaução.

reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcPendDurationMs /t REG_DWORD /d 300 /f

300 é um exemplo de diagnóstico ajustável, não um novo valor predefinido recomendado. Aumenta o atraso em relação ao valor predefinido documentado de 100 milissegundos para cada ligação TCP IPv4 de saída afetada. Medir antes e depois com o mesmo utilizador e destino. Se não houver benefício, o seguinte comando administrativo repõe o valor predefinido ao eliminar o valor opcional:

reg delete "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcPendDurationMs /f

Tal como nas outras alterações de registo, é necessário reiniciar o servidor RDS depois.

Registar o servidor RDS na firewall

A firewall tem de saber que servidores fornecem informações SATC. Isto é feito na Device Console, não na Advanced Shell.

Procedimento:

1. Iniciar sessão na Sophos Firewall por consola ou SSH.
2. Abrir a opção 4. Device Console.
3. Mostrar as entradas existentes:

system auth thin-client show

4. Adicionar o IP do servidor RDS apenas se ainda não estiver listado:

system auth thin-client add citrix-ip <RDS-SERVER-IP>

<RDS-SERVER-IP> é substituído pelo endereço IP do Remote Desktop Session Host.

Se existirem vários servidores RDS, cada servidor deve ser registado individualmente e documentado. Depois deve estar claro:

• que servidores contam como origens SATC
• que zona estes servidores usam
• que regras de firewall avaliam utilizadores destes servidores
• quem aprova alterações à lista de servidores RDS

Se tiver sido registado um IP incorreto, verificar novamente a lista e removê-lo de forma direcionada:

system auth thin-client delete citrix-ip <RDS-SERVER-IP>

O comando remove apenas a entrada Thin Client da firewall; os valores de Registry e o Sophos Server Protection permanecem no servidor RDS. Num IP produtivo, a associação SATC deixa assim de existir, pelo que as regras baseadas em utilizadores podem deixar de fazer match. A Sophos não documenta como reagem as sessões já existentes. Por isso, remover a entrada apenas numa janela de manutenção e com um caminho de reversão preparado.

Verificar Active Directory e grupos

SATC fornece informações de utilizador. Para que a firewall possa usar estas informações em regras, a integração AD e os grupos têm de estar corretos.

Verificar:

1. Abrir Authentication > Servers.
2. Validar o servidor AD com Test connection.
3. Controlar a importação de grupos.
4. Abrir Authentication > Groups.
5. Procurar os grupos relevantes.
6. Abrir Authentication > Services.
7. Verificar o servidor AD na ordem correta dos Firewall authentication methods.

Apenas se se pretender consultar o AD primeiro: Antes de alterar a configuração, documentar a ordem atual e verificar a ordem de autenticação pretendida e o plano de reversão; não reordenar indiscriminadamente a autenticação em produção. Em Authentication > Services > Firewall authentication methods, selecionar o servidor AD relevante, movê-lo para a primeira posição na lista de servidores selecionados e clicar em Apply. Se surgirem efeitos indesejados, restaurar a ordem anterior documentada e clicar em Apply.

Quanto à associação a grupos AD, a Sophos documenta que, durante a autenticação, os utilizadores são associados aos seus grupos AD importados na firewall; os grupos são avaliados e atualizados em cada início de sessão. Só se nenhum dos grupos AD do utilizador existir na firewall é que lhe é atribuído o Default group configurado em Authentication > Services > Firewall authentication methods. Este mecanismo de recurso não substitui a importação dos grupos em falta.

Contradição entre fontes no primeiro início de sessão: A descrição da configuração SATC indica uma associação automática ao grupo predefinido no primeiro início de sessão na firewall, enquanto a descrição dos grupos AD apresenta um mecanismo de recurso condicional. Não está esclarecido se se refere a um estado inicial específico de SATC. Por isso, não pressupor uma associação generalizada ao grupo predefinido nem uma prioridade de grupos especial para SATC.

Antes da implementação em produção: Verificar os grupos importados em Authentication > Groups e o valor realmente configurado de Default group, com as definições herdadas, em Authentication > Services. Pedir a um utilizador de teste que volte a iniciar sessão, confirmar a sua associação efetiva aos grupos em Authentication > Users e utilizar tráfego de teste RDS no Log Viewer para verificar a regra pretendida e os acessos tanto permitidos como bloqueados. Se o mecanismo de recurso se destinar a ser utilizado, testá-lo também com uma conta de teste cujos grupos AD não estejam presentes na firewall, sem eliminar grupos de produção. Pertencer ao grupo predefinido, por si só, não comprova a correspondência da regra desejada. Se a associação for inesperada, parar a implementação e esclarecer com Sophos Support; não alargar grupos de utilizadores nem regras para contornar o problema.

Se os utilizadores aparecerem na área Live Users, mas as regras não se aplicarem, a causa muitas vezes não está no próprio SATC, mas sim na importação de grupos, grupo predefinido, critério da regra ou posição da regra.

Definir Device Access e regra de firewall

Para que a firewall aceite mensagens SATC da zona do servidor, o serviço local Clients tem de estar permitido para essa zona. O SFOS 22 documenta UDP 6060; Clients também inclui STAS e Client Authentication Agent na respetiva porta.

Caminho:

Administration > Device access

Na linha Clients, ativar a zona do servidor RDS. Não se deve abrir cegamente WAN ou uma zona ampla e insegura. Device Access controla serviços locais da firewall e faz parte do hardening de gestão.

Depois, o tráfego propriamente dito precisa de uma regra de firewall.

Procedimento típico:

1. Abrir Rules and policies > Firewall rules.
2. Criar a regra adequada para tráfego do servidor RDS ou da zona de servidores. Como exemplo ajustável, a regra RDS-Web-Users pode inicialmente permitir apenas o serviço HTTPS necessário a partir do objeto host RDSH-01 em LAN para WAN.
3. Adaptar Source zones, Source networks and devices, Destination zones e Services à topologia. RDSH-01, LAN, WAN e HTTPS são exemplos, não requisitos do produto.
4. Ativar Match known users.
5. Selecionar os utilizadores AD ou grupos AD necessários.
6. Ativar logging, para que o teste seja depois rastreável.
7. Guardar a regra.
8. Gerar tráfego de teste a partir de uma sessão RDS.

Recomendação da Avanet: Tornar a regra piloto mais restrita do que a futura regra de produção e colocá-la imediatamente acima de uma regra de bloqueio documentada. Expandir serviços ou grupos de utilizadores apenas após um teste bem-sucedido com dois utilizadores RDS diferentes.

Logging é importante para troubleshooting posterior. Se uma regra de utilizador for criada sem logging, torna-se mais difícil perceber se o problema está em SATC, matching de grupos, ordem de regras ou outro caminho.

Validação e operação

Validação após a configuração

Depois da configuração, não se deve verificar apenas se um utilizador tem acesso à Internet. O essencial é saber se a firewall vê o utilizador correto e se a regra correta faz match.

Teste prático:

1. Iniciar sessão de um utilizador numa sessão RDS.
2. Gerar tráfego de teste definido, por exemplo uma ligação HTTPS permitida.
3. Na Sophos Firewall, abrir Current activities > Live users.
4. Verificar se o utilizador aparece com Client type Thin client.
5. Verificar se o endereço IP do servidor RDS aparece com um ID de sessão único para cada utilizador.
6. Abrir Log Viewer.
7. Filtrar por Source IP do servidor RDS, utilizador e regra.
8. Verificar se a regra esperada baseada em utilizador se aplica.

Repetir o teste com um segundo utilizador e a mesma ligação de destino. O sucesso não significa apenas que ambas as ligações são permitidas: Live users tem de mostrar duas identidades com o mesmo IP do servidor RDS, mas IDs de sessão diferentes, e o Log Viewer tem de mostrar o utilizador correto em cada caso. Testar também um serviço de sistema documentado se tiver sido criada uma regra de máquina separada; este tráfego não pode ser atribuído incorretamente a um utilizador com sessão iniciada.

Para uma análise mais aprofundada na Advanced Shell, firewall_rule.log é relevante para o rule match e access_server.log para autenticação e autorização. O Log Viewer continua a ser a forma mais rápida de efetuar a primeira verificação.

Se o tráfego não correr como esperado, ajuda também Testar regra de firewall com Log Viewer, Policy Test e Packet Capture. Se os utilizadores estiverem visíveis, mas grupos ou utilizadores individuais não fizerem match, Regra da Sophos Firewall não faz match é o próximo caminho de validação adequado.

Operação e documentação

SATC deve ser operado como um componente produtivo de autenticação, não como um hack pontual no Registry.

Documentar:

• servidores RDS e endereços IP
• IP da firewall utilizado e porta SATC
• valores de Registry definidos
• utilizadores e destinos excluídos
• regras de firewall afetadas
• grupos AD e responsável
• utilizador de teste e match de regra esperado
• janela de manutenção e momento do reinício

Após atualizações de Sophos Server Protection, Windows Server, Sophos Firewall ou AD, SATC deve ser testado de forma direcionada com um utilizador de teste. Os problemas de autenticação muitas vezes só se tornam evidentes quando as regras de utilizador ficam subitamente demasiado amplas ou deixam de se aplicar.

Reversão numa janela de manutenção

A Sophos documenta que SendSatcEvents só ativa SATC quando o valor existe e é diferente de 0, e que a entrada Thin Client substitui outros métodos de autenticação para este IP de servidor. Isto oferece um caminho de retorno planeado, mas não repõe automaticamente o método de identidade anterior.

1. Registar previamente a consulta de Registry, a saída de system auth thin-client show, as regras afetadas e o modelo de autenticação anterior.
2. Terminar as sessões RDS ativas na janela de manutenção, desativar Tamper Protection de forma controlada e desativar SendSatcEvents numa linha de comandos administrativa:

reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SendSatcEvents /t REG_DWORD /d 0 /f

3. Ativar novamente Tamper Protection e reiniciar o servidor RDS.
4. Na Device Console, confirmar a entrada com system auth thin-client show e depois eliminá-la de forma direcionada:

system auth thin-client delete citrix-ip <RDS-SERVER-IP>

5. Repor o modelo de regras e autenticação anteriormente documentado e validá-lo com um utilizador de teste. Não ativar sem testes um Clientless User ou uma regra de máquina ampla como substituição.

Recomendação da Avanet: Não eliminar todos os valores de Registry antes de identificar a causa. O valor 0 preserva o endereço de destino e as listas de exclusão para uma reativação controlada; uma exportação do Registry também preserva o estado inicial exato.

Troubleshooting

Nenhum utilizador Thin Client visível

Verificar:

• O servidor RDS foi reiniciado após a alteração de Registry.
• SendSatcEvents está definido e é diferente de 0.
• SatcDestinationAddr aponta para o IP correto da firewall.
• SatcDestinationPort corresponde à porta esperada.
• O caminho de rede do servidor RDS para a firewall está aberto para UDP 6060.
• O IP do servidor RDS foi registado na firewall com system auth thin-client add citrix-ip.
• A zona do servidor RDS está permitida na linha Clients em Device Access.

O utilizador permanece não autenticado devido a um conflito da porta de origem

Software de proxy ou segurança no servidor RDS pode alterar a Source Port. A firewall deteta então um port mismatch e trata o tráfego como não autenticado. Não confundir esta Source Port com SatcDestinationPort: o valor de Registry define a porta de destino para mensagens SATC, por predefinição 6060. Testar esse software de forma controlada ou configurá-lo adequadamente para o caminho SATC; não desativar genericamente as funções de proteção.

O utilizador aparece, mas a regra não faz match

Verificar:

• O utilizador ou grupo está importado na firewall.
• A regra usa Match known users.
• O grupo AD correto está selecionado na regra.
• A posição da regra está correta.
• Não existe uma regra anterior que faça match do mesmo tráfego sem referência a utilizador.
• O Log Viewer mostra o mesmo utilizador, a mesma Source IP e o mesmo serviço.

Contas locais aparecem nos logs

Verificar SatcExcludedUsers e acrescentar contas técnicas. Candidatos frequentes são administradores locais, serviços e contas de sistema. A lista, porém, não deve ficar tão ampla que exclua acidentalmente utilizadores reais.

Alguns destinos não recebem contexto de utilizador

Verificar SatcExcludedAddresses. Se um destino ou porta tiver sido excluído, SATC não envia informações de autenticação à firewall para esse destino. Isto pode ser intencional, mas causa facilmente confusão em regras de utilizador.

Após registar o IP do servidor, um Clientless User antigo deixa de se aplicar

Isto é esperado. Se o IP do servidor RDS foi registado como Thin Client Server, SATC deve ser o modelo de autenticação para esse IP. Workarounds antigos com Clientless Users devem ser removidos ou substituídos de forma planeada.

Sem acesso à Internet após uma atualização para SFOS 22.0 GA

Se o utilizador aparecer como Thin client, mas não tiver acesso à Internet desde a atualização, guardar primeiro a versão de firmware, o rule match, firewall_rule.log e access_server.log. As notas de versão oficiais do SFOS 22.0 listam NC-178903 no SFOS 22.0 MR2 Build 546 como um problema corrigido para atualizações para SFOS 22.0 GA. A Sophos não indica uma assinatura de log inequívoca nem um workaround separado. O enquadramento da release está disponível na visão geral do SFOS 22.0 MR2.

Checklist

• O cenário RDS é realmente adequado para SATC e não para STAS normal.
• Sophos Server Protection está instalado no Remote Desktop Session Host.
• A versão do Windows Server e a função RDS foram verificadas.
• Tamper Protection foi desativado apenas de forma controlada e depois novamente ativado.
• SendSatcEvents, SatcDestinationAddr e SatcDestinationPort estão definidos.
• O servidor RDS foi reiniciado.
• O IP do servidor RDS foi registado na Device Console da firewall.
• O servidor AD e os grupos AD foram verificados na firewall.
• Clients está permitido para a zona correta em Device Access e UDP 6060 está acessível.
• A regra de firewall usa Match known users e tem logging ativo.
• O utilizador aparece em Current activities > Live users com Client type Thin client.
• O Log Viewer mostra o utilizador esperado e a regra esperada.

FAQ