Share via


Consola Remota no System Center 2012 R2

 

Publicado: março de 2016

Aplica-se A: System Center 2012 R2 Virtual Machine Manager

A Consola Remota é uma funcionalidade que foi introduzida no System Center 2012 R2. A Consola Remota dá aos inquilinos a capacidade de aceder à consola das suas máquinas virtuais em cenários onde outras ferramentas remotas (ou o Ambiente de Trabalho Remoto) não estão disponíveis. Os inquilinos podem utilizar a consola remota para aceder a máquinas virtuais, quando a máquina virtual está numa rede isolada, numa rede não fidedigna ou na Internet.

A Consola Remota precisa do seguinte para ser executada:

  • Microsoft® Hyper-V® Server 2012 R2

  • System Center 2012 R2 Virtual Machine Manager

  • System Center 2012 R2 Service Provider Foundation

  • Windows Azure Pack for Windows Server

Nota

Os inquilinos necessitam de um computador cliente que suporte o Protocolo de Ambiente de Trabalho Remoto 8.1. Por exemplo, os utilizadores que tenham o Windows 8 têm de atualizar para o Windows 8,1. Além disso, os clientes que utilizem o Windows 7 SP1 têm de instalar a atualização KB2830477.

Nesta versão, a Consola Remota suporta uma funcionalidade limitada. As funcionalidades como a área de transferência, o som, o redirecionamento de impressoras e mapeamento de unidade não são suportadas. A Consola Remota funciona de uma forma semelhante à ligação do teclado, vídeo e rato (KVM) que é utilizada por computadores físicos.

Autenticação de utilizador

O Hyper-V no Windows Server 2012 R2 suporta a autenticação com base em certificados, que é utilizada para garantir que os inquilinos acedem apenas às máquinas virtuais que lhes foram atribuídas. O portal Web Windows Azure Pack for Windows Server, Service Provider Foundation e o Virtual Machine Manager (VMM) autenticam e autorizam o acesso a máquinas virtuais e fornecem um token que o anfitrião Hyper-V utiliza para conceder acesso a uma única máquina virtual.

O diagrama seguinte ilustra os componentes que são necessários para acesso à Consola Remota quando os inquilinos estão a aceder a uma máquina virtual numa rede não fidedigna, como a Internet. O Gateway do Ambiente de Trabalho Remoto (Gateway de RD) é omitido se este ambiente for implementado num ambiente empresarial.

Autenticação baseada no Certificado de Consola Remota

As chaves privadas e públicas para um certificado são utilizadas para estabelecer uma relação de fidedignidade. As secções seguintes descrevem como criar os certificados necessários.

Criar um certificado para acesso remoto

Um certificado é utilizado para criar uma relação de fidedignidade entre o servidor de Gateway de RD, os anfitriões de Hyper-V, e o VMM. O certificado permite aos anfitriões do Gateway de RD e Hyper-V aceitar tokens de afirmação emitidos pelo Gateway de VMMRD. É possível utilizar os mesmos certificados ou certificados diferentes para a validação no Gateway de RD e nos anfitriões Hyper-V. Os certificados válidos devem satisfazer os seguintes requisitos:

  1. O certificado não deve estar expirado.

  2. O campo Utilização de Chaves tem de conter uma assinatura digital.

  3. O campo Utilização Avançada de Chaves tem de conter o seguinte identificador de objeto de Autenticação de Cliente:

  4. Os certificados de raiz da autoridade de certificação (CA) que emitiram o certificado devem ser instalados no arquivo Autoridades de Certificação de Raiz Fidedignas.

  5. O fornecedor de serviços criptográficos para o certificado tem de suportar SHA256.

Pode obter um certificado válido de uma Autoridade de Certificação Comercial, uma Autoridade de Certificação Empresarial ou utilizando um certificado autoassinado.

Nota

Pode obter um certificado válido de uma autoridade de certificação comercial, uma autoridade de certificação empresarial ou utilizando um certificado autoassinado. Quando utiliza um certificado autoassinado, tem de colocar a chave pública do certificado no arquivo das Autoridades de Certificação de Raiz Fidedignas nos anfitriões Gateway de RD e Hyper-V.

Utilizar a ferramenta MakeCert para criar um certificado de teste

Para fins de teste, pode utilizar a ferramenta MakeCert para criar um certificado autoassinado. MakeCert faz parte do Windows SDK.

O código seguinte é um exemplo de como criar um certificado autoassinado:

makecert -n "CN=Remote Console Connect" -r -pe -a sha256 -e <mm/dd/yyyy> -len 2048 -sky signature -eku 1.3.6.1.5.5.7.3.2 -ss My -sy 24 "<CertificateName>.cer"

no caso de:

assinatura -sky

Utilização para assinar

-r

Criar certificado autoassinado

-n "CN=Ligação à consola remota"

Nome do requerente (ligar a consola remota)

-pe

Chave privada é exportável

-a sha256

algoritmo

-len 2048

Comprimento da chave

-e

Utilizar uma autoridade de certificação

Quando requisita um certificado a uma autoridade de certificação, um ficheiro de modelo de certificado .inf semelhante ao seguinte pode ser utilizado com a ferramenta Certreq. Para obter mais informações, consulteCertreq.

[Version]
Signature="$Windows NT$"
[NewRequest]
; Change to your,country code, company name and common name
Subject = "C=US, O=Contoso, CN=wap-rdg.contoso.com"
; Indicates both encryption and signing
KeySpec = 1 
; Length of the public and private key, use 2048 or higher
KeyLength = 2048
; Certificate will be put into the local computer store
MachineKeySet = TRUE 
PrivateKeyArchive = FALSE
RequestType = PKCS10
UserProtected = FALSE
; Allow the key to be shared between multiple computers
Exportable = TRUE
SMIME = False
UseExistingKeySet = FALSE 
; ProviderName and ProviderType must be for a CSP that supports SHA256
ProviderName = "Microsoft Enhanced RSA and AES Cryptographic Provider"
ProviderType = 24
; KeyUsage must include DigitalSignature. 0xA0 also includes Key Encipherment
KeyUsage = 0xa0
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.2

Pode validar que um certificado num ficheiro .pfx cumpre requisitos de algoritmo e de utilização avançada de chaves executando o seguinte script do Windows PowerShell:

$cert = Get-PfxCertificate <cert.pfx>
if ($cert.PrivateKey.CspKeyContainerInfo.ProviderName -ne "Microsoft Enhanced RSA and AES Cryptographic Provider")
{
       Write-Warning "CSP may not support SHA256"
}
if (! (Test-Certificate $cert -EKU "1.3.6.1.5.5.7.3.2") )
{
       Write-Warning "Certificate is not valid"
} 

Instalar o certificado

Quando o certificado tiver sido criado, tem de instalá-lo e configurar o Virtual Machine Manager para que utilize o certificado para emitir tokens de afirmação A chave privada do certificado é então importada para a base de dados do Virtual Machine Manager. Para tal, utilize o cmdlets do Windows PowerShell Set-SCVMMServer, por exemplo:

PS C:\> $mypwd = ConvertTo-SecureString "password" -AsPlainText -Force
PS C:\> $cert = Get-ChildItem .\RemoteConsoleConnect.pfx 
PS C:\> $VMMServer = VMMServer01.Contoso.com
PS C:\> Set-SCVMMServer -VMConnectGatewayCertificatePassword $mypwd -VMConnectGatewayCertificatePath $cert -VMConnectHostIdentificationMode FQDN -VMConnectHyperVCertificatePassword $mypwd -VMConnectHyperVCertificatePath $cert -VMConnectTimeToLiveInMinutes 2 -VMMServer $VMMServer

Neste exemplo, o mesmo certificado é utilizado para o Gateway de RD e para os anfitriões Hyper-V, e os tokens têm uma duração de dois minutos. Pode selecionar uma duração para os tokens de 1 a 60 minutos.

O servidor anfitrião pode ser identificado pelo Nome de Domínio Completamente Qualificado (FQDN). Em alternativa, os anfitriões podem ser identificados pelo endereço IPv4, o endereço IPv6 e o nome de anfitrião. A identidade do anfitrião está incluída no ficheiro do protocolo RDP (Remote Desktop Protocol) que é enviado aos inquilinos.

Nota

VMMServer01.Contoso.com é utilizado como nome do servidor anfitrião de exemplo. Altere-o para o nome do seu servidor real.

RemoteConsoleConnect.pfx é utilizado para importar o ficheiro PFX no qual estão armazenadas as chaves dos certificados para a base de dados do VMM.

Quando cada anfitrião é atualizado no Virtual Machine Manager, este instala o certificado no arquivo de certificados Pessoais do anfitrião Hyper-V e configura o anfitrião Hyper-V de forma a validar os tokens utilizando o certificado. Pode utilizar o seguinte comando do Windows PowerShell para forçar uma atualização de todos os anfitriões Hyper-V:

PS C:\> Get-SCVMHost -VMMServer "VMMServer01.Contoso.com" | Read-SCVMHost

Anfitriões Hyper-V

Quando está a autenticar os tokens, o Hyper-V só aceita tokens que são assinados com certificados específicos e algoritmos hash. O Virtual Machine Manager efetua a configuração necessária aos anfitriões de Hyper-V. Apenas o Hyper-V no Windows Server 2012 R2 suporta a funcionalidade de Consola Remota.

Quando utiliza um certificado autoassinado, tem de importar a chave pública do certificado para o arquivo de certificados das Autoridades de Certificação de Raiz Fidedigna para o anfitrião Hyper-V. O script seguinte fornece um exemplo de como utilizar o Windows PowerShell para importar a chave pública:

PS C:\> Import-Certificate -CertStoreLocation cert:\LocalMachine\Root -Filepath "<certificate path>.cer"

Tem de reiniciar o serviço de gestão de Máquina Virtual Hyper-V se instalar um certificado depois de configurar o Virtual Machine Manager.

Pode verificar se o anfitrião de Hyper-V está corretamente configurado para a Consola Remota do seguinte modo:

  1. Verifique se o certificado está no arquivo de certificados Pessoais do anfitrião Hyper-V e se é fidedigno.

  2. Verifique se a configuração hash do certificado de emissor fidedigno.

O script que se segue fornece um exemplo de como utilizar o Windows PowerShell para verificar se o certificado está instalado no arquivo de certificados Pessoais do anfitrião Hyper-V:

PS C:\> dir cert:\localmachine\My\ | Where-Object { $_.subject -eq "CN=Remote Console Connect" }

O script seguinte fornece um exemplo de como utilizar o Windows PowerShell para verificar a configuração hash do certificado de emissor fidedigno:

PS C:\> $TSData = Get-WmiObject -computername $Server -NameSpace "root\virtualization\v2" -Class "Msvm_TerminalServiceSettingData"

A matriz TrustedIssuerCertificateHashes tem de conter o thumbprint do certificado que é utilizado para ligar a consola remota. A matriz AllowedHashAlgorithms tem de estar vazia ou conter o algoritmo SHA256. Quando a matriz está vazia, assume como predefinição SHA256 ou SHA512.

Nota

O Virtual Machine Manager gera tokens SHA256.

Gateway de Ambiente de Trabalho Remoto

O Gateway de Ambiente de Trabalho Remoto (Gateway de RD) só pode ser utilizado para acesso à consola das máquinas virtuais. Quando configurar o Gateway de RD, ocorre uma alteração da configuração, que faz com que o gateway fique inutilizável para outros fins. As tarefas seguintes são concluídas quando configurar o Gateway de RD:

  1. Implementar o Gateway de RD e instalar a extensão de autenticação.

  2. Instale o certificado.

  3. Configure certificados de emissor fidedigno (utilizando o WMI).

  4. Crie um certificado para o Gateway de RD.

Para suportar a autenticação federada, é necessário instalar o Gateway da Consola do Virtual Machine Manager do Microsoft System Center no servidor de Gateway de RD. Comece por criar uma máquina virtual, em seguida, ative os Serviços de Ambiente de Trabalho Remoto.

Em seguida, instale o componente do Gateway da Consola do Virtual Machine Manager do Microsoft System Center. Encontrará os binários de instalação para este componente na seguinte pasta de suporte de dados de instalação do Virtual Machine Manager: CDLayout.EVAL\amd64\Setup\msi\RDGatewayFedAuth. Para uma configuração de elevada disponibilidade, instale várias quantidades de Gateway de RD com o componente do Gateway de Ligação da Consola por trás de um balanceador de carga.

Em seguida, importe a chave pública do certificado para arquivo de certificados pessoais em cada servidor de Gateway de RD. Pode consegui-lo utilizando o Windows PowerShell, tal como apresentado no exemplo seguinte:

PS C:\> Import-Certificate -CertStoreLocation cert:\LocalMachine\My -Filepath "<certificate path>.cer"

Se estiver a utilizar um certificado autoassinado, tem de importar a chave pública do certificado para o arquivo das Autoridades de Certificação de Raiz Fidedignas nas conta da máquina. Pode consegui-lo utilizando o Windows PowerShell, tal como apresentado no exemplo seguinte:

PS C:\> Import-Certificate -CertStoreLocation cert:\LocalMachine\Root -Filepath "<certificate path>.cer"

Quando está a autenticar os tokens, o Gateway de RD só aceita tokens que são assinados com certificados específicos e algoritmos hash. Esta configuração é realizada definindo as propriedades TrustedIssuerCertificateHashes e AllowedHashAlgorithms na classe FedAuthSettings de WMI. Tem de ter credenciais administrativas para definir estas propriedades.

A propriedade TrustedIssuerCertificateHashes é uma matriz de thumbprints de certificado que estão armazenadas no servidor de Gateway de RD. Pode utilizar o seguinte comando do Windows PowerShell para definir a propriedade TrustedIssuerCertificateHashes:

$Server = "rdgw.contoso.com"
$Thumbprint = "95442A6B58EB5E443313C1B4AFD2665991D354CA"
$TSData = Get-WmiObject -computername $Server -NameSpace "root\TSGatewayFedAuth2" -Class "FedAuthSettings"
$TSData.TrustedIssuerCertificates = $Thumbprint
$TSData.Put()

O último passo consiste em selecionar ou criar um certificado autoassinado para o Gateway de RD. Para tal, abra o Gestor de Gateway de RD, clique com o botão direito em Gateway de Ambiente de trabalho remoto e clique em Propriedades. Na caixa de diálogo Propriedades, clique no separador Certificado SSL.

Este certificado é utilizado por computadores de inquilino para verificar a identidade do servidor Gateway de RD. O nome de NC para o certificado deve corresponder ao FQDN do servidor de Gateway de RD. Abra o Gestor de Gateway de RD e atribua ou crie um certificado autoassinado.

Nota

Utilize um certificado autoassinado apenas para testes. Um certificado autoassinado nunca deve ser utilizado numa implementação de produção. A utilização de um certificado autoassinado também requer que o certificado esteja instalado em todos os computadores de inquilino que se liguem através do Gateway de RD.

Pode verificar a configuração do Gateway de RD, efetuando os seguintes passos:

  1. Certifique-se de que o Gateway de RD está configurado para utilizar o Gateway de Ligação de Consola para autenticação e autorização. Pode consegui-lo utilizando o Windows PowerShell, tal como apresentado no exemplo seguinte:

    PS C:\> Get-WmiObject -Namespace root\CIMV2\TerminalServices -Class Win32_TSGatewayServerSettings
    

    Verifique se as propriedades AuthenticationPlugin e AuthorizationPlugin estão definidas para FedAuthorizationPlugin.

  2. Certifique-se de que foi instalado um certificado no arquivo de certificados pessoais para a conta da máquina. Pode consegui-lo utilizando o Windows PowerShell, tal como apresentado no exemplo seguinte:

    PS C:\> dir cert:\localmachine\My\ | Where-Object { $_.subject -eq "CN=Remote Console Connect" }
    
  3. Verifique a configuração do Gateway de Ligação da Consola. Pode consegui-lo utilizando o Windows PowerShell, tal como apresentado no exemplo seguinte:

    PS C:\> Get-WmiObject -computername $Server -NameSpace "root\TSGatewayFedAuth2" -Class "FedAuthSettings"
    

    A matriz TrustedIssuerCertificates tem de conter o thumbprint do certificado do Gateway de Ligação da Consola.

Microsoft Azure Pack para Windows Server para Consola Remota

Pode ativar o acesso à consola remota numa base por plano através do serviço de Nuvens de Máquina Virtual no Windows Azure Pack para Windows Server. No painel de controlo do plano, selecione Nuvens de Máquina Virtual nos serviços de plano e selecione Ligar à consola das máquinas virtuais nas definições adicionais.

Se tiver instalado um Gateway de Ambiente de Trabalho Remoto, leia o procedimento Como Configurar o Microsoft Azure Pack para utilizar o Gateway de Ambiente de Trabalho Remoto.

Recomendações de segurança

Recomendamos que efetue as seguintes tarefas para melhorar a segurança:

Nome

Ameaça

Recomendação

Acesso de token

O acesso ao Meu arquivo de certificados pode ser utilizado para gerar tokens de acesso a qualquer máquina virtual.

Utilize os grupos de segurança do Active Directory para restringir o acesso à criação de tokens do Virtual Machine Manager.

Duração do token

O ficheiro RDP (Remote Desktop Protocol) contém o token EndpointFedAuth e a posse do ficheiro RDP permite o acesso à consola de uma máquina virtual específica.

Configure um tempo de expiração curto para o token. Um minuto é o tempo de expiração recomendado. Utilize o cmdlets do Windows PowerShell SetSCVMMServer para definir a duração do token.

Acesso partilhado

Outro utilizador solicita e acede a sessão de consola, que termina a sessão existente. Isto inclui um anfitrião que acede à consola de um utilizador que tem sessão iniciada e que obtém acesso aos recursos dos inquilinos.

As sessões de consola são semelhantes às sessões do KVM para anfitriões físicos. Uma sessão de máquina virtual está disponível a todos os utilizadores que tenham obtido o privilégio de operações de Leitura da Consola ou de Leitura/Escrita da Consola na política de autorização. Por predefinição, este privilégio é concedido a qualquer Administrador.

Utilizadores inquilinos:

Não permaneça com a sessão iniciada numa sessão de consola quando não estiver a trabalhar.

Garanta que o sistema operativo bloqueia após um curto período de inatividade.

Fornecedores de serviços de alojamento:

Utilize políticas de autorização para restringir o acesso de escrita e leitura.

Utilizadores mal intencionados

Os utilizadores mal intencionados podem tentar ligar a portas através do Gateway de RD quando não são autorizados. Por exemplo, um utilizador mal intencionado poderá tentar ligar à porta RDP num anfitrião Hyper-V para experimentar combinações de nome e palavra-passe do utilizador.

Configure as políticas de autorização de recursos de ambiente de trabalho remoto no servidor de Gateway de RD para impedir que os utilizadores liguem diretamente à porta 3389 no servidor Hyper-V. As ligações só são necessárias na porta 2179. Para obter mais informações, consulte Gerir Políticas de Atribuição de Recursos do Ambiente de Trabalho Remoto.

Ataque man-in–the-middle

Um dos problemas de segurança que o Hyper-V foi concebido para solucionar é uma melhor melhor proteção contra ataques "man-in-the-middle" (também referidos como MITM). A utilização de certificados fidedignos para identificar o anfitrião Hyper-V pode ajudar a proteger contra ataques MITM. O Hyper-V utiliza uma escuta de porta única que utiliza certificados fidedignos para autenticação de servidor. Em determinadas circunstâncias, o Hyper-V emite um certificado autoassinado que é, então, utilizado para autenticação de servidor. Como alternativa a esta abordagem, pode configurar o Hyper-V para utilizar um certificado diferente, tal como uma emitido por uma autoridade de certificação (CA).

Utilize um certificado de anfitrião Hyper-V com uma cadeia de certificado válido que esteja ligada a um certificado de raiz fidedigna. Isto impede que uma mensagem de erro que indica que não é possível verificar a identidade do computador remoto. Para obter mais informações, consulte Configurar Certificados para Ligação de Máquinas Virtuais.

Monitorização de sessão

Quando a ligação de uma consola está ativa, é possível que o pessoal do anfitrião tire um instantâneo da máquina virtual e exporte a máquina virtual para outro servidor, ou que recolha imagens em miniatura da consola.

Utilize políticas de autorização para restringir o acesso de escrita e leitura. Divulgue aos inquilinos as situações em que o seu pessoal pode aceder às sessões das consolas.

Configuração de rede

Um utilizador mal intencionado pode utilizar propriedades no ficheiro RDP para obter conhecimentos aprofundados sobre uma configuração de rede.

Determine se o nome do anfitrião ou o endereço IP devem ser utilizados para ligar a um servidor com o Hyper-V. Estas informações estão incluídas no ficheiro RDP que é enviado ao consumidor do serviço. Estão igualmente no certificado que é apresentado pelo servidor com Hyper-V, quando a ligação da consola é iniciada.

Defina a configuração de rede para assegurar que os servidores com Hyper-V não são diretamente acessíveis a partir da Internet ou de uma máquina virtual de um utilizador. Um endereço IP (em especial, um endereço IPv6) reduz a quantidade de informação divulgada.