publicado pela primeira vez no TECHNET em janeiro 24, 2014
Bom Dia AskPerf! Kiran aqui com uma pergunta para você: Por Que precisamos de certificados? Bem, os certificados são usados para assinar a comunicação entre duas máquinas. Quando um cliente se conecta a um servidor, a identidade do servidor que está recebendo a conexão e, por sua vez, as informações do cliente são validadas usando certificados.
isso é feito para evitar possíveis ataques man-in-the-middle. Quando um canal de comunicação é configurado entre o cliente e o servidor, a autoridade que emite/gera o certificado está atestando a autenticidade do servidor.
portanto, desde que o cliente confie no servidor com o qual está se comunicando, os dados enviados de e para o servidor são considerados seguros. Isso me leva à próxima pergunta:
que tipo de certificado é necessário para o RDS?
o seguinte blog contém informações sobre o tipo de certificados e como você pode criá-los usando a CA interna do domínio.
http://blogs.msdn.com/b/rds/archive/2010/04/09/configuring-remote-desktop-certificates.aspx
requisitos básicos para certificados de área de Trabalho Remota:
- o certificado é instalado no armazenamento de certificados “pessoais” do computador.
- o certificado tem uma chave privada correspondente.
- a extensão “Uso de Chave aprimorado “tem um valor de” autenticação de servidor “ou” autenticação de área de Trabalho Remota ” (1.3.6.1.4.1.311.54.1.2). Certificados sem extensão “Uso de Chave aprimorado” também podem ser usados.
como a função que ele executa sugere, precisamos de um certificado de’ autenticação do servidor’. Este certificado pode ser gerado usando o modelo de’ autenticação de Estação de trabalho ‘ (se necessário).
aqui está o processo exato:
- abrir CERTSRV.MSC e configurar certificados.
- Autoridade De Certificação Aberta.
- no painel de detalhes, expanda o nome do computador do instrutor.
- clique com o botão direito em modelos de certificado e selecione Gerenciar. Clique com o botão direito do mouse na autenticação da estação de trabalho e clique em Duplicate Template.
- na guia Geral, altere o nome de Exibição Do modelo para Autenticação cliente-servidor e verifique publicar certificado no Active Directory.
- na guia Extensões, clique em políticas do aplicativo e edite. Clique em Adicionar e selecione Autenticação do servidor. Clique em OK até retornar às propriedades da caixa de diálogo Novo Modelo.
- clique na guia Segurança. Para computadores de domínio, clique na caixa de seleção para ‘permitir Autoenroll’. clicar. Feche o console modelos de certificado.
- no snap-in certsrv, clique com o botão direito em modelos de certificado e selecione Novo Modelo de Certificado a ser emitido.
- Selecione Autenticação cliente-servidor e clique em OK.
isso ficará visível ao visualizar o certificado no snap-in MMC’ certificados’, como abaixo:
quando você abre o certificado, a guia ‘geral’ também conterá a finalidade deste certificado como ‘autenticação do servidor’, conforme visto abaixo:
Outra forma de validar a isso, seria ir para o ‘Detalhes’ seção do certificado e olhar para o ” Uso Avançado de Chave de propriedade:
A maneira mais fácil para obter um certificado, se você controlar as máquinas cliente que irá se conectar, é usar o Active Directory Certificate Services. Você pode solicitar e implantar seus próprios certificados e eles serão confiáveis por todas as máquinas no domínio.
se você permitir que os usuários se conectem externamente e eles não farão parte do seu domínio, você precisará implantar certificados de uma CA pública. Exemplos incluindo, mas não limitado a: GoDaddy, Verisign, Entrust, Thawte, DigiCert
agora que você sabe que tipo de certificado você precisa, vamos falar sobre o conteúdo do certificado.
no Windows 2008/2008 R2, você se conecta ao nome do farm, que, de acordo com o DNS round robin, é direcionado primeiro ao redirecionador, ao lado do Corretor de conexão e, finalmente, ao servidor que hospedará sua sessão.
no Windows 2012, você se conecta ao Corretor de conexão e ele o encaminha para a coleção usando o nome da coleção.
os certificados implantados precisam ter um nome de assunto ou nome alternativo de assunto que corresponda ao nome do servidor ao qual o usuário está se conectando. Portanto, por exemplo, para publicação, o certificado precisa conter os nomes de todos os servidores RDSH na coleção. O certificado para RDWeb precisa conter o FQDN do URL, com base no nome ao qual os usuários se conectam. Se você tiver usuários se conectando externamente, isso precisa ser um nome externo (precisa corresponder ao que eles se conectam). Se você tiver usuários se conectando internamente ao RDweb, o nome precisará corresponder ao nome interno. Para Logon Único, novamente o nome do assunto precisa corresponder aos servidores na coleção.
Para o nosso exemplo, vamos considerar o meu RDS implantação para conter os seguintes máquinas:
RDSH1.RENDER.COM de Anfitrião de Sessões com Aplicativos Remotos configurados
RDSH2.RENDER.COM de Anfitrião de Sessões com Aplicativos Remotos configurados
RDVH1.PROCESSAR.COM o host de Virtualização, com o VDI VMs configurado
RDVH2.RENDER.COM host de Virtualização com VDI VMs configurado
RDCB.RENDER.COM o agente de Conexão
RDWEB.RENDER.COM RDWeb e servidor de Gateway
Quando o meu cliente se conecta internamente, ele irá inserir o FQDN do servidor que hospeda a página da web, eu.e: RDWEB.RENDER.COM.
O nome do certificado deve ser esse nome, a URL que o usuário irá iniciar a conexão. Mas precisamos lembrar que a conexão não termina apenas aqui. A conexão flui do servidor web para um dos hosts de sessão ou hosts de virtualização e também para o corretor de conexão.
o certificado pode ser comum em todos esses servidores. É por isso que recomendamos que o nome alternativo do assunto do certificado contenha os nomes de todos os outros servidores que fazem parte da implantação.
Em resumo, o certificado para o meu ambiente, seria da seguinte forma:
Tipo: Servidor de Autenticação
Nome: RDWEB.RENDER.COM
SAN: RDSH1.RENDER.COM; RDSH2.RENDER.COM; RDVH1.RENDER.COM; RDVH2.PROCESSAR.COM; RDCB.RENDER.COM
isso é tudo que você precisa, desde que você tenha 5 ou menos servidores na implantação. Mas temos um problema quando temos mais servidores na implantação. Isso ocorre porque, por design, o SAN (Nome Alternativo do assunto) em um certificado, só pode conter 5 nomes de servidor. Se você tiver mais deles, terá que obter um certificado curinga emitido para cobrir todos os servidores na implantação. Aqui, meu certificado muda da seguinte forma:
Tipo: autenticação do servidor
nome: RDWEB.RENDER.COM
SAN: *.PROCESSAR.COM
ainda encontramos alguns desafios quando se trata do seguinte cenário. Observe que isso é verdadeiro somente quando você tem usuários externos que acessam a implantação.
nome Externo: RDWEB.RENDER.com
Nome Interno: RDWEB.PROCESSAR.local
aqui, se você receber um certificado com RDWEB.RENDER.COM no nome, os erros do certificado ainda aparecem. Isso ocorre porque o certificado deve validar um servidor com o FQDN: ‘RDWEB.RENDER.COM’. no entanto, seu servidor é ‘RDWEB.PROCESSAR.LOCAL ‘e o’. com ‘para’.local ‘ magia só acontece em seu firewall público / roteador usando encaminhamento de porta (cenário mais comum).
nesses cenários, recomendamos anteriormente que o nome no certificado contenha o nome ‘.com’ e a SAN contenha o ‘.nome local.
recentemente, todos os provedores de certificados públicos estão parando de emitir certificados com’.LOCAL ‘ neles. Começando com o Windows 8 e o Windows Server 2012, não precisamos mais dos nomes externos e internos contidos no certificado.
em cenários onde você tem clientes externos se conectando e você tem um sufixo de domínio interno privado (domínio.LOCAL), você pode obter um certificado de uma CA pública com o externo (RDWEB.DOMAIN.COM) nomeie e vincule-o às funções RD Web Access e RD Gateway, porque essas são as únicas funções expostas à internet. Para RD Connection Broker – Publishing e RD Connection Broker-ativar Logon Único, você pode fazer uso de um certificado interno com o ‘domínio.Nome LOCAL nele. Isso, no entanto, como mencionado anteriormente, só funcionará com clientes que se conectam através do RDC 8.0 ou superior.
o Gateway RD e o cliente de área de Trabalho Remota versão 8.0 (e superior) fornecem aos usuários externos uma conexão segura com a implantação. Uma vez conectado à implantação, o certificado interno com o ‘.o nome local ‘ cuidará da Assinatura Remota de aplicativos (publicação) e do logon único.
agora, vamos ver onde configuramos o certificado que temos:
abra o Gerenciador do servidor no servidor do Connection Broker e clique em Serviços de área de Trabalho Remota no painel mais à esquerda.
uma vez aqui, você verá sua implantação mostrada como na ilustração abaixo. Clique em tarefas e selecione “Editar Propriedades de implantação”
isso abrirá a folha de propriedades da implantação. Selecione a opção certificados no painel esquerdo:
agora, como discutido anteriormente, você pode selecionar o certificado que foi criado usando o botão ‘Selecionar certificado existente’ na parte inferior da tela.
apenas aponte para o’.pfx’ arquivo e permitir que ele importe o certificado para a função.
você pode usar um único certificado para todas as funções, se seus clientes forem internos apenas ao Domínio, gerando um certificado curinga simples (*.PROCESSAR.LOCAL) e vinculá-lo a todos os papéis.
Observe que mesmo se você tiver vários servidores que são parte dessa implantação, o Gerenciador de Servidor de importar o certificado para todos os servidores na implantação, coloque-os na raiz confiáveis de máquinas e ligá-los para as respectivas funções.
-Kiran Kadaba
