Corrija o erro de RDP Falha na tentativa de logon no Windows

avatar Jun 11, 2026
Fix the Logon Attempt Failed RDP Error on Windows

Você digita suas credenciais, o prompt de Segurança do Windows pisca e uma linha vermelha aparece: A tentativa de logon falhou. A sessão nunca abre. Já me deparei com isso em laboratórios domésticos, máquinas de clientes e servidores igualmente. E o erro parece idêntico, independentemente de a causa ser a falta de uma permissão em Diretiva de Grupo, uma entrada obsoleta no Gerenciador de Credenciais, uma atualização do Windows que interrompeu o CredSSP ou um controlador de domínio que ficou temporariamente inacessível. 

Neste artigo, vou mostrar as causas raiz mais comuns e confirmadas e as correções testadas para o erro de RDP A tentativa de logon falhou.

Índice

O que significa “Falha na tentativa de logon do RDP”?

The logon attempt failed é a mensagem genérica do Windows para uma rejeição de credenciais em algum ponto da cadeia de autenticação do RDP. Ela é exibida como texto dentro do prompt de credenciais do RDP antes que a área de trabalho remota seja estabelecida. O problema é que o Windows retorna essa mesma string para falhas em vários pontos diferentes.

O log de Segurança do Windows na máquina de destino registra isso como Event ID 4625, e o código de status ou sub-status dentro desse evento é o que realmente identifica o ponto de falha.

Como corrigir o erro “Falha na tentativa de logon da Área de Trabalho Remota”?

Correção 1: Conceda o direito de logon dos Serviços de Área de Trabalho Remota

Isso resolve uma grande parte dos casos em que as credenciais estão corretas, mas a conexão falha. Eu começo por aqui antes de mexer em qualquer outra coisa.

  1. Na máquina de destino, pressione a tecla Windows + R, digite secpol.msc e pressione Enter para abrir a Política de Segurança Local.

  2. Expanda Políticas Locais e selecione Atribuição de direitos de usuário.

  3. No painel direito, clique duas vezes em Permitir o logon por Serviços de Área de Trabalho Remota.

    Clicando em Permitir logon por Serviços de Área de Trabalho Remota na Política de Segurança Local

  4. Clique em Adicionar Usuário ou Grupo e digite o nome de usuário exato da conta que você usa para se conectar.

    Adicionando Usuário ou Grupo na guia Configuração de Segurança Local

  5. Clique em OK e feche a Política de Segurança Local.

  6. Abra um Prompt de Comando elevado e execute gpupdate /force para aplicar a alteração sem reiniciar.

    Executando gpupdate force no Prompt de Comando elevado

Enquanto estiver em Gerenciamento do Computador, verifique também se a conta é membro do grupo Usuários da Área de Trabalho Remota em Usuários e Grupos Locais. Isso não substitui o direito de política, mas faz parte da configuração esperada. Por padrão, a associação ao grupo Usuários da Área de Trabalho Remota normalmente concede esse direito, a menos que seja substituída por uma Política de Grupo local ou de domínio. No entanto, se uma Política de Grupo substituir isso explicitamente, talvez seja necessário adicionar a conta diretamente ao direito de política, mesmo que a associação ao grupo já esteja em vigor.

Correção 2: Limpar credenciais obsoletas no Gerenciador de Credenciais

Execute esta correção imediatamente após a Correção 1 se o erro persistir, especialmente após uma alteração de senha na máquina de destino.

  1. Na máquina que está se conectando, abra o menu Iniciar e pesquise por Gerenciador de Credenciais.

  2. Selecione Credenciais do Windows.

    Selecionando credenciais da Web no Gerenciador de Credenciais

  3. Procure por quaisquer entradas que comecem com TERMSRV/ seguidas pelo endereço IP ou pelo nome do host da máquina de destino.

  4. Expanda cada entrada correspondente e clique em Remover.

  5. Feche o Gerenciador de Credenciais.

  6. Abra a Conexão de Área de Trabalho Remota, digite as credenciais manualmente, e conecte-se.

Não deixe que a Conexão de Área de Trabalho Remota salve as credenciais novamente enquanto você ainda está diagnosticando. Desmarque a caixa de seleção Permitir que eu salve as credenciais antes de se conectar, para que o Windows não grave uma nova entrada obsoleta.

Para o caso de Win11-para-Win11 na compilação 26100.6584 relatado no Microsoft Q&A, adicionar manualmente as credenciais da máquina de destino por meio de Painel de Controle > Gerenciador de Credenciais > Credenciais do Windows > Adicionar uma credencial do Windows também resolve casos em que a política de delegação de credenciais está interferindo.

Adicionando uma credencial do Windows no Gerenciador de Credenciais

Além disso, teste com um novo perfil de RDP iniciando o mstsc, clicando em Mostrar Opções e evitando quaisquer perfis de conexão salvos. Arquivos de configuração do RDP corrompidos ou desatualizados (.rdp) podem reutilizar parâmetros ou credenciais inválidos.

Solução 3: Diagnosticar e desabilitar a Autenticação em Nível de Rede

O NLA pré-autentica a sessão usando suas credenciais antes que a Área de Trabalho Remota seja carregada. Quando a máquina de destino não consegue alcançar o controlador de domínio, quando há uma incompatibilidade de versão do CredSSP, ou quando o tipo de conta é incompatível com o handshake do NLA, o NLA pode falhar no handshake de autenticação e exibir a mesma mensagem logon attempt failed no lado do cliente. Desativar temporariamente o NLA confirma se ele é a causa.

  1. No computador de destino, pressione a tecla Windows + Pause para abrir as Propriedades do Sistema, em seguida, clique em configurações remotas no painel esquerdo.

  2. Na guia Remoto, desmarque Permitir conexões somente de computadores que executam a Área de Trabalho Remota com Autenticação em Nível de Rede.

  3. Clique em Aplicar.

  4. Tente a conexão a partir da máquina cliente.

Se a conexão tiver êxito com a NLA desativada, o problema está na cadeia de autenticação da NLA e você pode diagnosticar mais a fundo sem precisar adivinhar. Para acesso baseado no Registro, a configuração da NLA fica armazenada em:

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

O nome do valor é UserAuthentication. Defina-o como 0 para desativar a NLA ou 1 para exigi-la. O valor SecurityLayer no mesmo caminho controla a camada de segurança mais ampla: 0 para apenas segurança RDP, 1 para negociar, 2 para SSL.

Alterando os valores SecurityLayer e UserAuthentication no Editor do Registro

A etapa de pré-autenticação do NLA é exatamente o que falha nos cenários de suporte que os técnicos de TI encontram com mais frequência:

  • Máquinas remotas fora da rede corporativa
  • Dispositivos finais em que o controlador de domínio é inacessível
  • Máquinas onde nenhuma configuração de TI foi feita

Se o seu caso de uso é suporte remoto em vez de acesso às suas próprias máquinas, o HelpWire remove completamente essa camada da equação. O usuário final abre um link de sessão e estabelece uma conexão de saída sem NLA, sem requisitos de conectividade com o domínio e sem qualquer configuração de conta do lado do usuário.

Correção 4: Corrija o erro de RDP “A tentativa de logon falhou” com uma Conta Microsoft

Contas Microsoft podem ser usadas para RDP, mas a autenticação pode falhar se o Windows Hello ou um PIN for usado em vez da senha da conta, se o formato do nome de usuário estiver incorreto (por exemplo, usar o e-mail em vez de MicrosoftAccount\email em algumas configurações), ou se ocorrerem conflitos de cache de credenciais. Nesses casos, usar explicitamente a senha da conta ou uma conta local pode ser uma solução alternativa mais confiável:

  1. Na máquina de destino, abra Configurações e vá para Contas, depois Outros usuários.

  2. Clique em Adicionar conta e, em seguida, clique em Não tenho as informações de entrada dessa pessoa.

  3. Selecione Adicionar um usuário sem uma conta da Microsoft.

  4. Crie um nome de utilizador e uma palavra-passe forte para a conta local.

  5. Depois que a conta for criada, clique nela em Outros usuários, selecione Alterar tipo de conta e defina-a como Administrador.

  6. Retorne à Correção 1 e conceda a esta conta local o direito Permitir o logon por meio dos Serviços de Área de Trabalho Remota na Política de Segurança Local.

  7. Use o nome de usuário e a senha da conta local ao se conectar via RDP.

Em muitos casos, alternar para uma conta de administrador local resolve o problema de forma mais confiável, particularmente quando a autenticação sem senha ou baseada em PIN está ativada.

Correção 5: Corrigir “A tentativa de logon falhou” do RDP após uma atualização do Windows

Foram relatados dois cenários relacionados a atualizações que causam esse erro. O primeiro é a correção do oracle de criptografia do CredSSP introduzida na atualização de maio de 2018 (KB4103727 e correlatas). O segundo é a KB5065426 no Windows 11 24H2 e 25H2, que interrompe a autenticação RDP em máquinas com SIDs duplicados provenientes de imagens preparadas com Sysprep de forma incorreta.


Para o erro do CredSSP (An authentication error has occurred. The function requested is not supported), a correção adequada é garantir que tanto o cliente quanto a máquina de destino estejam totalmente atualizados para que suas versões do CredSSP sejam compatíveis. Apenas como solução temporária, aplique o seguinte na máquina que está se conectando:

  1. Pressione a tecla Windows + R, digite gpedit.msc e pressione Enter.

  2. Navegue até Configuração do Computador > Modelos Administrativos > Sistema > Delegação de Credenciais.

    Clicando em Remediação do Oráculo de Criptografia

  3. Abra Encryption Oracle Remediation e defina como Habilitado.

  4. Defina o Nível de Proteção como Vulnerável.

    Definindo Remediação do Oráculo de Criptografia como Habilitado e Nível de Proteção como Vulnerável

  5. Execute gpupdate /force em um Prompt de Comando elevado.

Isto é apenas uma solução temporária. A correção permanente é atualizar a máquina de destino para que ambos os lados executem uma versão compatível do CredSSP.

Para a regressão do KB5065426 no Windows 11 24H2 e 25H2, uma solução alternativa no Registro relatada pela comunidade tenta desativar a flag de recurso introduzida por essa atualização:

  1. Na máquina de destino, abra o Editor do Registro pressionando a tecla Windows + R e digitando regedit.exe.

  2. Navegue até HKLM\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides.

    Navegando para Substituições no Editor do Registro

  3. Crie um novo valor DWORD (32 bits) chamado 718619.

  4. Defina os dados para 0.

  5. Reinicie a máquina de destino.

A correção permanente para este ambiente é executar sysprep /generalize /oobe /shutdown na imagem base antes de qualquer implantação.

NOTA: Esta solução alternativa no Registro é fornecida pela comunidade e não é oficialmente documentada pela Microsoft. Verifique se ela se aplica à sua compilação específica antes de aplicá-la.

Correção 6: corrigir falha na segunda tentativa de logon via RDP em ambientes de domínio

Em ambientes de domínio, alguns usuários constatam que a primeira tentativa de RDP falha, mas a segunda tem êxito, ou que a conta é bloqueada na segunda tentativa. Configurações incorretas de autenticação NTLM (lmcompatibilitylevel) podem causar falhas de autenticação em ambientes de domínio ou legados, onde diferentes políticas de NTLM são aplicadas entre máquinas.


A correção é alinhar o lmcompatibilitylevel em ambas as máquinas:

  1. Tanto no controlador de domínio quanto no host de RDP, pressione a tecla Windows + R e digite regedit.exe.

  2. Navegue até HKLM\SYSTEM\CurrentControlSet\Control\Lsa.

    Navegando para Lsa no Editor do Registro

  3. Localize ou crie um valor DWORD chamado lmcompatibilitylevel.

  4. Defina o valor para 5, o que impõe: Enviar somente resposta NTLMv2, recusar LM e NTLM.

  5. Reinicie ambas as máquinas.

Isso corresponde ao caminho da Diretiva de Grupo: Configuração do Computador > Configurações do Windows > Configurações de Segurança > Políticas Locais > Opções de Segurança > Segurança de rede: nível de autenticação do LAN Manager. Definir como Enviar somente resposta NTLMv2. Recusar LM e NTLM em ambas as máquinas elimina a incompatibilidade que provoca a falha repetida.

Usando o Visualizador de Eventos para diagnosticar falhas de autenticação do RDP

Visualizador de Eventos na máquina de destino é a forma mais rápida de identificar exatamente qual causa raiz se aplica antes de alterar qualquer configuração. Eu executo isso primeiro em qualquer máquina em que a correção não seja imediatamente óbvia.

  1. Na máquina de destino, pressione a tecla Windows + R, digite eventvwr.msc e pressione Enter.

  2. No painel esquerdo, expanda Logs do Windows e selecione Segurança.

  3. No painel Ações à direita, clique em Filtrar Log Atual.

  4. Digite 4625 no campo IDs de Evento e clique em OK.

  5. Clique na entrada mais recente do ID do evento 4625 e leia os detalhes no painel inferior.

Os campos Status e SubStatus dentro do evento fazem a maior parte do trabalho de diagnóstico:

Código de Status e SubStatus Significado Correção a aplicar
0xC000006A Nome de usuário correto, senha incorreta Verifique a senha, confira o Gerenciador de Credenciais
0xC0000064 Nome de usuário não existe no destino Verifique o nome exato da conta nos usuários locais
0xC0000234 Conta bloqueada Desbloqueie no Active Directory ou no gerenciamento de usuários local
0xC0000072 Conta desabilitada Habilite a conta no gerenciamento de usuários
0xC000015B Tipo de logon não concedido Correção 1 acima (Adicione o direito Allow log on through Remote Desktop Services)
0xC000006F Conta restrita por horários de logon Verifique as propriedades da conta
0xC0000070 Restrição de estação de trabalho Conta limitada a máquinas específicas

Se SubStatus mostrar 0x0, baseie-se no código de Status em vez disso. Se Status ou SubStatus mostrar 0xC000015B, mas a conta já estiver no grupo Usuários da Área de Trabalho Remota, verifique se uma GPO em nível de domínio está substituindo o direito local antes de aplicar a Correção 1.

O campo Tipo de logon também vale a pena verificar. Tipo 10 é interativo remoto, que é o que o RDP usa. Tipo de logon 10 indica RDP (RemoteInteractive). Outros tipos de logon podem indicar diferentes caminhos de autenticação ou falhas no tratamento de sessões, o que aponta para um problema de configuração de retransmissão de rede ou de gateway, em vez de um problema de política local.

Em ambientes de domínio, execute a mesma pesquisa de ID do Evento 4625 no log de Segurança do controlador de domínio, bem como na máquina de destino. O controlador de domínio frequentemente registra a rejeição de autenticação antes que a máquina de destino a registre, e as duas entradas juntas mostram exatamente onde a cadeia de autenticação falhou.

Nem toda falha de RDP gera uma entrada 4625 limpa na máquina de destino em ambientes de domínio, especialmente quando a autenticação falha antes no controlador de domínio.

Se isso não funcionou, restam dois casos de borda após as correções acima:

  1. A máquina de destino está em um estado travado de sessão dos Serviços de Área de Trabalho Remota. Após um corte de energia inesperado ou uma desconexão forçada, TermService pode entrar em um estado que rejeita novas autenticações. Uma reinicialização completa da máquina de destino limpa isso. Se você tiver um caminho alternativo para a máquina, é possível reiniciar apenas os Serviços de Área de Trabalho Remota por meio de services.msc sem uma reinicialização completa.

  2. Uma Diretiva de Grupo no nível de domínio ou da unidade organizacional aplica à sua conta um direito de Negar logon por meio dos Serviços de Área de Trabalho Remota, o que substitui todos os direitos de Permitir abaixo dele. Execute rsop.msc na máquina de destino e navegue até Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment.

    Se a sua conta aparecer em ambos Allow log on through Remote Desktop Services e Deny log on through Remote Desktop Services, o Negar prevalece independentemente da associação ao grupo. Você precisa remover a conta da entrada Negar no nível de política em que ela é aplicada, o que requer acesso ao Console de Gerenciamento de Diretiva de Grupo.

Causas do erro "Falha na tentativa de logon" no RDP

6 causas raiz são responsáveis pela esmagadora maioria dos casos que tenho visto e são frequentemente relatadas na documentação da Microsoft, nos fóruns da comunidade e na solução de problemas em campo.

Mensagem de erro Causa raiz Ambiente
A tentativa de logon falhou. Ausência do direito de política Permitir fazer logon por meio dos Serviços de Área de Trabalho Remota

Formato de nome de usuário incorreto (incompatibilidade entre local e domínio) 		Grupo de trabalho ou domínio
Suas credenciais não funcionaram. A tentativa de logon falhou. Credenciais obsoletas ou conflitantes no Gerenciador de Credenciais Todos os ambientes
Credenciais de logon inválidas. Problemas com credenciais de conta Microsoft em alguns cenários de RDP (frequentemente devido a incompatibilidade entre senha/PIN ou ao tratamento de credenciais) Windows 11
Ocorreu um erro de autenticação. A função solicitada não é suportada. Incompatibilidade de segurança CredSSP/NLA entre o cliente e o destino (geralmente após atualizações ou quando um dos lados não está totalmente corrigido) Após atualização, todos
Ocorreu um erro de autenticação. A Autoridade de Segurança Local não pode ser contatada. Falha do NLA com o controlador de domínio inacessível Redes de domínio
Falha de logon: o usuário não recebeu o tipo de logon solicitado neste computador. Conta explicitamente sem o direito de logon em RDS por meio da Política de Grupo Política de domínio ou local

NOTA: Em ambientes mistos, o formato incorreto do nome de usuário (por exemplo, um nome de usuário local em vez de DOMAIN\username, ou vice-versa) provoca uma falha imediata de autenticação, mesmo quando a senha está correta.

O erro também pode aparecer ao se conectar ao host errado (por exemplo, quando o DNS resolve para uma máquina diferente) ou quando a Área de Trabalho Remota não está devidamente habilitada no destino.

A maioria dessas causas remonta à forma como o RDP empilha suas camadas de autenticação antes que um único pixel da área de trabalho remota esteja visível. Esse design faz sentido para um protocolo de rede corporativa. Mas, para técnicos de TI que fazem suporte remoto em dispositivos finais que eles não controlam totalmente, essas camadas são uma fonte inevitável de falhas de sessão. HelpWire foi desenvolvido para esse caso de uso específico. Você simplesmente inicia uma sessão enviando um link, e o usuário final se conecta sem qualquer configuração de conta do lado dele. Além disso, o acesso não supervisionado permite que você realize tarefas de acompanhamento sem forçá-lo a passar novamente pela cadeia de autenticação.

Por que o RDP exibe “Falha na tentativa de logon da Conexão de Área de Trabalho Remota” mesmo com a senha correta?

Credenciais corretas não compensam a falta de um direito de política. O direito Allow log on through Remote Desktop Services na Política de Segurança Local é um controle separado das permissões de administrador local. Se a sua conta não estiver listada sob esse direito na máquina de destino, o Windows rejeita a conexão antes de confirmar se a senha é válida. Já vi pessoas redefinirem a senha duas vezes, adicionarem sua conta ao grupo Administradores locais e ainda assim enfrentarem o mesmo erro, porque nenhuma dessas ações afeta essa configuração de política.

A segunda causa silenciosa é o Gerenciador de Credenciais no computador que está se conectando. O Windows armazena credenciais de RDP vinculadas ao nome do host ou ao endereço IP do destino. Se essas credenciais salvas estiverem desatualizadas ou pertencerem a uma conta diferente, o Windows pode aplicar automaticamente as credenciais armazenadas para o destino antes de solicitar as suas, dependendo de como a entrada foi salva. Você vê o erro, presume que a senha está errada, muda-a e esbarra no mesmo obstáculo novamente. Em alguns casos, as credenciais armazenadas no Gerenciador de Credenciais substituem a entrada manual, especialmente após alterações de senha.

O bloqueio de conta é uma terceira causa que passa despercebida em ambientes de grupo de trabalho. Se outro dispositivo, uma credencial salva obsoleta em um navegador, ou uma sessão de RDP desconectada estiver tentando repetidamente credenciais antigas para a mesma conta, a conta é bloqueada antes mesmo de você abrir a Conexão de Área de Trabalho Remota. Verificar o painel de gerenciamento de usuários locais da máquina de destino em Gerenciamento do Computador confirma isso em menos de 30 segundos.

O que a maioria das pessoas tenta primeiro após “Falha ao fazer login na Área de Trabalho Remota” (e por que não funciona)

Desativar o Firewall do Windows é o primeiro impulso instintivo. As regras do firewall controlam se a conexão TCP 3389 chega ao destino. Se você alcançar o prompt de credenciais, geralmente o firewall não é a causa.

Adicionar a conta ao grupo Administradores local é o segundo instinto. Privilégios de administrador não concedem o direito de logon nos Serviços de Área de Trabalho Remota. São controles separados. Você pode ser administrador local e ainda assim ser bloqueado no RDP se a permissão da política estiver ausente.

Alternar entre formatos de nome de usuário sem ler o Visualizador de Eventos primeiro é adivinhação. DOMAIN\user, user@domain.com, e o nome de usuário simples podem todos representar a mesma conta. Sem o Event ID 4625 diante de você, não há base para saber o que realmente está falhando.

Executar o cliente Conexão de Área de Trabalho Remota como administrador no computador que está se conectando não tem efeito. A autenticação é feita de acordo com a política de segurança do computador de destino, não do cliente.

Além disso, verifique se a Área de Trabalho Remota está habilitada no computador de destino e se a edição do Windows oferece suporte a conexões de host RDP (o Windows Home não oferece suporte).

Perguntas frequentes

A NLA autentica a sessão antes que a Área de Trabalho Remota seja carregada. Quando a máquina de destino não consegue alcançar o controlador de domínio, ou quando há uma incompatibilidade de versão do CredSSP entre o cliente e o destino, a NLA pode encerrar a tentativa de autenticação antes que a sessão seja iniciada. Isso geralmente aparece como a mensagem The logon attempt failed no lado do cliente. Desativar temporariamente a NLA na máquina de destino na guia Propriedades do Sistema > Remoto confirma se a NLA é a causa.

Execute rsop.msc na máquina de destino e navegue até Configuração do Computador > Configurações do Windows > Configurações de Segurança > Políticas Locais > Atribuição de Direitos de Usuário. Se a conta afetada aparecer em Deny log on through Remote Desktop Services, essa entrada substitui todos os direitos de Permitir e deve ser removida no nível de Diretiva de Grupo em que está sendo aplicada, usando o Console de Gerenciamento de Diretiva de Grupo.

Começando com a atualização do Windows de abril de 2026 (KB5083769), a Microsoft adicionou avisos obrigatórios antes de arquivos .rdp se conectarem, solicitando que os usuários confirmem quais recursos locais compartilhar. Este é um recurso de segurança para evitar ataques de spoofing, mas pode parecer repetitivo se a caixa de diálogo não salvar as preferências. Definir RedirectionWarningDialogVersion como 1 reverte o comportamento da caixa de diálogo para o anterior a abril de 2026 como uma solução alternativa temporária, embora as melhorias de segurança subjacentes permaneçam ativas.


Dica profissional: Configure uma conta de administrador local dedicada para acesso RDP em cada máquina que você gerencia remotamente antes de precisar dela. Dê a ela uma senha forte armazenada em um gerenciador de senhas e conceda o direito Allow log on through Remote Desktop Services no momento da configuração. Quando o controlador de domínio cair, o NLA falhar após uma atualização ou a conta principal enfrentar um conflito de política, essa conta local será o único caminho para a máquina que contorna toda a cadeia de autenticação descrita neste artigo.


Se você gerencia arquivos .rdp para usuários, considere assiná-los com o PowerShell após a atualização de abril de 2026 para evitar avisos de confiança repetidos. Arquivos .rdp não assinados acionarão o novo aviso de spoofing toda vez que forem abertos no Windows 11 com o KB5083769 ou posterior.

Se o erro de falha na tentativa de logon estiver bloqueando seu único caminho para a máquina, e você não tiver acesso ao console, nenhuma conta local alternativa e ninguém no local para alterar as configurações, a solução de problemas padrão do RDP encontra um obstáculo intransponível. Você não pode abrir secpol.msc, limpar o Gerenciador de Credenciais ou desativar a NLA em uma máquina na qual você não consegue fazer logon.


Neste cenário, o HelpWire oferece uma saída prática. O usuário final abre um link de sessão, sem configuração de conta, sem handshake de NLA e sem necessidade de conectividade com o domínio do lado deles. Quando a sessão estiver ativa, você pode aplicar qualquer uma das correções deste artigo de dentro da máquina e restaurar o RDP para uso futuro.

HelpWire
4.6

Potencialize o suporte remoto com um software de área de trabalho remota simples e gratuito.

Visitar o site
Preço: Grátis
Sistemas suportados: Windows, macOS, Linux
HelpWire