Acesso VPN sem direitos de área de trabalho remota: quatro portas separadas

Um utilizador liga-se à VPN, abre uma partilha de ficheiros e uma aplicação interna, e depois uma tentativa de RDP devolve «a conta de utilizador não está autorizada para o início de sessão remoto». Nessa mensagem não há nada errado com o túnel. Quatro portas independentes situam-se entre uma conta VPN e um ambiente de trabalho interativo, e só a última o produziu. As pessoas costumam responder adicionando a conta a Administrators, o que concede muito mais do que o ambiente de trabalho e não corrige a porta se a Política de Grupo a negar. Eis o que cada porta faz realmente, e como alterar apenas a que está a recusar.

Quatro portas numa ordem fixa

O gateway decide primeiro se a identidade pode estabelecer um túnel: uma política RADIUS, uma condição de grupo, uma verificação de certificado, uma permissão do Access Server. Depois o encaminhamento e as firewalls decidem se o pacote do conjunto de túneis chega ao ouvinte TCP 3389 do destino. Depois o handshake NLA do cliente autentica a conta no destino. Só depois destas três é que a autoridade de segurança local verifica se a conta possui o direito de logon exigido por uma sessão remota interativa.

Como a ordem é fixa, cada porta esconde as que estão atrás. Um túnel falhado não diz nada sobre o encaminhamento; uma porta bloqueada não diz nada sobre o direito de logon; um teste de porta bem-sucedido não diz nada sobre a admissão. É por isso que «a VPN funciona mas o RDP não» não é um único problema mas uma fronteira entre duas destas portas, e é por isso que o texto do erro é a forma mais rápida de saber em qual bateu.

O direito que realmente recusa a sessão

O início de sessão na área de trabalho remota exige o direito de utilizador Permitir início de sessão através dos Serviços de Ambiente de Trabalho Remoto, SeRemoteInteractiveLogonRight. É verificado no início de sessão, não na configuração do túnel, pelo que uma conta pode navegar na rede durante horas e ainda assim ser-lhe negado um ambiente de trabalho. A caixa de diálogo que o mostra está em Políticas Locais, Atribuição de Direitos de Utilizador, e o equivalente de domínio está numa GPO.

A pertença predefinida depende do papel da máquina: as estações de trabalho e os servidores membros concedem-no a Administrators e Remote Desktop Users, enquanto um controlador de domínio o concede apenas a Administrators. Esse único facto explica a maior parte da confusão, porque a mesma conta tem sucesso num servidor de ficheiros e falha num DC. Um direito de negação prevalece sobre o direito de permissão correspondente independentemente da pertença ao grupo, pelo que uma conta que tem simultaneamente permissão e negação fica negada. Um grupo de negação amplo pode apanhar um administrador adicionado por favor.

Leia a política efetiva, não a caixa de diálogo local

A política local é substituída por qualquer GPO de domínio que defina o mesmo direito, pelo que o snap-in local pode mostrar uma lista aparentemente correta enquanto o estado efetivo é diferente. Exporte o que a máquina aplica realmente, depois procure o direito e leia os SID em vez dos nomes apresentados:

secedit /export /cfg C:\temp\secpol.cfg
Select-String -Path C:\temp\secpol.cfg -Pattern SeRemoteInteractiveLogonRight
gpresult /scope computer /v

Nessa saída, *S-1-5-32-544 é Administrators e *S-1-5-32-555 é Remote Desktop Users.

Se nenhum aparecer, ninguém exceto um titular de política pode abrir um ambiente de trabalho, diga o que disser a caixa de diálogo local de Utilizadores e Grupos. Então gpresult nomeia a GPO que venceu, e é esse o objeto que deve editar; alterar a política local numa máquina associada ao domínio é um teste, não uma correção.

Conceda o direito mais estreito que se aplica

A resposta habitual é o grupo Remote Desktop Users no destino. Transporta o direito por predefinição, é muito mais pequeno do que Administrators e separa «pode abrir um ambiente de trabalho» de «pode gerir o servidor». Onde a política reatribuiu o direito explicitamente, adicione o grupo ou a conta a essa política em vez de adicionar um grupo que ninguém pensou como controlo de acesso.

Add-LocalGroupMember -Group "Remote Desktop Users" -Member "CORP\a.user"

Verifique a lista de negações antes de adicionar qualquer coisa. Se um direito de negação nomear um grupo que contém o utilizador, a alteração correta é remover a conta desse grupo ou restringir a negação, não adicionar uma segunda permissão noutro local. Registe que direito alterou e onde, porque uma atualização posterior da GPO restaurará silenciosamente o estado anterior e o ticket reabrirá com a mesma mensagem.

Mantenha o caminho de rede como uma decisão separada

O grupo VPN não tem de chegar a todas as portas. Quando um grupo precisa de uma aplicação e não de um ambiente de trabalho, uma regra de firewall limitada ao conjunto de túneis e à porta da aplicação dá efeito a essa política, enquanto o direito de logon permanece intacto.

Get-NetFirewallRule -DisplayGroup "Remote Desktop"
Test-NetConnection -ComputerName 10.20.0.50 -Port 3389

A configuração por cliente do OpenVPN e as permissões de grupo do Access Server podem restringir os prefixos de destino no mesmo espírito; nenhuma delas concede um direito de logon do Windows, e um direito de logon não pode abrir uma porta. Mantenha-as em janelas de alteração separadas, porque uma regra de porta e um direito são aprovados por pessoas diferentes.

Verifique na mesma ordem em que as portas se aplicam: a conta consegue estabelecer o túnel, a sessão chega ao ouvinte, o cliente autentica-se e a conta possui o direito. Um ping que falha enquanto o teste de porta tem sucesso é uma firewall que responde de forma diferente ao ICMP, não uma prova de que o RDP está bloqueado. A referência da Microsoft sobre o direito de logon lista os valores predefinidos por papel da máquina e a regra de que a negação prevalece sobre a permissão.