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:
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.
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:
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:
Local do item: mstsc.exe /v:192.168.10.196
Nome: [Nome do cliente] VPN
Passo 2 — primeira execução, configurar recursos locais:
- Abrir o atalho criado.
- Clicar em Mostrar Opções (se a janela abrir compacta).
- Ir na aba Recursos Locais → marcar Impressoras, Área de Transferência e, em Mais…, as unidades/drives necessários.
- 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:
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.
Alternativa via registro: RedirectionWarningDialogVersion (uso avançado)
Existe uma segunda forma de eliminar o alerta, via chave de registro. Ela reverte o cliente RDP para o comportamento anterior à atualização de segurança de abril de 2026 (KB5083769 para Windows 11 e KB5082200 para Windows 10), que foi a atualização que introduziu esse aviso.
Ou diretamente pelo Editor do Registro (regedit), criando o valor DWORD RedirectionWarningDialogVersion = 1 em:
Não exige reinicialização — vale já na próxima conexão.
Quando essa alternativa faz sentido: ambientes em que o colaborador abre vários arquivos .rdp nomeados de fontes diferentes (múltiplos clientes) e a migração para atalhos mstsc.exe /v: não é viável de imediato. Nesse caso, documente a aplicação com data de revisão — não deixe como configuração permanente e silenciosa.
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:
- Um atalho mstsc.exe /v:IP por servidor, nomeado com o nome do cliente.
- Configurar os Recursos Locais uma única vez, na primeira conexão de cada colaborador.
- 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.
- 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.