Статья
11/16/2016

Удаленная консоль в System Center 2012 R2

Применимо к: System Center 2012 R2 Virtual Machine Manager

Удаленная консоль — это функция, впервые представленная в System Center 2012 R2. Удаленная консоль обеспечивает клиентам возможность получать доступ к консоли виртуальной машины в сценарии, когда другие средства удаленного доступа (или удаленный рабочий стол) недоступны. Клиенты могут использовать удаленную консоль для получения доступа к виртуальным машинам, когда они размещаются в изолированной сети, ненадежной сети или в Интернете.

Для работы удаленной консоли требуется наличие следующих компонентов.

Microsoft® Hyper-V® Server 2012 R2
System Center 2012 R2 Virtual Machine Manager
System Center 2012 R2 Service Provider Foundation.
Пакет Windows Azure для Windows Server

Примечание
Клиентам требуется клиентский компьютер, поддерживающий протокол удаленного рабочего стола версии 8.1. Например, пользователи, работающие с Windows 8, должны обновить компьютеры до Windows 8.1. Кроме того, клиенты, использующие Windows 7 с пакетом обновления 1 (SP1) должны установить KB2830477.

Клиентам требуется клиентский компьютер, поддерживающий протокол удаленного рабочего стола версии 8.1. Например, пользователи, работающие с Windows 8, должны обновить компьютеры до Windows 8.1. Кроме того, клиенты, использующие Windows 7 с пакетом обновления 1 (SP1) должны установить KB2830477.

В этом выпуске удаленная консоль поддерживает ограниченные функции. Такие функции, как буфер обмена, звук, перенаправление принтера и сопоставление дисков, не поддерживаются. Удаленная консоль функционирует аналогично подключению клавиатуры, видеоустройства и мыши (KVM), используемому физическими компьютерами.

Проверка подлинности пользователя

Hyper-V в Windows Server 2012 R2 поддерживает проверку подлинности на основе сертификатов, которая используется, чтобы гарантировать, что клиенты смогут получить доступ только к тем виртуальным машинам, которые им назначены. Веб-портал Пакет Windows Azure для Windows Server, Service Provider Foundation и Virtual Machine Manager (VMM) проверяют подлинность и авторизуют доступ к виртуальным машинам, а также предоставляют маркеры, которые узел Hyper-V использует для предоставления доступа к отдельной виртуальной машине.

На следующей диаграмме представлены компоненты, необходимые для доступа удаленной консоли, когда клиенты получают доступ к виртуальной машине через ненадежную сеть, такую как Интернет. Шлюз удаленных рабочих столов пропускается, если эта среда развернута в корпоративной сети.

Проверка подлинности удаленной консоли на основе сертификата

Открытые и закрытые ключи для сертификата используются для установления отношений доверия. В следующих разделах описываются процедуры создания необходимых сертификатов.

Создание сертификата для удаленного доступа

Сертификат используется для создания отношений доверия между сервером шлюза удаленных рабочих столов, узлами Hyper-V и VMM. Этот сертификат позволяет шлюзу удаленных рабочих столов и узлам Hyper-V принимать маркеры утверждений, выпущенные этим шлюзом VMM. Можно использовать одинаковые или разные сертификаты для проверки на шлюзе удаленных рабочих столов и на узлах Hyper-V. Действительные сертификаты должны отвечать следующим требованиям.

Сертификат не должен быть просрочен.
Поле "Использование ключа" должно содержать цифровую подпись.
Поле "Расширенное использование ключа" должно содержать следующий идентификатор объекта проверки подлинности клиента: (1.3.6.1.5.5.7.3.2)
Корневые сертификаты для центра сертификации (ЦС), выпустившего сертификат, должны быть установлены в хранилище сертификатов доверенных корневых центров сертификации.
Поставщик служб шифрования для сертификата должен поддерживать SHA256.

Примечание
Действительный сертификат можно получить из коммерческого центра сертификации или корпоративного центра сертификации. Кроме того, можно использовать самозаверяющий сертификат. При использовании самозаверяющего сертификата необходимо поместить открытый ключ сертификата в хранилище сертификатов доверенных корневых центров сертификации в шлюзе удаленных рабочих столов и на узлах Hyper-V.

Действительный сертификат можно получить из коммерческого центра сертификации или корпоративного центра сертификации. Кроме того, можно использовать самозаверяющий сертификат. При использовании самозаверяющего сертификата необходимо поместить открытый ключ сертификата в хранилище сертификатов доверенных корневых центров сертификации в шлюзе удаленных рабочих столов и на узлах Hyper-V.

Использование средства MakeCert для создания тестового сертификата

В целях тестирования можно использовать средство MakeCert для создания самозаверяющего сертификата. MakeCert входит в состав набора SDK Windows.

Чтобы загрузить набор SDK, перейдите на веб-страницу Пакет SDK Windows для Windows 7.
Дополнительные сведения см. в разделе MakeCert в Центре разработчиков Windows.

Ниже приведен пример кода для создания самозаверяющего сертификата.

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"

где:

-sky signature используется для подписывания

-r создает самозаверяющий сертификат

-n "CN=Remote Console Connect" имя субъекта (подключение удаленной консоли)

-pe закрытый ключ поддерживает экспорт

-a sha256 алгоритм

-len 2048 длина ключа

-e <дд/мм/гггг> дата окончания срока действия

-eku 1.3.6.1.5.5.7.3.2 расширенное использование ключа (идентификатор объекта проверки подлинности клиента)

-ss My закрытый ключ хранится в хранилище сертификатов My

-sy 24 тип поставщика служб шифрования (поддерживает SHA256)

Использование центра сертификации

Когда вы запрашиваете сертификат из центра сертификации, INF-файл шаблона сертификации, подобный следующему, можно использовать со средством Certreq. Дополнительные сведения см. в статье Certreq.

[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

Проверить, соответствует ли сертификат в PFX-файле требованиям к алгоритму и расширенному использованию ключа, можно, выполнив следующий сценарий 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"  
}

Установка сертификата

Созданный сертификат необходимо установить и настроить Virtual Machine Manager для использования сертификата для выдачи маркеров утверждений. Затем закрытый ключ сертификата необходимо импортировать в базу данных Virtual Machine Manager. Для этого можно использовать командлет Windows PowerShell Set-SCVMMServer, например:

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

В этом примере один и тот же сертификат выпускается для шлюза удаленных рабочих столов и для узлов Hyper-V. Время существования маркеров составляет две минуты. Можно выбрать время существования маркеров — от 1 до 60 минут.

Идентификация сервера узлов выполняется по его полному доменному имени (FQDN). Дополнительно, узлы можно идентифицировать по адресу IPv4, IPv6 и имени узла. Удостоверение узла включается в файл удаленного рабочего стола (RDP-файл), который отправляется клиентам.

Примечание
`VMMServer01.Contoso.com` используется в качестве примера имени сервера узла. Замените его на имя вашего сервера.

‎%%78%%% ‎

При обновлении каждого узла в Virtual Machine Manager сертификат устанавливается в личное хранилище сертификатов узла Hyper-V. Для узла Hyper-V настраивается проверка маркеров с помощью сертификата. Следующую команду Windows PowerShell можно использовать для принудительного обновления всех узлов Hyper-V:

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

Узлы Hyper-V

При проверке подлинности маркеров Hyper-V принимает только те маркеры, которые подписаны с использованием определенных сертификатов и алгоритмов хэширования. Virtual Machine Manager выполняет необходимую настройку для узлов Hyper-V. Только узлы Hyper-V в Windows Server 2012 R2 поддерживают функцию удаленной консоли.

При использовании самозаверяющего сертификата необходимо импортировать открытый ключ сертификата в хранилище сертификатов доверенных корневых центров сертификации для узла Hyper-V. Следующий пример сценария демонстрирует использование Windows PowerShell для импорта открытого ключа:

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

Если вы устанавливаете сертификат после настройки Virtual Machine Manager, необходимо перезагрузить службу управления виртуальными машинами Hyper-V.

Проверить, правильно ли настроен узел Hyper-V для удаленной консоли можно следующим образом.

Убедитесь, что сертификат находится в личном хранилище сертификатов узла Hyper-V и является доверенным.
Проверьте конфигурацию хэша для сертификата надежного поставщика.

Следующий пример сценария демонстрирует использование Windows PowerShell для проверки установки сертификата в личном хранилище сертификатов узла Hyper-V.

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

Следующий пример сценария демонстрирует использование Windows PowerShell для проверки конфигурации хэша для сертификата надежного поставщика:

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

Массив TrustedIssuerCertificateHashes должен содержать отпечаток сертификата, который используется для подключения удаленной консоли. Массив AllowedHashAlgorithms должен быть пустым или содержать алгоритм SHA256. Если оставить массив пустым, будет использоваться алгоритм по умолчанию — SHA256 и SHA512.

Примечание
Virtual Machine Manager создает маркеры SHA256.

Шлюз удаленных рабочих столов

Шлюз удаленных рабочих столов можно использовать только для получения доступа консоли к виртуальным машинам. При настройке шлюза удаленных рабочих столов происходит изменение в конфигурации, которое делает его непригодным для других целей. При настройке шлюза удаленных рабочих столов выполняются следующие задачи:

развертывание шлюза удаленных рабочих столов и установка подключаемого модуля проверки подлинности;
установка сертификата;
настройка сертификатов надежного поставщика (с помощью инструментария WMI);
создание сертификата для шлюза удаленных рабочих столов.

Для поддержки федеративной проверки подлинности необходимо установить шлюз подключения консоли Microsoft System Center Virtual Machine Manager на сервер шлюза удаленных рабочих столов. Начните с создания виртуальной машины, а затем включите службы удаленного рабочего стола.

Затем установите компонент "Шлюз подключения консоли System Center Virtual Machine Manager". Двоичные файлы установки для этого компонента можно найти в следующей папке установочного носителя Virtual Machine Manager: CDLayout.EVAL\amd64\Setup\msi\RDGatewayFedAuth. Для конфигураций высокой надежности установите несколько экземпляров шлюза удаленных рабочих столов с компонентом "Шлюз подключения консоли" за подсистемой балансировки нагрузки.

Затем импортируйте открытый ключ сертификата в личное хранилище сертификатов на каждом сервере шлюза удаленных рабочих столов. Это можно сделать, используя Windows PowerShell, как показано в следующем примере:

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

При использовании самозаверяющего сертификата необходимо импортировать открытый ключ сертификата в хранилище сертификатов доверенных корневых центров сертификации для учетной записи машины. Это можно сделать, используя Windows PowerShell, как показано в следующем примере:

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

При проверке подлинности маркеров шлюз удаленных рабочих столов принимает только те маркеры, которые подписаны с использованием определенных сертификатов и алгоритмов хэширования. Эта настройка выполняется путем задания свойств TrustedIssuerCertificateHashes и AllowedHashAlgorithms в классе FedAuthSettings инструментария WMI. Для настройки этих свойств необходимы права администратора.

Свойство TrustedIssuerCertificateHashes представляет собой массив отпечатков сертификата, хранимых на сервере шлюза удаленных рабочих столов. Для задания свойства TrustedIssuerCertificateHashes можно использовать следующую команду Windows PowerShell:

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

Последним этапом является выбор или создание самозаверяющего сертификата для шлюза удаленных рабочих столов. Для этого откройте диспетчер шлюзов удаленных рабочих столов, щелкните шлюз удаленных рабочих столов правой кнопкой мыши и выберите пункт Свойства. В диалоговом окне Свойства перейдите на вкладку SSL-сертификат.

Этот сертификат используется клиентскими компьютерами клиента для проверки удостоверения сервера шлюза удаленных рабочих столов. CN-имя для сертификата должно совпадать с полным доменным именем сервера шлюза удаленных рабочих столов. Откройте диспетчер шлюзов удаленных рабочих столов и назначьте или создайте самозаверяющий сертификат.

Используйте самозаверяющий сертификат только для тестирования. Самозаверяющий сертификат ни в коем случае нельзя использовать в рабочем развертывании. Использование самозаверяющего сертификата также требует, чтобы сертификат был установлен на каждом компьютере клиента, который подключается через шлюз удаленных рабочих столов.

Проверить конфигурацию шлюза удаленных рабочих столов можно следующим образом.

Убедитесь, что для шлюза удаленных рабочих столов настроено использование шлюза подключения консоли для проверки подлинности и авторизации. Это можно сделать, используя Windows PowerShell, как показано в следующем примере:
```
PS C:\> Get-WmiObject -Namespace root\CIMV2\TerminalServices -Class Win32_TSGatewayServerSettings  
```
Убедитесь, что для свойств AuthenticationPlugin и AuthorizationPlugin задано значение FedAuthorizationPlugin.
Убедитесь, что сертификат установлен в личном хранилище сертификатов для учетной записи виртуальной машины. Это можно сделать, используя Windows PowerShell, как показано в следующем примере:
```
PS C:\> dir cert:\localmachine\My\ | Where-Object { $_.subject -eq "CN=Remote Console Connect" }  
```
Проверьте конфигурацию шлюза подключения консоли. Это можно сделать, используя Windows PowerShell, как показано в следующем примере:
```
PS C:\> Get-WmiObject -computername $Server -NameSpace "root\TSGatewayFedAuth2" -Class "FedAuthSettings"  
```
Массив TrustedIssuerCertificates должен содержать отпечаток сертификата для шлюза подключения к консоли.

Пакет Windows Azure Pack для Windows Server для удаленной консоли

Можно включить доступ к удаленной консоли на основе планов, используя службу облаков виртуальных машин в пакете Windows Azure для Windows Server. В панели мониторинга плана выберите в разделе служб плана службу Virtual Machine Clouds (Облака виртуальной машины), а затем в разделе дополнительных параметров — Connect to the console of virtual machines (Подключение к консоли виртуальных машин).

Если установлен шлюз удаленных рабочих столов, ознакомьтесь с процедурой Настройка Windows Azure Pack для использования шлюза удаленных рабочих столов.

Рекомендации по безопасности

С целью повышения безопасности рекомендуется выполнить следующие задачи.

Имя	Угроза	Рекомендация
Маркер доступа	Доступ к хранилищу сертификатов My можно использовать для создания маркеров доступа для любой виртуальной машины.	Используйте группы безопасности Active Directory для ограничения доступа к серверу Virtual Machine Manager, создающему маркеры.
Время существования маркера	Файл удаленного рабочего стола (RDP-файл) содержит маркер EndpointFedAuth. Владение RDP-файлом обеспечивает доступ к консоли конкретной виртуальной машины.	Настройте короткий срок действия для маркера. Рекомендуемое время истечения срока действия — одна минута. Для установки времени существования маркера используйте командлет Windows PowerShell SetSCVMMServer.
Общий доступ	При запросе и получении доступа к сеансу консоли другого пользователя происходит завершение текущего сеанса. Это также относится к узлу, который получает доступ к консоли пользователя, выполнившего вход в систему, а затем — к ресурсам клиента. Сеансы консоли похожи на KVM-сеансы для физических узлов. Сеанс виртуальной машины доступен для всех пользователей, которым в политике авторизации предоставлены права на выполнения операций чтения консоли и чтения/записи консоли. По умолчанию эти права предоставлены любому администратору.	Пользователи клиента: если не работают активно, выполняется выход из сеанса консоли. Убедитесь, что операционная система заблокирована после краткого периода неактивности. Поставщики услуг размещения. Используйте политики авторизации, чтобы ограничить доступ для чтения и записи.
Пользователи-злоумышленники	Пользователи-злоумышленники могут пытаться подключиться к портам с помощью шлюза удаленных рабочих столов, если они не авторизованы в системе. Например, пользователь-злоумышленник может попытаться подключиться к RDP-порту на узле Hyper-V для перебора сочетаний имени пользователя и пароля.	Настройте политики авторизации ресурсов удаленных рабочих столов на сервере шлюза удаленных рабочих столов, чтобы заблокировать непосредственное подключение пользователей к порту 3389 на сервере Hyper-V. Подключения должны проходить только через порт 2179. Дополнительные сведения см. в разделе Управление политиками выделения ресурсов удаленных рабочих столов.
Атака "злоумышленник в середине"	Одна из проблем безопасности, для решения которой был создан Hyper-V, заключается в более эффективной защите от атак "злоумышленник в середине" (которые также называются MITM). Использование доверенных сертификатов для определения узла Hyper-V помогает защититься от атак MITM. В Hyper-V используется прослушиватель отдельного порта, который проводит проверку подлинности серверов с помощью доверенных сертификатов. При определенных обстоятельствах Hyper-V выдает самозаверяющий сертификат, который впоследствии используется для проверки подлинности серверов. В качестве альтернативного варианта этого подхода можно настроить Hyper-V для использования другого сертификата, например сертификата, выданного центром сертификации (ЦС).	Используйте сертификат узла Hyper-V с действительной цепочкой сертификатов, связанной с доверенным корневым сертификатом. Это предотвращает отображение сообщения об ошибке, информирующего о невозможности проверки удостоверения удаленного компьютера. Дополнительные сведения см. в разделе Настройка сертификатов для подключения виртуальной машины.
Отслеживание сеансов	Когда подключение к консоли активно, персонал узла может создать моментальный снимок виртуальной машины и экспортировать ее на другой сервер или получить эскизы консоли.	Используйте политики авторизации, чтобы ограничить доступ для чтения и записи. Раскройте клиентам сведения о ситуациях, в которых персонал может получить доступ к сеансам консоли.
Сетевая конфигурация	Пользователь-злоумышленник может использовать свойства в RDP-файле для получения расширенного представления о конфигурации сети.	Определите, следует ли использовать имя узла или IP-адрес для подключения к серверу под управлением Hyper-V. Указанная информация входит в RDP-файл, который отправляется пользователю службы. Она также содержится в сертификате, который представляет сервер под управлением Hyper-V при установке подключения к консоли. Настройте подключение к сети, чтобы ограничить непосредственный доступ к серверам под управлением Hyper-V из Интернета или с виртуальной машины пользователя. IP-адрес (в частности, IPv6-адрес) сокращает объем раскрываемых сведений.

См. также

Настройка Windows Azure Pack для использования шлюза удаленных рабочих столов

Поделиться через