Active Directory: restringir logon de usuários de domínio a PCs designados (ADUC, GPO e RDP)

Quer impedir que usuários de domínio entrem em PCs aleatórios e limitar cada pessoa apenas ao(s) seu(s) computador(es) designado(s)? Veja duas abordagens oficiais do Windows/Active Directory — por usuário (ADUC) e por computador (GPO) — com passos, scripts, testes e dicas de produção.

Índice

Visão geral e objetivo

Em ambientes Windows com Active Directory (AD), é comum precisar restringir o logon (interativo/local e via RDP) para garantir que cada colaborador só acesse o(s) computador(es) autorizado(s). Isso reduz superfícies de ataque, dificulta movimentos laterais e simplifica auditoria. A boa notícia é que existe mais de uma forma correta de cumprir esse requisito — e elas se complementam:

Opção A (por usuário): configurar, na conta do usuário no AD, em quais estações ele pode se autenticar.
Opção B (por computador): usar Diretiva de Grupo (GPO) para permitir o logon apenas a um conjunto de usuários/grupos em cada máquina.

Se você administra poucos PCs e a relação costuma ser 1:1 (um usuário por computador), a Opção A é direta e eficaz. Para laboratórios, turnos, times compartilhando estações ou cenários de grande escala, a Opção B oferece controle fino, repetível e sustentável.

Resumo rápido: qual opção escolher?

Critério	Opção A — Por usuário (ADUC)	Opção B — Por computador (GPO)
Escopo ideal	Poucos usuários; 1 ou poucos PCs por pessoa.	Laboratórios, equipes, muitos PCs por OU, produção em escala.
Facilidade inicial	Alta: ajuste rápido por conta de usuário.	Média: requer GPO, grupos por máquina e OU organizadas.
Manutenção	Manual por usuário (troca de equipamento exige atualizar a lista).	Mais previsível: adicione/remova pessoas do grupo certo.
Risco de erro amplo	Baixo, pois é granular por usuário.	Moderado: GPO mal vinculada pode afetar muitas máquinas.
Offline/cached logon	Observação: restrição pode não se aplicar se o PC estiver offline e o usuário já tiver credenciais em cache.	Funciona localmente mesmo offline (direitos de logon são locais após aplicação do GPO).
RDP (Remote Desktop)	Em geral funciona; ainda assim, recomenda-se reforçar com GPO.	Controle explícito via “Permitir fazer logon por Serviços de Área de Trabalho Remota”.

Opção A — Restringir por usuário no AD (1:1 usuário ⇄ computador)

Nesta abordagem, você informa ao Active Directory em quais estações um usuário pode se autenticar. É a forma mais direta para a maioria dos escritórios onde cada pessoa tem um PC dedicado.

Passos no ADUC

Abrir Usuários e Computadores do Active Directory (ADUC).
Abrir Propriedades da conta do usuário.
Ir à aba Conta → botão Fazer logon em… (Log On To…).
Marcar Somente nos seguintes computadores e adicionar o(s) nome(s) NetBIOS das estações permitidas (ex.: PC001, NOTEBOOK23).
Clicar em Aplicar / OK.

Boas práticas do método por usuário

Nome NetBIOS: utilize o nome curto da máquina (não FQDN). O campo aceita uma lista separada por vírgulas.
Limite do atributo: o campo possui limite de tamanho (aprox. 1 KB). Evite listas extensas; para muitos PCs, prefira a Opção B.
Trocas de equipamento: ao substituir o PC do usuário, atualize a lista imediatamente para evitar bloqueios inesperados.
Conectividade com DC: em cenários offline (uso de credenciais em cache), essa restrição pode não ser aplicada; complemente com GPO quando necessário.

Quando usar

Empresas com estações dedicadas por usuário.
Ambientes com baixa rotatividade de hardware.
Casos onde o controle por máquina via GPO seria desproporcional.

Exemplo rápido em PowerShell

# Definir as estações permitidas para um usuário
Set-ADUser -Identity j.silva -LogonWorkstations "PC001","PC002"

Opção B — Restringir por computador via GPO (controle fino e escalável)

Aqui, você define na máquina quem pode fazer logon. O controle ocorre através de Diretivas de Grupo e dos direitos de usuário (User Rights Assignment). É a abordagem preferida para laboratórios, times compartilhando PCs e ambientes grandes.

Estratégia de grupos por máquina

Crie um grupo de domínio para cada computador (ex.: GRP-PC001-Logon) e adicione ao grupo apenas os usuários autorizados para aquela estação. Isso simplifica a operação: para dar ou retirar acesso, basta gerenciar a membresia do grupo.

Direitos de usuário a configurar

Crie/edite um GPO e vincule à OU que contém os computadores (não os usuários). Em Configuração do Computador → Configurações do Windows → Configurações de Segurança → Políticas Locais → Atribuição de Direitos de Usuário, ajuste:

Permitir fazer logon localmente (Allow log on locally)
Recomendado: remover grupos amplos (ex.: Users/Usuários) e incluir apenas:
- Administrators (administradores da máquina).
- Grupo específico da máquina, ex.: GRP-PC001-Logon.
Permitir fazer logon por Serviços de Área de Trabalho Remota (Allow log on through Remote Desktop Services)
Se houver RDP: mesmo princípio: remova grupos amplos e inclua apenas Administrators e o grupo da máquina (ou, em servidores de sessão, um grupo próprio de usuários RDS).
(Opcional) Acessar este computador a partir da rede / Negar acesso a este computador a partir da rede
Use somente se também quiser restringir conexões de rede (CIFS/SMB). Esses itens não controlam logon interativo/RDP.

Mapa de configuração por tipo de máquina

Tipo de máquina	Permitir logon local	Permitir logon via RDP	Observações
Estações de trabalho (usuário dedicado)	Administrators + `GRP-PCxxx-Logon`	Se usado, idem ao lado	Remover Users para evitar logon indevido.
Estações compartilhadas (laboratório)	Administrators + grupo do laboratório	Se usado, grupo do laboratório	Gerir acesso por turnos adicionando/removendo usuários do grupo.
Servidores membro	Administrators + grupo restrito (se necessário)	Administrators + grupo de RDP do servidor	Evite conceder acesso amplo; nunca aplique isso em Controladores de Domínio.

Boas práticas com GPO

Grupos por máquina: padronize nomenclatura (GRP-<HOST>-Logon) e armazene em uma OU de grupos.
Evite “Negar logon …” para grupos amplos (como Domain Users): a negação tem precedência e pode bloquear quem precisa entrar.
Nunca vincule a GPO de estações em DCs: Controladores de Domínio têm requisitos especiais.
Testes em uma OU piloto antes de produção.
Conta “break glass”: mantenha uma conta de emergência com acesso local documentado para contingência.

Exemplos em PowerShell (grupos)

# Criar grupo por máquina e adicionar usuário
New-ADGroup -Name "GRP-PC001-Logon" -GroupScope Global -Path "OU=Grupos,DC=contoso,DC=local"
Add-ADGroupMember -Identity "GRP-PC001-Logon" -Members "j.silva"

Script de massa: criar grupos para uma lista de hosts

\$hosts = @("PC001","PC002","PC003")
foreach (\$h in \$hosts) {
\$g = "GRP-\$h-Logon"
if (-not (Get-ADGroup -Filter "Name -eq '\$g'" -ErrorAction SilentlyContinue)) {
New-ADGroup -Name \$g -GroupScope Global -Path "OU=Grupos,DC=contoso,DC=local"
}
}

Fluxo de implementação recomendável

Inventário: liste PCs e donos/responsáveis.
Escolha a abordagem: A (ADUC) para 1:1; B (GPO) para equipes/labs/escala; ou combinação para dupla proteção.
Preparação: crie grupos por máquina (Opção B) e garanta OU de computadores bem organizada.
Aplicação:
- Opção A: configure Fazer logon em… no usuário.
- Opção B: vincule GPO na OU de computadores e ajuste os direitos de logon conforme tabela.
Atualização dos clientes: gpupdate /force.
Validação: gpresult /r ou gpresult /h C:\Temp\GPO.html e testes práticos (usuário autorizado deve conseguir; não autorizado deve ser bloqueado).
Documentação e rollback: registre as mudanças e o plano de reversão.

Validação e testes (passo a passo)

Forçar atualização de políticas

gpupdate /force

Conferir GPOs aplicadas

gpresult /r
gpresult /h C:\Temp\GPO.html

Confira na seção de User Rights Assignment se os itens “Permitir fazer logon localmente” e “Permitir fazer logon por Serviços de Área de Trabalho Remota” estão conforme o planejado.

Testes de logon

Usuário autorizado no PC certo: deve conseguir logar normalmente.
Usuário não autorizado no PC errado: deve receber mensagem como “O método de entrada que você está tentando usar não é permitido”.

Eventos úteis para auditoria

4624 — Sucesso de logon.
4625 — Falha de logon (procure Status/SubStatus como 0xC000015B — tipo de logon não concedido).
4776 — Validação de credenciais NTLM (útil para diagnósticos).

Verifique também o Tipo de Logon: 2 (interativo/local) e 10 (RDP/Remoto).

Erros comuns (e como evitar)

Editar “Acessar este computador a partir da rede” achando que afeta logon local/RDP: esse ajuste controla acesso a recursos via rede (ex.: \\PC\C$), não autenticação local/Remote Desktop.
Usar “Negar logon…” para Domain Users: a negação tem precedência e pode bloquear inclusive quem deveria entrar. Prefira listar apenas quem pode nos itens “Permitir…”.
Vincular GPO na OU errada: para a Opção B, o vínculo é na OU de computadores, não na de usuários.
Aplicar em Controladores de Domínio: não faça. DCs possuem perfis próprios de segurança.
Esquecer do modo offline (credenciais em cache) quando usar só a Opção A: complemente com GPO se o requisito for absoluto.

FAQ — Perguntas frequentes

Isso impacta mapeamento de drives ou compartilhamentos?

Somente se você também ajustar “Acessar/Negar acesso a este computador a partir da rede”. Para logon local/RDP, os itens principais são “Permitir fazer logon localmente” e “Permitir fazer logon por Serviços de Área de Trabalho Remota”.

Preciso manter o usuário no grupo local “Remote Desktop Users”?

Quando você define “Permitir fazer logon por Serviços de Área de Trabalho Remota” via GPO para um grupo de domínio, esse grupo passa a deter o direito de logon remoto. A membresia no grupo local pode ser desnecessária, desde que o direito esteja concedido pelo GPO.

Tenho notebooks que às vezes ficam fora do domínio. O que fazer?

Se houver uso intenso offline, a Opção A isoladamente pode não sustentar a restrição (credenciais em cache). Para garantir consistência, adote a Opção B nas estações e complemente com criptografia (BitLocker) e práticas de hardening.

Como lidar com contas de serviço?

Contas de serviço não devem efetuar logon interativo. Restrinja-as removendo direitos de logon interativo e permitindo apenas os direitos necessários ao serviço. Evite negações amplas que afetem usuários legítimos.

E servidores de Terminal (RDS) para muitos usuários?

Crie um grupo próprio (ex.: GRP-RDS-Usuarios) e use-o no item “Permitir fazer logon por Serviços de Área de Trabalho Remota”. Gerencie acesso adicionando/removendo usuários desse grupo, sem alterar GPOs por servidor.

Exemplos práticos de cenários

Escritório com PCs dedicados

Use a Opção A para cada usuário apontando seu PC.
Em TI, adote também a Opção B para as máquinas críticas (dupla camada).

Laboratório de treinamento com 20 PCs e 3 turmas por dia

Crie GRP-LAB-Logon por laboratório ou por conjunto de turnos.
Vincule um GPO à OU dos computadores do lab, permitindo logon a esse grupo.
Adicione/remova alunos do grupo conforme a turma do dia.

Equipe de suporte compartilhando 5 estações

Opção B com grupos por máquina ou um grupo único do time aplicado às 5 estações.
Rastreie alterações de membresia para auditoria.

Automação e governança

Abaixo, um exemplo para auditar quais usuários podem logar em cada PC (quando você segue a estratégia de grupos por máquina):

# Listar membros autorizados por máquina com padrão GRP-&lt;HOST&gt;-Logon
$grupos = Get-ADGroup -Filter 'Name -like "GRP-*-Logon"'
$saida = foreach ($g in $grupos) {
  $membros = Get-ADGroupMember $g | Select-Object -ExpandProperty SamAccountName
  [PSCustomObject]@{
    Grupo = $g.Name
    Membros = ($membros -join ",")
  }
}
$saida | Format-Table -AutoSize

Troubleshooting avançado

RSOP: execute rsop.msc para ver a Resultant Set of Policy.
Exportar política local: secedit /export /cfg C:\Temp\secpol.inf e revise as entradas de SeInteractiveLogonRight (logon local) e SeRemoteInteractiveLogonRight (RDP).
Ver grupos efetivos: whoami /groups para conferir a tokenização do usuário.
Mensagens de erro: “o método de entrada não é permitido” geralmente está ligado a falta do direito “Permitir…” ou presença indevida de “Negar…”.

Checklist de segurança e operação

Padronize nomes de grupos (GRP-<HOST>-Logon).
Documente o owner do grupo (quem pode adicionar/remover membros).
Monitore mudanças de membresia (SIEM / relatórios de AD).
Mantenha uma conta de emergência fora das restrições, com guarda segura das credenciais.
Reavalie a cada substituição de hardware.

Passo a passo consolidado (guia de bolso)

ADUC: Conta do usuário → Conta → Fazer logon em… → listar PCs permitidos.
GPO: OU de computadores → Definir “Permitir fazer logon localmente” e “Permitir fazer logon por Serviços de Área de Trabalho Remota” com grupos por máquina.
Aplicar: gpupdate /force e validar com gpresult.
Testar: usuário autorizado (sucesso) e não autorizado (bloqueio).
Operar: mexa apenas na membresia dos grupos; não reabra GPO sem necessidade.

Apêndice — comandos úteis

:: Atualizar política
gpupdate /force

\:: Ver políticas aplicadas (resumo e relatório HTML)
gpresult /r
gpresult /h C:\Temp\GPO.html

\:: Ver grupos efetivos do usuário logado
whoami /groups

\:: Exportar política local (para inspeção de direitos de logon)
secedit /export /cfg C:\Temp\secpol.inf

Resumo executivo

Para limitar o logon a PCs designados no Windows/AD, use o que é nativo e seguro: o atributo “Fazer logon em…” no usuário (Opção A) e/ou os direitos de logon via GPO por máquina (Opção B). Em escritórios com 1:1, a Opção A resolve rápido; em laboratórios e em escala, a Opção B oferece controle centralizado, auditável e resiliente — inclusive quando as máquinas ficam temporariamente offline. Combine as duas quando precisar de uma camada extra de proteção e mantenha grupos por máquina para facilitar a operação diária.

Dicas rápidas de escolha

Poucos usuários, 1 PC por pessoa: ADUC → Fazer logon em… (Opção A).
Muitos PCs/turnos/laboratórios: GPO por computador com “Permitir logon local/RDS” + grupos por máquina (Opção B).
Restringir compartilhamentos de rede: complemente com “Acessar/Negar acesso a este computador a partir da rede”.

# (Relembrando) Exemplo de criação e uso de grupos por máquina
New-ADGroup -Name "GRP-PC001-Logon" -GroupScope Global -Path "OU=Grupos,DC=contoso,DC=local"
Add-ADGroupMember -Identity "GRP-PC001-Logon" -Members "j.silva"
Referencie esse grupo em “Permitir fazer logon localmente” e, se aplicável, em “Permitir fazer logon por Serviços de Área de Trabalho Remota”.

Com esse desenho, cada usuário consegue iniciar sessão apenas no(s) equipamento(s) designado(s), reduzindo o risco de acesso indevido e elevando o nível de conformidade e governança do seu ambiente.