Многие компании используют инфраструктуру VDI для организации удаленной работы с неуправляемых компанией персональных станций. При публикации фермы VDI в интренет, внешние пользователи сталкиваются с проблемой недоверия к сертификату, который был выпущен корпоративным центром сертификации. В следствии этого, появляются предупреждения безопасности при установке удаленного подключения.
В данном случае, предупреждение появляется дважды: первый раз не доверенным является Connection Broker сервер, а второй – виртуальная машина фермы VDI.
Многие системные администраторы выходят из данной ситуации либо предлагая пользователям игнорировать данное сообщение установив галку «Больше не спрашивать», либо устанавливают корневой сертификат в доверенные на удаленном компьютере пользователя и публикуют CRL корпоративного CA. Однако данные методы не работают если пользователь подключается каждый раз из разных мест, либо подключается к разным виртуальным машинам.
Для решения поставленной проблемы необходимо использовать «белый» сертификат, выписанный доверенным Certificate Authority для фермы VDI. Имя данного внешнего сертификата и имена компьютеров VDI должны совпадать.
РЕШЕНИЕ ПРОБЛЕМЫ
Для начала нам понадобится wildcard сертификат вида *.yourcompany.com, приобретенный у доверенного центра сертификации.
Добавление нового DNS Суффикса в домене:
В DNS на контроллере домена добавляем новую Active Directory Integrated зону yourcompany.com, которая будет обслуживать внутренние запросы для новых имен серверов и виртуальных машин фермы VDI.
Для поддержания в домене дополнительного доменного суффикса необходимо внести изменения в атрибут msDS-AllowedDNSSuffixes на уровне домена. Необходимо добавить внутреннее и внешнее имена домена как значения атрибута, например, yourcompany.local и yourcompany.com. На уровне домена создаем новую групповую политику для указания DNS суффиксов, которые будут добавляться к коротким именам машин при DNS запросах.
Следующую политику необходимо включить и добавить через запятую значения внутреннего доменного имени и внешнего доменного имени: Computer Configuration \ Policies \ Administrative Templates \ Network \ DNS Client\ DNS suffix search list.
Установка сертификата на RD сервера
Перед созданием VDI фермы необходимо выполнить смену DNS суффикса планируемых RD серверов на имя внешнего домена. Для этого перейдем в свойства компьютера и выберем изменить имя компьютера. В окне изменения имени компьютера необходимо нажать на кнопку More… и задать новый первичный DNS суффикс компьютера — yourcompany.com.
Далее создаем новую ферму VDI, основываясь на выбранных серверах Microsoft Windows Server 2012 R2. Информацию по данной процедуре можно легко найти в сети.
После того, как pfx файл сертификата будет на руках, можно приступить к установке его на новую VDI ферму. На сервере RD Connection Broker переходим Server Manager -> Remote Desktop Services -> Overview. В поле Deployment Overview в выпадающем списке TASKS выбираем Edit Deployment Properties.
Открываем вкладку Certificates и устанавливаем необходимый сертификат *.yourcompany.com для всех сервисов фермы. Добавление производится по одному за действие. Выбираем существующий сертификат, указываем его путь на файловой системе и пароль.
После чего данные сертификаты будут установлены на серверах VDI, но не на виртуальных машинах. В реестре на Connection Broker сервере появится SSLCertificateSHA1Hash REG_BINARY параметр со значением thumbprint сертификата по следующему адресу:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp.
Данный параметр отвечает за выбор сертификата, который будет использоваться при установке RDP сессии. Это параметр необходимо будет установить и на клиентские машины.
Установка сертификата на виртуальные машины
Для использования белого сертификата на виртуальных машинах необходимо:
- Установить сертификат на все машины в персональное хранилище сертификатов компьютера.
- Установить права на чтение ключа сертификата для Network Service каждой машины.
- Иметь SSLCertificateSHA1Hash REG_BINARY параметр со значением thumbprint сертификата.
- Виртуальные имена машин должны совпадать с именем сертификата, т.е. иметь суффикс yourcompany.com
Создадим новую групповую политику на уровне Organizational Unit, выделенного для компьютерных аккаунтов виртуальных машин фермы VDI.
Данная политика должна выполнить Startup Script ExportVDICert.bat на виртуальных машинах.
В указанном скрипте используются утилиты certutil и FindPrivateKey от Microsoft. Certutil является встроенной утилитой, FindPrivateKey предоставляется в качестве Samle tool для разработчиков и может быль скомпилирован самостоятельно. Скрипт необходимо расположить внутри политики.
Сертификат и утилиту FindPrivateKey необходимо разместить в сетевой папке, откуда скрипт будет забирать файлы для установки. Текст скрипта:
certutil -f -p "<certificate password>" -importpfx "<Path to pfx>" NoExport
c:
mkdir "c:\TempCertSecurity"
cd "c:\TempCertSecurity"
xcopy "<Path to FindPrivateKey.exe>" "c:\TempCertSecurity"
FindPrivateKey.exe My LocalMachine -t "<thumbprint of certificate>" -a > tmp.txt
set /p myvar= < tmp.txt
del tmp.txt
del FindPrivateKey.exe
cd rd "c:\TempCertSecurity"
cacls.exe %myvar% /E /G "NETWORK SERVICE":R"
При помощи данного скрипта после перезагрузки виртуальной машины будет установлен новый сертификат и для него будут настроены права.
Следующая часть политики касается установки параметра SSLCertificateSHA1Hash. Необходимый ключ настраивается через Preferences \ Windows Settings \ Registry
Для централизованного изменения Primary DNS суффикса виртуальных машин в политике необходимо включить Primary DNS suffix и установить его как внешнее доменное имя yourcompany.com.
После перезагрузки, машина получит новый FQDN, соответствующий белому сертификату. После проведения данных операций, пользователи больше не увидят надоедливые предупреждения безопасности.
Комментарии (21)
AliraSirin
14.10.2015 13:28Белые сертификаты дорогие.
serjdag
14.10.2015 14:05можно взять на www.startssl.com за 60$ на 2 года, зато избавит вас от процедуры копирвоания корпортаивного СА на станции.
ErshoFF
14.10.2015 14:47Или бесплатно (http://habrahabr.ru/post/257207/) на три года, и его не жаль копировать.
При первой проверке такого сертификата возможны тормоза — Китай далеко.
Не пробовал для VDI, но для отдельного терминального сервера на 2008 существенного проще можно добавить.serjdag
14.10.2015 15:12+1для отдельного терминального сервера подойдет, для VDI нет, как ответил выше, нужен wildcard *.domain.com
ErshoFF
14.10.2015 15:23Может wildcard *.domain.com, но ничего не мешает прописать в сертификате
vdi1.domain.com
vdi2.domain.com
…
vdi50.domain.comserjdag
14.10.2015 16:38да, можно воспользоваться SANами, но если машин сотни, и вдруг потребуется внести изменение в именование, придется на всех устройствах менять сертификат
ErshoFF
14.10.2015 16:52Что вы имеете в виду под «SAN»?
В статье не нашел. Если это «Сеть хранения данных, СХД (англ. Storage Area Network, SAN)», почему именно при использовании «SAN»?
Если виртуальных машин столько, что не хвататет 50 имен третьего уровня — нет смысла использовать бесплатный сертификат, экономия ничтожна.
hardpoint
14.10.2015 16:59SAN это альтернативные имена в сертификате, что вы и писали (Subject Alternative Name)
navion
19.10.2015 16:07Выглядит очень сложно и странно, особенно в части установки сертификата на конечные ВМ.
Разве нельзя установить доверенный сертификат на RD Gateway через set-RDCertificate и подключаться через него?
Neuronix
Вы бы уточняли в заголовке, что за VDI, ибо VDI — это технология, но не название.
П.С. Вот как-то всё у майкрософта через одно место. В Citrix XenDesktop это делается в пару кликов мыши.
serjdag
Для большей ясности внес изменения в заголовок.
П.С. Ну и стоит Citrix дороже.
Neuronix
Это, как говорится, вопрос бюджета. Если есть возможность согласовать установку enterprise-level ПО, то по мне лучше его и использовать…
VahMaster
Microsoft VDI по вашему мнению не enterprise-level ПО? критерии определения есть?
Neuronix
Microsoft VDI еще далеко по возможностям до того же Citrix. В серьёзный продакшн я бы его не поставил.
hardpoint
чисто для интереса, какие например?, У меня, увы опыта работы Citrix нет, поэтому объективно определить нет возможности?
Neuronix
Ну хотя бы на вскидку те же HDX 3DPro, Flex, WAN-оптимизации, StoreFront и NetScaler… Да много всего
hardpoint
у MS VD есть аналогичные технологии мод другим маркетинговым названием, RemoteFX, SelfPortal, Load balance, RDG и оптимизация RDP для узких полос итд, нет объективной возможности сравнить эти технологии.
Neuronix
Боюсь, что те же оптимизации RDP для узких полос не сравнятся с цитриксовыми. RemoteFX большой шаг в сторону улучшения протокола, но до HDX 3DPro в тяжелой 3D графике опять же не дотягивает. Технологии может быть и аналогичные, но слабее. В будущем возможно Microsoft и догонит Citrix (хотя скорее всего это сделает VMWare). Очень много всяких мелких штучек, но вместе они делают картину.