Há poucas coisas mais desanimadoras do que sentar-se para se conectar remotamente ao seu próprio PC, digitar suas credenciais e ser informado, da forma menos útil possível, que “uma restrição de conta de usuário (por exemplo, uma restrição de horário) está impedindo você de fazer logon”.

Uma restrição de horário? Eu mesmo configurei esta máquina.

Esse era eu, sem acesso a um servidor Windows Server uma hora depois de migrá-lo para um nível funcional de domínio mais recente. Depois de analisar a documentação da Microsoft e fóruns de administradores de sistemas, acabei juntando as peças do que havia dado errado, e não era o que a mensagem de erro sugeria de forma alguma.

Aqui está o que ninguém lhe diz de antemão: esse erro não é um único problema, é uma categoria. A causa pode ser qualquer coisa, desde uma conta sem senha até um caminho de autenticação que silenciosamente recai para NTLM quando apenas Kerberos é permitido. Depois que você entende isso, já está com metade do caminho andado para corrigi-lo.

Restrição de conta de usuário está impedindo de fazer logon

Sumário

Sintoma / Causa	Ambiente	Primeira ação	Frequência
Em branco / sem senha na conta local	Autônomo / PC doméstico	Correção 1 — Definir uma senha	Comum
Conta ausente da permissão Permitir logon via RDP	Qualquer	Correção 2 — Verificar Atribuição de Direitos de Usuário	Comum
Conta na permissão Negar logon via RDP	Qualquer	Correção 2 — Remover da política de negação	Comum
Conectando por IP, NTLM restrito	Domínio	Correção 3 — Usar nome de host FQDN	Comum
Conta bloqueada	Qualquer	Correção 4 — Desbloquear no ADUC / lusrmgr	Ocasional
Restrição de horário de logon	Domínio	Correção 4 — Verificar Horários de Logon no ADUC	Ocasional
Conta em Usuários Protegidos, Kerberos com falha	Domínio	Correção 5 — Reparar o Kerberos ou remover do grupo	Admin/fortalecido
Logs de eventos mostram falha de autenticação	Qualquer	Correção 6 — Ler o log de Segurança (Evento 4625)	Diagnóstico

A correção de que você precisa depende inteiramente do seu ambiente. Passe por estas perguntas antes de mexer em qualquer coisa.

Você consegue fazer logon localmente com a mesma conta? Se sim, e apenas o RDP falha, não se trata de credenciais inválidas. O problema é uma atribuição de direitos do RDP, uma restrição de política ou um problema no caminho de autenticação. Verifique no Visualizador de Eventos → Logs do Windows → Segurança, na máquina de destino, o ID do Evento 4625. Para ambientes de domínio, verifique também os logs de segurança dos controladores de domínio, pois algumas falhas de autenticação só são visíveis lá.

Um usuário ou todos? Um único usuário bloqueado aponta para uma configuração no nível da conta. Todos bloqueados simultaneamente sugere uma alteração recente de política, uma atualização de Diretiva de Grupo ou uma mudança de configuração no lado do servidor.

Máquina autônoma ou ingressada no domínio? Ambientes de domínio introduzem diretivas de grupo do Active Directory, Kerberos, restrições de NTLM e o comportamento de Usuários Protegidos. Se você estiver em um PC doméstico autônomo, apenas as Correções 1, 2 e 4 provavelmente são relevantes. Se você estiver em um domínio, todas as correções podem se aplicar.

Você está se conectando por endereço IP ou nome do host? Isso importa mais do que a maioria das pessoas imagina. Conectar-se por endereço IP geralmente impede o Windows de usar Kerberos e força o uso de NTLM como alternativa. Se o NTLM for restrito no seu ambiente, essa alternativa falha e você recebe exatamente este erro, embora nada na sua conta em si tenha mudado. Veja a Correção 3.

Algo mudou recentemente? Atualizações de Diretiva de Grupo, patches do sistema operacional, upgrades do nível funcional do domínio e fortalecimento de segurança podem quebrar o RDP da noite para o dia sem aviso visível. Sempre faça essa pergunta antes de presumir que o problema é a sua conta.

As correções 1–4 são as mais relevantes aqui. Elas não exigem nenhum conhecimento de Active Directory ou de domínio.

Comece por aqui, especialmente em um PC doméstico ou em uma máquina autônoma.

Por padrão, o Windows bloqueia logons remotos para contas locais que não têm senha. Isso é intencional e é uma política de segurança documentada: a configuração “Accounts: Limit local account use of blank passwords to console logon only” está habilitada por padrão, o que significa que contas sem senha ficam restritas a logons interativos no console. O RDP é um logon interativo remoto e, portanto, é bloqueado.

Por que isso acontece: Microsoft documenta esse comportamento na configuração da política de segurança local “Contas: Limitar o uso de senhas em branco por contas locais somente para logon no console.” (Microsoft Learn)

Defina uma senha: abra o Gerenciamento do Computador → Usuários e Grupos Locais → Usuários → clique com o botão direito na conta → Definir Senha. Se isso resolver, pronto.

Há uma solução alternativa: você pode desativar a restrição de senha em branco via secpol.msc ou a chave do Registro LimitBlankPasswordUse. Trate isso como último recurso em qualquer máquina acessível pela rede.

Aviso: Desativar as restrições de senha em branco enfraquece significativamente sua superfície de ataque. Definir uma senha forte é sempre a solução correta.

Esta é uma das causas mais comuns e uma das mais fáceis de passar despercebidas.

O Windows usa duas configurações de Política de Grupo complementares para controlar o acesso via RDP:

Permitir logon através dos Serviços de Área de Trabalho Remota — concede o direito de se conectar.
Negar logon através dos Serviços de Área de Trabalho Remota — bloqueia o direito de se conectar.

A política Negar sempre prevalece sobre Permitir, independentemente da associação a grupos. Este é um comportamento documentado pela Microsoft.

Onde encontrá-lo: Abra gpedit.msc → Configuração do Computador → Configurações do Windows → Configurações de Segurança → Políticas Locais → Atribuição de Direitos do Usuário.

Verifique ambas as políticas. Confirme que a sua conta, ou um grupo ao qual ela pertence, como Usuários da Área de Trabalho Remota ou Administradores, aparece em Permitir. Confirme que ela não aparece em Negar. Se a sua conta não estiver em Permitir, o acesso por RDP é bloqueado independentemente da sua senha ou credenciais.

Em máquinas no domínio: Esses direitos podem ser definidos no nível de domínio pela Política de Grupo e podem substituir as configurações locais. Se as configurações locais parecerem corretas, mas o problema persistir, verifique se há GPOs conflitantes usando gpresult /h report.html no computador de destino.

Esta única alteração resolve mais problemas do que seria de esperar.

Ao conectar-se usando um endereço IP (por exemplo, 192.168.1.100), o Windows normalmente não consegue usar a autenticação Kerberos e recorre ao NTLM. Em máquinas domésticas independentes isso geralmente é aceitável. Em máquinas ingressadas no domínio, onde o NTLM é restrito ou desativado, esse fallback falha silenciosamente, e você recebe o erro de restrição de conta, embora nada na sua conta tenha mudado.

Use o nome de host da máquina em vez disso:

server.yourdomain.com ✔ Recomendado

192.168.1.100 ✘ Força o fallback para NTLM

Também use credenciais no formato UPN ao conectar-se a máquinas de domínio: user@domain.com em vez de DOMAIN\user. Isso ajuda o Windows a selecionar o caminho de autenticação correto e evita um número surpreendente de casos-limite.

Exceção: A Microsoft documentou uma capacidade mais recente de Kerberos sobre IP para ambientes do Windows Server, mas ela requer configuração explícita e não está habilitada por padrão. (Microsoft Learn: Configurando o Kerberos para endereço IP).

O Windows retorna a mesma mensagem genérica para vários tipos distintos de restrições, o que é parte do que torna esse erro tão frustrante. Bloqueios de conta e restrições de horário de logon são dois dos raros casos em que a mensagem de erro é literalmente correta.

Para contas locais (autônomas ou de domínio) Abra lusrmgr.msc → selecione o usuário → verifique se Conta bloqueada está marcada. Desbloqueie-a, se estiver.

Para contas de domínio Abra Usuários e Computadores do Active Directory → localize o usuário → clique duas vezes → guia Conta. Marque a opção Desbloquear a conta e revise as Horas de logon.

Um administrador do Windows Server 2016 descreveu ter esbarrado exatamente nesse obstáculo: conectar-se ao servidor falhava com a mensagem de restrição de conta, mas nenhuma restrição de horário havia sido configurada deliberadamente. A causa foi uma Diretiva de Grupo que havia aplicado silenciosamente uma restrição de logon após uma atualização da política de domínio. O ID do evento 4625 no Log de Segurança teria mostrado o subcódigo específico.

Evento 4625: A entrada do log de Segurança para um logon com falha inclui um código de substatus que identifica o motivo exato. Valores comuns: 0xC0000234 (conta bloqueada), 0xC000006F (logon fora do horário permitido), 0xC0000022 (acesso negado). Verifique isso antes de adivinhar a causa.

As correções 5 e 6 exigem acesso ao Active Directory e familiaridade com Kerberos e NTLM. Se você estiver em um PC doméstico autônomo, pode pular esta seção.

Este é o modo de falha que pega administradores experientes de surpresa, frequentemente após uma atualização de domínio.

O grupo de segurança Protected Users do Active Directory impõe regras de autenticação mais rígidas aos seus membros:

A autenticação NTLM é totalmente bloqueada.
Apenas Kerberos é permitido, e somente com criptografia AES.
Os tipos de criptografia Kerberos RC4 e DES não são permitidos.
As credenciais não são armazenadas em cache na máquina.

Na teoria, isso é uma excelente prática de segurança. Na prática, isso quebra o acesso via RDP em ambientes que dependiam silenciosamente de NTL, o que é exatamente o que acontece quando você se conecta pelo endereço IP, quando o DNS está mal configurado ou quando o Kerberos não foi totalmente validado após uma atualização de domínio. O usuário recebe a mensagem genérica de restrição de conta sem nenhuma indicação de que Protected Users está envolvido.

Por que isso surge após atualizações de domínio: Elevar o nível funcional do domínio frequentemente permite uma imposição mais rigorosa das políticas existentes. Contas que já estavam em Usuários Protegidos, mas anteriormente toleravam reverter para NTLM, podem falhar repentinamente. (Microsoft Learn: Grupo de Segurança Usuários Protegidos)

Antes de remover alguém de Protected Users, tente estas etapas nesta ordem:

Use o FQDN da máquina (server.domain.com), e não um endereço IP.
Use credenciais UPN (user@domain.com).
Verifique se a resolução de DNS funciona corretamente a partir da máquina que está se conectando.
Confirme a conectividade com o controlador de domínio e que o serviço Kerberos está em execução.

Se o Kerberos estiver funcionando corretamente, o problema geralmente desaparece sem quaisquer alterações de conta. Caso contrário, você pode remover a conta de Protected Users como medida temporária:

powershell
$Cred = Get-Credential Remove-ADGroupMember -Identity "Protected Users" -Members YourAccountName -Credential $Cred

Sobre o PowerShell Remoting: Essa abordagem funciona quando o PowerShell Remoting está disponível. Observe que o PowerShell Remoting também usa Kerberos quando disponível e NTLM como alternativa, portanto, pode enfrentar as mesmas restrições de autenticação em ambientes totalmente reforçados. (Microsoft Learn: Segurança do WinRM)

Aviso: Remover uma conta de Usuários Protegidos enfraquece sua postura de segurança. Trate isso como uma etapa de diagnóstico, não uma correção permanente. A resolução correta é garantir que o Kerberos funcione corretamente em seu ambiente.

Encerre a sessão e permita que a autenticação seja atualizada antes de tentar novamente o RDP após qualquer alteração na associação a grupos.

Neste ponto, pare de adivinhar e comece a ler.

Na máquina de destino Visualizador de Eventos → Logs do Windows → Segurança. Filtre pelo ID de Evento 4625. Cada entrada inclui um Motivo da Falha e um código de Substatus que identifica a causa exata, de forma muito mais precisa do que a própria mensagem de erro do RDP.

Para um rastreamento de autenticação mais detalhado, ative também: Logs de Aplicativos e Serviços → Microsoft → Windows → Authentication.

Nos controladores de domínio Algumas falhas de autenticação, especialmente as relacionadas ao Kerberos, são registradas apenas no controlador de domínio que processou a solicitação, não na máquina de destino. Verifique os logs de Segurança nos seus DCs quando os logs locais da máquina de destino não estiverem fornecendo o quadro completo.

Depois que você encontrar o código de Substatus no Evento 4625, o erro deixa de ser vago e se torna um problema específico e diagnosticável. Os códigos comuns estão listados na nota da Correção 4 acima.

Se você vir o código de erro 0xC07, particularmente no macOS ao usar o Microsoft Remote Desktop, ele normalmente aparece junto com a mesma classe de problemas de autenticação e restrições descritos neste artigo. Relatos da comunidade sugerem que conectar pelo nome de host em vez do endereço IP resolve o problema em muitos casos, o que é consistente com o padrão de fallback do NTLM descrito em Fix 3.

Não há documentação definitiva da Microsoft que mapeie de forma clara o 0xC07 a uma única causa raiz. Trate-o como um sinal de que você está na categoria certa de problema, e não como um diagnóstico preciso. As correções acima se aplicam.

Quando o acesso RDP é negado com a mensagem “user account restriction”, o Windows está fazendo exatamente o que deveria fazer, apenas sem informar qual regra você violou.

O caminho mais rápido para a solução é:

Use a matriz de diagnóstico no topo deste artigo para identificar a causa mais provável.
Aplique a correção relevante para o seu ambiente (doméstico/autônomo ou de domínio).
Verifique o ID do Evento 4625 na máquina de destino se a causa ainda não estiver clara.
Para ambientes de domínio, verifique também os logs do controlador de domínio e confirme que o Kerberos está funcionando antes de alterar as configurações de conta.

Na maioria das vezes é algo simples. Mesmo quando não é, geralmente é algo lógico, apenas oculto por trás de uma mensagem pouco útil.

Como corrigir a restrição da conta de usuário que está impedindo o logon

Diagnóstico Rápido

Parte 1: PC doméstico & Máquinas independentes

Correção 1: A Conta Não Tem Senha

Correção 2: Verifique quem está autorizado a se conectar via RDP

Correção 3: Pare de se conectar pelo endereço IP

Correção 4: Verifique se há bloqueios de conta e restrições de horário de logon

Parte 2: Ambientes de Domínio e Empresariais

Correção 5: O Grupo Usuários Protegidos

Correção 6: Leia os logs quando nada mais fizer sentido

E quanto ao código de erro 0xC07?

Resumo