Установка белого сертификата на ферму Microsoft VDI



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

    image


    В данном случае, предупреждение появляется дважды: первый раз не доверенным является 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 запросах.

    image


    Следующую политику необходимо включить и добавить через запятую значения внутреннего доменного имени и внешнего доменного имени: Computer Configuration \ Policies \ Administrative Templates \ Network \ DNS Client\ DNS suffix search list.

    image


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

    Перед созданием VDI фермы необходимо выполнить смену DNS суффикса планируемых RD серверов на имя внешнего домена. Для этого перейдем в свойства компьютера и выберем изменить имя компьютера. В окне изменения имени компьютера необходимо нажать на кнопку More… и задать новый первичный DNS суффикс компьютера — yourcompany.com.

    image

    Далее создаем новую ферму VDI, основываясь на выбранных серверах Microsoft Windows Server 2012 R2. Информацию по данной процедуре можно легко найти в сети.

    После того, как pfx файл сертификата будет на руках, можно приступить к установке его на новую VDI ферму. На сервере RD Connection Broker переходим Server Manager -> Remote Desktop Services -> Overview. В поле Deployment Overview в выпадающем списке TASKS выбираем Edit Deployment Properties.

    image


    Открываем вкладку Certificates и устанавливаем необходимый сертификат *.yourcompany.com для всех сервисов фермы. Добавление производится по одному за действие. Выбираем существующий сертификат, указываем его путь на файловой системе и пароль.

    image


    После чего данные сертификаты будут установлены на серверах VDI, но не на виртуальных машинах. В реестре на Connection Broker сервере появится SSLCertificateSHA1Hash REG_BINARY параметр со значением thumbprint сертификата по следующему адресу:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp.

    Данный параметр отвечает за выбор сертификата, который будет использоваться при установке RDP сессии. Это параметр необходимо будет установить и на клиентские машины.

    image


    Установка сертификата на виртуальные машины

    Для использования белого сертификата на виртуальных машинах необходимо:

    • Установить сертификат на все машины в персональное хранилище сертификатов компьютера.
    • Установить права на чтение ключа сертификата для Network Service каждой машины.
    • Иметь SSLCertificateSHA1Hash REG_BINARY параметр со значением thumbprint сертификата.
    • Виртуальные имена машин должны совпадать с именем сертификата, т.е. иметь суффикс yourcompany.com

    Создадим новую групповую политику на уровне Organizational Unit, выделенного для компьютерных аккаунтов виртуальных машин фермы VDI.

    Данная политика должна выполнить Startup Script ExportVDICert.bat на виртуальных машинах.

    image


    В указанном скрипте используются утилиты 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

    image


    Для централизованного изменения Primary DNS суффикса виртуальных машин в политике необходимо включить Primary DNS suffix и установить его как внешнее доменное имя yourcompany.com.

    image


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

    Ну. И что?
    Реклама
    Комментарии 22
      0
      Вы бы уточняли в заголовке, что за VDI, ибо VDI — это технология, но не название.
      П.С. Вот как-то всё у майкрософта через одно место. В Citrix XenDesktop это делается в пару кликов мыши.
        +3
        Для большей ясности внес изменения в заголовок.
        П.С. Ну и стоит Citrix дороже.
          –1
          Это, как говорится, вопрос бюджета. Если есть возможность согласовать установку enterprise-level ПО, то по мне лучше его и использовать…
            +3
            Microsoft VDI по вашему мнению не enterprise-level ПО? критерии определения есть?
              0
              Microsoft VDI еще далеко по возможностям до того же Citrix. В серьёзный продакшн я бы его не поставил.
                +2
                чисто для интереса, какие например?, У меня, увы опыта работы Citrix нет, поэтому объективно определить нет возможности?
                  +1
                  Ну хотя бы на вскидку те же HDX 3DPro, Flex, WAN-оптимизации, StoreFront и NetScaler… Да много всего
                    +2
                    у MS VD есть аналогичные технологии мод другим маркетинговым названием, RemoteFX, SelfPortal, Load balance, RDG и оптимизация RDP для узких полос итд, нет объективной возможности сравнить эти технологии.
                      0
                      Боюсь, что те же оптимизации RDP для узких полос не сравнятся с цитриксовыми. RemoteFX большой шаг в сторону улучшения протокола, но до HDX 3DPro в тяжелой 3D графике опять же не дотягивает. Технологии может быть и аналогичные, но слабее. В будущем возможно Microsoft и догонит Citrix (хотя скорее всего это сделает VMWare). Очень много всяких мелких штучек, но вместе они делают картину.
        0
        Белые сертификаты дорогие.
          0
          можно взять на www.startssl.com за 60$ на 2 года, зато избавит вас от процедуры копирвоания корпортаивного СА на станции.
            0
            можно подождать немного и получить уже бесплатно
              0
              в VDI лучше использовать wildcard, чтобы не прописывать имя каждой машины в SAN, а их бесплатно не дают. нужно проходить верификацию за 60$
                0
                Вот, кстати, еще плюс Citrix :) Для конечных машин сертификаты не нужны.
          0
          Или бесплатно (http://habrahabr.ru/post/257207/) на три года, и его не жаль копировать.
          При первой проверке такого сертификата возможны тормоза — Китай далеко.

          Не пробовал для VDI, но для отдельного терминального сервера на 2008 существенного проще можно добавить.
            +1
            для отдельного терминального сервера подойдет, для VDI нет, как ответил выше, нужен wildcard *.domain.com
              0
              Может wildcard *.domain.com, но ничего не мешает прописать в сертификате
              vdi1.domain.com
              vdi2.domain.com

              vdi50.domain.com
                0
                да, можно воспользоваться SANами, но если машин сотни, и вдруг потребуется внести изменение в именование, придется на всех устройствах менять сертификат
                  0
                  Что вы имеете в виду под «SAN»?
                  В статье не нашел. Если это «Сеть хранения данных, СХД (англ. Storage Area Network, SAN)», почему именно при использовании «SAN»?

                  Если виртуальных машин столько, что не хвататет 50 имен третьего уровня — нет смысла использовать бесплатный сертификат, экономия ничтожна.
            0
            SAN это альтернативные имена в сертификате, что вы и писали (Subject Alternative Name)
              0
              Выглядит очень сложно и странно, особенно в части установки сертификата на конечные ВМ.
              Разве нельзя установить доверенный сертификат на RD Gateway через set-RDCertificate и подключаться через него?
                0
                Сертификат итак устанавливается на RDG сервер. Если имя конечной виртуальной машины не доверенное, то при подключении все равно будет появляться предупреждение безопасности, поэтому сертификаты также ставятся и на конечные виртуальные машины.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое