Recentemente, implementamos uma solução em um servidor terminal Windows. Como é de praxe, criamos atalhos na área de trabalho dos funcionários para conexão e dissemos — trabalhem. Mas os usuários ficaram alarmados em relação à Cibersegurança. Ao se conectar ao servidor, ao ver mensagens como: "Você confia neste servidor? Tem certeza?", ficavam assustados e nos procuravam — se estava tudo bem, podiam clicar em OK? Foi então que decidimos tornar tudo mais bonito, para que não houvesse mais perguntas ou pânico.
Se os seus usuários ainda vêm até você com esses medos, e você está cansado de marcar a opção "Não perguntar novamente" — sinta-se à vontade para continuar.
Passo zero. Preparação e questões de confiança
Então, nosso usuário clica no arquivo salvo com a extensão .rdp e recebe um pedido como este:
"Conexão maliciosa".
Para eliminar essa janela, utilizamos uma ferramenta chamada RDPSign.exe. A documentação completa está disponível, como de costume, no , e vamos analisar um exemplo de uso.
Para começar, precisamos obter um certificado para assinar o arquivo. Ele pode ser:
- Público.
- Emitido por um serviço interno de Autoridade Certificadora.
- Completamente autoassinado.
O mais importante é que o certificado tenha a capacidade de assinar (sim, pode-se obter
de contadores a assinatura digital), e os PCs clientes confiem nele. Aqui, vou usar um certificado autoassinado.
Lembro que a confiança em um certificado autoassinado pode ser organizada por meio de políticas de grupo. Mais detalhes — abaixo do spoiler.
Como tornar o certificado confiável usando a mágica do GPO
Primeiro, deve-se obter o certificado existente sem a chave privada no formato .cer (isso pode ser feito exportando o certificado da ferramenta "Certificados") e colocá-lo em uma pasta de rede acessível aos usuários para leitura. Depois, você pode configurar a política de grupo.
A importação do certificado é configurada na seção: Configuração do computador — Políticas — Configuração do Windows — Configurações de segurança — Políticas de chave pública — Centros de certificação raiz confiáveis. Depois, clicamos com o botão direito do mouse para importar o certificado.
Política configurada.
Agora, os PCs clientes confiarão no certificado autoassinado.
Se os problemas de confiança foram resolvidos, passamos diretamente à questão da assinatura.
Passo um. Assinamos o arquivo com confiança.
O certificado está disponível, agora precisamos saber o seu hash. Vamos abri-lo na ferramenta 'Certificados' e copiá-lo na aba 'Detalhes'.
O hash que precisamos.
É melhor já formatá-lo adequadamente — apenas letras maiúsculas e sem espaços, se houver. Isso pode ser feito facilmente no console PowerShell com o comando:
("6B142D74CA7EB9F3D34A2FE16D1B949839DBA8FA").ToUpper().Replace(" ","")
Com o hash no formato correto, podemos assinar o arquivo rdp sem problemas:
rdpsign.exe /sha256 6B142D74CA7EB9F3D34A2FE16D1B949839DBA8FA .contoso.rdp
Onde .contoso.rdp é o caminho absoluto ou relativo para o nosso arquivo.
Depois que o arquivo foi assinado, não será possível alterar parte das configurações através da interface gráfica, como o nome do servidor (de fato, caso contrário, qual é o sentido de assinar?). E se alterarmos as configurações com um editor de texto, a assinatura será inválida.
Agora, ao clicar duas vezes no atalho, a mensagem será diferente:
Nova mensagem. A cor é menos alarmante, já é um progresso.
Vamos nos livrar disso também.
Passo dois. Novamente questões de confiança.
Para nos livrarmos dessa mensagem, precisaremos novamente de uma política de grupo. Desta vez, o caminho é: Configuração do Computador — Políticas — Modelos Administrativos — Componentes do Windows — Serviços de Área de Trabalho Remota — Cliente de Conexão de Área de Trabalho Remota — Especificar hashes SHA1 de certificados representando editores confiáveis do RDP.
A política que precisamos.
Na política, basta adicionar o hash que já conhecemos do passo anterior.
Vale notar que essa política sobrepõe a política 'Permitir arquivos RDP de editores confiáveis e parâmetros de RDP definidos por padrão'.
Política configurada.
Voilá, agora não há perguntas estranhas — apenas um pedido de login e senha. Hmm...
Passo três. Acesso transparente ao servidor.
De fato, se já nos autenticamos ao entrar em um computador do domínio, por que inserir novamente o mesmo login e senha? Vamos transmitir as credenciais ao servidor de forma 'transparente'. No caso do RDP simples (sem usar RDS Gateway), a política de grupo nos ajudará...
Vamos para a seção: Configuração do Computador — Políticas — Modelos Administrativos — Sistema — Transmissão de Credenciais — Permitir transmissão de credenciais padrão.
Aqui é possível adicionar os servidores necessários à lista ou usar um wildcard. Isso ficará assim: TERMSRV/trm.contoso.com ou TERMSRV/*.contoso.com.
Política configurada.
Agora, se olharmos para o nosso atalho, ele ficará mais ou menos assim:
O nome de usuário não pode ser alterado.
Se estiver usando RDS Gateway, você também precisará permitir a transmissão de dados nele. Para isso, no Gerenciador do IIS, desative a verificação anônima e ative a verificação de identidade do Windows nas 'Métodos de Autenticação'.
IIS configurado.
Não se esqueça de reiniciar os serviços da web ao final com o comando:
iisreset /noforce
Agora tudo está bem, sem perguntas ou solicitações.
Apenas usuários registrados podem participar da pesquisa. , por favor.
Conte-me, você assina os atalhos RDP para seus usuários?
43%Não, eles estão acostumados a clicar em 'OK' nas mensagens sem ler, alguns até marcam sozinhos 'Não perguntar novamente'.28
29.2%Eu coloco o atalho manualmente e faço a primeira entrada no servidor junto com cada usuário.19
6.1%Claro, eu gosto de tudo em ordem.4
21.5%Não uso servidores de terminal.14
65 usuários votaram. 14 usuários se abstiveram.
Fonte: habr.com
