Suporte Técnico

Alerta “Conexão remota desconhecida” no RDP: solução

14 de agosto de 2026 8 min de leitura

Alerta “Conexão remota desconhecida” no RDP: impressora e área de transferência somem

Se sua conexão de Área de Trabalho Remota mostra o alerta “conexão remota desconhecida” e, depois disso, a impressora local ou a área de transferência param de funcionar, o problema não é falha de configuração — é o comportamento padrão do Windows para arquivos .rdp salvos. Veja a causa exata e a correção.

O alerta “conexão remota desconhecida” na tela

Ao abrir um arquivo .rdp salvo por duplo clique, o Windows exibe esta janela:

Cuidado: conexão remota desconhecida
Esta conexão remota pode prejudicar o computador local ou remoto e pode ser usada para roubar senhas ou arquivos. Não foi possível verificar o distribuidor desta conexão remota.
Distribuidor: Fornecedor desconhecido
Tipo: Conexão de Área de Trabalho Remota

Logo abaixo, uma lista de recursos aparece desmarcada por padrão:

  • Cartões inteligentes ou Windows Hello para Empresas
  • WebAuthn (chaves de acesso e chaves de segurança)
  • Área de Transferência
  • Impressoras

Mesmo que o usuário já tenha marcado “Impressoras” e “Área de Transferência” na aba Recursos Locais do cliente RDP antes de conectar, essa segunda tela sobrescreve a escolha. O aviso avisa também que a mudança “se aplica somente a esta inicialização de conexão” — ou seja, mesmo marcando manualmente, na próxima vez o Windows pergunta de novo.

Por que isso acontece: editor não verificado, não GPO

A causa não está em política de grupo, antivírus ou permissão do usuário. É o Mark of Untrusted Publisher do Windows: qualquer arquivo .rdp salvo em disco (mesmo criado localmente, sem download da internet) é tratado como conteúdo de origem não assinada.

Diferença entre os dois modos de abrir uma conexão RDP:

Como conecta Aviso aparece? Recursos locais persistem?
Arquivo .rdp salvo (duplo clique) Sim, toda vez Não — reseta a cada conexão
mstsc.exe direto (sem .rdp de origem) Não Sim — gravado em Default.rdp

O RDP segue sendo um dos vetores de acesso mais visados em incidentes de segurança — segundo o relatório Unit 42 Incident Response and Data Breach Report de 2020, o RDP foi o vetor inicial de ataque em 50% dos casos de implantação de ransomware analisados. Por isso o Windows trata qualquer arquivo .rdp de origem incerta com esse nível de suspeita — é comportamento de segurança por design, não bug.

O que testamos e NÃO resolveu

Antes de confirmar a causa raiz, testamos adicionar o IP do servidor (192.168.10.196) à zona de Intranet Local do Windows:

Painel de Controle > Opções da Internet > Segurança > Intranet Local > Sites > Avançado
Adicionar: 192.168.10.196

Esse ajuste não teve efeito sobre o alerta. Zona de segurança do Windows é consultada por processos que leem essas zonas (como Internet Explorer/Edge legado, RD Web Access via navegador), mas o mstsc.exe abrindo um .rdp local direto não consulta essa configuração. Reiniciar a máquina também não muda o comportamento — não é cache de sistema, é o mecanismo de assinatura do arquivo sendo avaliado a cada abertura.

⚠️ Atenção: não perca tempo testando zona de segurança ou reinicialização para esse sintoma específico — nenhum dos dois altera o comportamento do alerta em conexão .rdp local via duplo clique.

Certificado confiável: existe, mas é o caminho mais longo

O Windows para de exibir o alerta quando reconhece o publisher do arquivo .rdp como confiável. Isso é possível assinando o arquivo com certificado (via rdpsign.exe) e cadastrando o thumbprint SHA1 desse certificado em:

Configuração do Computador > Modelos Administrativos > Componentes do Windows >
Serviços de Área de Trabalho Remota > Cliente de Conexão de Área de Trabalho Remota >
“Especificar impressões digitais SHA1 de certificados que representam editores confiáveis de arquivos .rdp”

Funciona, mas exige gerar e manter certificado, assinar o arquivo, distribuir a versão assinada e reassinar quando o certificado expirar. Para a maioria dos ambientes SMB sem PKI própria, esse custo de manutenção não compensa — existe um caminho mais direto para o mesmo resultado.

A solução: atalho mstsc.exe /v: em vez de arquivo .rdp

A correção real não edita nem assina o .rdp — troca a forma como a conexão é iniciada.

Passo 1 — criar o atalho:

Clique direito na Área de Trabalho > Novo > Atalho
Local do item: mstsc.exe /v:192.168.10.196
Nome: [Nome do cliente] VPN

Passo 2 — primeira execução, configurar recursos locais:

  1. Abrir o atalho criado.
  2. Clicar em Mostrar Opções (se a janela abrir compacta).
  3. Ir na aba Recursos Locais → marcar Impressoras, Área de Transferência e, em Mais…, as unidades/drives necessários.
  4. Voltar em Geral, conferir o IP, clicar em Conectar — nunca em “Salvar” ou “Salvar como”.

Resultado esperado: a conexão abre sem nenhum alerta de “editor desconhecido”, porque não existe um .rdp nomeado envolvido — apenas o executável mstsc.exe recebendo o IP como parâmetro.

Por que funciona: o Default.rdp

Ao clicar em Conectar (sem passar por “Salvar”), o Windows grava automaticamente as escolhas de Recursos Locais em:

%USERPROFILE%\Documents\Default.rdp

Esse arquivo é o “molde” de configuração do perfil do usuário, lido silenciosamente em toda conexão futura via mstsc.exe /v:IP — sem disparar o aviso de segurança, porque não é um .rdp nomeado clicado diretamente.

Diagnóstico vs. correção: os comandos usados até aqui para investigar (gpresult /r /scope:computer, inspeção do tsconfig.msc, edição do .rdp no Bloco de Notas) servem para descartar causas — GPO, política de RDS, configuração salva no arquivo. Nenhum deles resolve o alerta sozinho. A correção definitiva é exclusivamente a troca do método de conexão para mstsc.exe /v:IP.

Se a empresa tem mais de um servidor RDP

O Default.rdp é único por usuário, não por servidor. Se o colaborador acessa dois ou mais servidores (cliente diferente, ou mais de um Terminal Server no mesmo cliente), a última configuração marcada é reaproveitada em qualquer novo IP conectado via mstsc.exe /v:.

Na prática, isso raramente é problema: a grande maioria dos ambientes usa o mesmo padrão de recursos (impressora + área de transferência) em todos os servidores. Marcar um recurso a mais que não será usado em um servidor específico não causa efeito colateral — apenas fica disponível e não utilizado.

Recomendação de padronização:

  1. Um atalho mstsc.exe /v:IP por servidor, nomeado com o nome do cliente.
  2. Configurar os Recursos Locais uma única vez, na primeira conexão de cada colaborador.
  3. Se um servidor específico exigir uma configuração diferente da padrão (ex: sem impressora, por política do cliente), reabrir “Mostrar Opções” e ajustar antes de conectar naquele IP — o Default.rdp só reflete a última escolha feita, então vale conferir quando o padrão do dia muda.
  4. Para ambientes com muitos servidores e políticas de redirecionamento distintas por cliente, o caminho de certificado + SHA1 thumbprint (mencionado acima) passa a compensar o investimento, já que cada .rdp assinado carrega sua própria configuração isolada.

Perguntas frequentes

O alerta “conexão remota desconhecida” indica que o servidor está comprometido?
Não necessariamente. O aviso aparece para qualquer arquivo .rdp salvo localmente, mesmo criado pelo próprio usuário, porque o Windows não verifica automaticamente a origem de arquivos .rdp sem assinatura digital. É um alerta de política de segurança do sistema operacional, não uma detecção de ameaça real no servidor de destino.

Trocar para o atalho mstsc.exe /v: resolve de forma permanente?
Sim, enquanto a conexão continuar sendo feita por esse atalho (sem clicar em “Salvar” no meio do caminho). Se em algum momento o usuário salvar um .rdp nomeado e passar a abri-lo por duplo clique, o alerta volta a aparecer, porque a causa está no tipo de arquivo, não em uma configuração que “gruda” permanentemente no sistema.

Preciso reiniciar o computador depois de criar o atalho ou ajustar os Recursos Locais?
Não. Tanto a criação do atalho quanto a gravação do Default.rdp são lidas em tempo real pelo mstsc.exe na próxima conexão — não exigem reinicialização, logoff ou nenhuma ação além de abrir uma nova sessão RDP.

Precisa de suporte técnico especializado?

Se sua empresa depende de acesso remoto para operar e enfrenta instabilidade, bloqueios ou configurações inconsistentes de RDP, fale com a gente no WhatsApp e receba um diagnóstico gratuito do seu ambiente.

Descubra se a TI da sua empresa
está realmente protegida

A Thompsontech oferece diagnóstico gratuito para pequenas e médias empresas. Em uma conversa rápida, você descobre o que precisa mudar para ter tranquilidade de verdade.

Quero meu diagnóstico gratuito

Compartilhe: