Add User or Group cinza no Allow log on through Remote Desktop Services (RDS): como habilitar via GPO e liberar RDP

O botão “Add User or Group” fica cinza em Allow log on through Remote Desktop Services quando o direito de logon está sendo imposto por uma GPO de domínio. Veja como identificar a origem, ajustar no lugar certo (GPMC), aplicar e validar para liberar o acesso RDP com segurança.

Índice

Entenda por que o botão fica cinza

Quando a máquina faz parte de um domínio Active Directory, os direitos de usuário (User Rights Assignment) normalmente são definidos por uma GPO. Nesse caso, a tela Local Security Policy (secpol.msc) fica em modo somente leitura e o botão Add User or Group aparece desativado. Isso é esperado: a origem real da configuração é a GPO aplicada ao computador, não a política local.

Outras situações que mantêm o botão desativado:

Você não está logado com uma conta com privilégios administrativos adequados para editar a GPO que define o direito.
O ajuste vem de uma GPO com prioridade maior (herança + Enforced), tornando inútil alterar políticas locais.
O direito está sendo substituído por Security Templates ou por Baseline de Segurança corporativa aplicada via GPO.

Resumo rápido — passo a passo objetivo

Abrir o Group Policy Management (gpmc.msc) num controlador de domínio.
Editar o GPO correto (o que se aplica ao computador de destino) e navegar até:
Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → User Rights Assignment → Allow log on through Remote Desktop Services
Adicionar os grupos/usuários adequados (ex.: Administrators e/ou Remote Desktop Users, ou um grupo específico da organização).
Verificar e limpar conflitos em Deny log on through Remote Desktop Services.
Garantir que o usuário esteja no grupo correto (ex.: Remote Desktop Users do servidor ou o grupo de domínio equivalente).
Forçar atualização e validar a aplicação: gpupdate /force e gpresult /h C:\gpo.html.

Onde editar? Escolha do GPO certo

Destino	Onde editar	Observações
Controlador de Domínio (DC)	Default Domain Controllers Policy ou um GPO dedicado vinculado à OU Domain Controllers	Evite usar a Default Domain Policy para direitos de logon de DCs.
Servidor membro / Estação	GPO vinculado à OU onde o objeto do computador está	Direitos de usuário são configurações de Computador (não dependem da OU do usuário).

Configuração dentro do GPO (GPMC)

No controlador de domínio, abra gpmc.msc.
Localize o GPO aplicável ao computador de destino e clique em Edit.
Navegue até:
Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → User Rights Assignment
Abra Allow log on through Remote Desktop Services e adicione:
- Administrators (quase sempre presente por padrão); e/ou
- Remote Desktop Users (grupo local no servidor membro, ou grupo Builtin\Remote Desktop Users no domínio).
- Opcionalmente, um grupo de AD dedicado (ex.: GGRDPServidoresApp) — recomendado para facilitar governança.
Em seguida, abra Deny log on through Remote Desktop Services e remova entradas que bloqueiem o público desejado (negações têm precedência sobre permissões).
Feche o editor e aguarde a replicação/atualização de políticas.

Quem deve estar no Allow? Recomendações práticas

Tipo de máquina	Grupos recomendados em Allow	Notas
Servidor membro	Administrators e Remote Desktop Users (local) ou grupo de AD dedicado	Adicione os usuários ao grupo local Remote Desktop Users do servidor (ou use um group nesting de um grupo de AD).
Controlador de Domínio	Administrators e, se necessário, Builtin\Remote Desktop Users (grupo de domínio)	DCs não têm grupos locais; use o grupo Builtin no AD. Permitir RDP em DCs exige cuidado e justificativa.

Verifique e elimine conflitos

A política Deny log on through Remote Desktop Services supera qualquer permissão. Exemplos de armadilhas comuns:

Adicionar o usuário a Remote Desktop Users, mas deixar o mesmo usuário (ou um grupo pai) em Deny.
Um GPO de Hardening corporativo que inclui Guests, Local account ou um grupo amplo em Deny, capturando o usuário indiretamente.
Duas GPOs diferentes definindo o direito: a de maior precedência vence (ordem de link + Enforced).

Associe o usuário ao grupo certo

Definir o direito de logon não basta: o usuário ainda precisa ser membro de um grupo autorizado a usar RDP. Faça assim:

Servidor membro: adicione o usuário ao grupo local Remote Desktop Users do servidor (ou inclua um grupo de AD dentro desse grupo local).
Controlador de Domínio: use Active Directory Users and Computers e gerencie a associação no grupo Builtin\Remote Desktop Users.

Aplicação e validação

No computador de destino, atualize políticas: gpupdate /force
Gere um relatório de Resultant Set of Policy: gpresult /h C:\gpo.html start C:\gpo.html No relatório, em Computer Details, confira:
- O GPO esperado foi aplicado.
- O(s) grupo(s)/usuário(s) constam em Allow log on through Remote Desktop Services.
- Não há entradas indesejadas em Deny log on through Remote Desktop Services.

Como confirmar a origem exata (chaves de direito)

Você pode exportar os direitos de usuário efetivos com secedit e procurar as chaves relacionadas ao RDP:

mkdir C:\Temp 2>NUL
secedit /export /areas USER_RIGHTS /cfg C:\Temp\rights.inf
notepad C:\Temp\rights.inf

Procure por estas entradas (se existirem):

SeRemoteInteractiveLogonRight — Allow log on through Remote Desktop Services
SeDenyRemoteInteractiveLogonRight — Deny log on through Remote Desktop Services

Os valores mostram SIDs ou nomes de grupos/contas que estão autorizados/negados.

Pré-requisitos técnicos para o RDP funcionar

Item	Como verificar	O que esperar
RDP habilitado	`SystemPropertiesRemote.exe` ou via registro	Allow remote connections marcado (ou `fDenyTSConnections=0`).
Firewall	`wf.msc` ou PowerShell	Regra de entrada “Remote Desktop” habilitada (TCP 3389 por padrão).
NLA (opcional)	Propriedades do RDP	Se NLA estiver ativo, o cliente deve autenticar com credenciais válidas do domínio.
Licenciamento (RDS)	Gerenciador de Licenças (se aplicável)	Não bloqueia o primeiro acesso administrativo, mas é necessário para hosts RDS de produção.

Comandos úteis (habilitar RDP rapidamente)

:: Habilitar RDP
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f

\:: Habilitar firewall do RDP
netsh advfirewall firewall set rule group="Remote Desktop" new enable=Yes

\:: Adicionar usuário ao grupo local (servidor membro)
net localgroup "Remote Desktop Users" CONTOSO\joao.silva /add

Diagnóstico quando ainda não funciona

Evento de logon negado: abra o Event Viewer → Windows Logs → Security e filtre por Event ID 4625 com Sub Status 0xC000015B (muitas vezes indica que a conta não tem direito de logon no tipo RemoteInteractive).
GPO não aplicada: no gpresult, verifique se o computador está na OU certa, se há Security Filtering excluindo o objeto do computador, se existe WMI Filter que o exclua e a ordem de link (Link Order + Enforced).
Conflitos de negação: revise todas as GPOs que definem User Rights Assignment e procure Deny log on through RDS herdado.
Erros de credenciais: confirme que o usuário está em um grupo efetivamente listado no Allow e que não herda negações de um grupo pai.

Fluxo de troubleshooting (vista rápida)

O botão está cinza? → Sim → Abra gpmc.msc e localize a GPO que define o direito.
Editar Allow log on through RDS e adicionar os grupos corretos.
Conferir Deny log on through RDS e limpar entradas indevidas.
Garantir associação do usuário aos grupos adequados (local ou de domínio).
Aplicar e validar: gpupdate /force + gpresult + teste de conexão.

Boas práticas de governança e segurança

Evite configurar direitos de logon de controladores de domínio na Default Domain Policy. Prefira a Default Domain Controllers Policy ou um GPO dedicado na OU Domain Controllers.
Crie grupos de AD específicos por função/servidor (ex.: GGRDPSQL, GGRDPBI) e atribua-os no Allow. Use group nesting para facilitar a administração.
Documente os donos dos grupos e implemente revisão periódica de membros.
Minimize o uso de contas com privilégios amplos (Domain Admins) para logons não administrativos.
Use um GPO dedicado aos direitos de logon RDP, com escopo restrito, para reduzir colisões com baselines de segurança.

Diferenças importantes: DC vs. servidor membro

DC: não há base de contas local; grupos “locais” são, na prática, grupos do contêiner Builtin do domínio. Ex.: Builtin\Remote Desktop Users.
Servidor membro: possui grupos locais. Pode-se usar um grupo de AD e aninhá-lo em Remote Desktop Users local.
Política: em ambos os casos, o direito é definido em Computer Configuration → User Rights Assignment e aplicado ao objeto do computador.

Erros comuns (e como evitar)

Editar no lugar errado: mexer em secpol.msc quando a configuração vem de GPO. Solução: editar no gpmc.msc.
Adicionar só no grupo e esquecer o direito: estar no Remote Desktop Users sem o Allow log on through RDS não habilita o logon.
Confundir direitos: Allow log on locally ≠ Allow log on through RDS. São diferentes e independentes.
Ignorar negações: entradas em Deny vencem qualquer Allow.
Aplicar GPO à OU do usuário: não funciona. Direitos de usuário são de Computador.

Alternativas e cenários especiais

Máquina fora do domínio (workgroup)

Use secpol.msc (agora o botão não estará cinza).
Habilite RDP e adicione usuários ao grupo local Remote Desktop Users.

Windows Server Core

:: Habilitar RDP e firewall
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f
netsh advfirewall firewall set rule group="Remote Desktop" new enable=Yes

\:: Atribuir direito via GPO (recomendado) ou usar Security Templates

Ambientes geridos (Baseline corporativa / Intune)

Se você usa baselines de segurança ou MDM (ex.: Intune), os direitos podem vir de uma política central. Ajuste na plataforma de gestão equivalente ao User Rights Assignment para evitar que a GPO “vença” no próximo ciclo.

Checklist final antes do teste

GPO certa, no escopo correto (OU do computador), sem filtros indevidos.
Allow log on through RDS contém os grupos esperados.
Deny log on through RDS sem bloqueios acidentais.
Usuário é membro (direta ou indiretamente) de um grupo autorizado.
RDP habilitado e porta 3389 liberada no firewall.
gpupdate /force executado e gpresult confirmando a aplicação.

Exemplo de modelo de GPO (direitos mínimos)

Direito	Valor recomendado	Notas
Allow log on through Remote Desktop Services	Administrators, Remote Desktop Users (ou grupo de AD dedicado)	Adicionar grupos específicos por função/servidor aumenta a rastreabilidade.
Deny log on through Remote Desktop Services	Somente grupos que você realmente precisa bloquear	Evite negações amplas que possam capturar usuários legítimos.

Perguntas frequentes (FAQ)

Preciso adicionar usuários diretamente em “Allow log on through RDS”?
Não necessariamente. O mais comum é permitir um grupo (ex.: Remote Desktop Users ou um grupo de AD) e gerenciar só a membresia do grupo.

Por que no DC não encontro “usuários e grupos locais”?
DCs não têm base local. Use o grupo do contêiner Builtin no AD, como Builtin\Remote Desktop Users, e configure o direito via GPO da OU Domain Controllers.

Editei a GPO, mas nada mudou. E agora?
Confira a link order, se a GPO está Enforced (por outra GPO), filtros de segurança/WMI, replicação entre DCs e a OU do computador. Valide com gpresult e secedit /export.

Segurança: mínimo privilégio com produtividade

Evite usar contas administrativas para tarefas de usuário final via RDP.
Prefira grupos específicos por função e servidores, com aprovação e owner definido.
Mantenha documentação de quem tem acesso e por que, com revisões periódicas.

Resultado esperado

Depois de definir a permissão no GPO correto, garantir a associação de grupos adequada e atualizar/validar a política, o usuário conseguirá iniciar sessão remotamente via RDP. O botão “Add User or Group” continuará cinza em secpol.msc (porque a origem é a GPO), mas isso é normal e desejado em ambientes geridos.

Dica final de boas práticas

Evite configurar direitos de logon de controladores de domínio na Default Domain Policy. Mantenha-os na Default Domain Controllers Policy ou em um GPO dedicado aplicado apenas à OU Domain Controllers — reduzindo o risco de impacto indevido em outras máquinas do domínio.