Как я расширял возможности использования Citrix VDI в компании
Invite pending
В далеком 2015 году в нашей маленькой, но успешно развивающейся компании появился продукт SAP BPC. Для поддержки пользователей возникла необходимость предоставить доступ сторонней организации. Был приглашен для данного проекта интегратор и принято решение использовать Citrix. Серверы SAP был вынесены в отдельный домен.
Интегратор на нашем vCenter развернул все необходимые сервисы:
Пользователям предоставлена возможность работать под учетными записями домена virtual.local.
Специалисты SAP получали идентичный доступ и подключались к пользовательским виртуальным машинам VDI для технической поддержки.
Все это работало на протяжении нескольких лет без изменений. Но в 2017 году мне чертовски надоело создавать учетные записи для пользователей и сбрасывать им забытые пароли.
Что имелось на момент ухода от стандартной схемы от интегратора:
Мной было принято окончательное решение избавиться от рутины дублирования учетных записей и провести модернизацию VDI для использования более широкого спектра сервисов и приложений.
Ожидаемый результат:
Приступим:
1. Для авторизации под учетными записями из другого домена требуется настроить доверительные отношения между удаленным доменом и доменом среды VDI (virtual.local).
2. Приступаем к настройке Citrix.
В трастовых доменах можно указать домен по умолчанию, показывать или скрывать список доменов при входе через Citrix Receiver, либо просто включить «Любой домен» (не рекомендую в целях безопасности и лишних нагрузок):
3. При первом же входе выпала ошибка — пользователь не может войти в эту машину.
Не добавил пользователя в группу Пользователи виртуальной машины.
На golden image добавляем пользователей других доменов (или специально созданную группу) в группу локальных пользователей:
4. В домене virtual.local были созданы группы доступа к каталогу машин (по количеству подключенных доменов).
Группы пользователей по компаниям входят в группу DG_VDI_Regions. Эта группа применяется в настройках доступа к каталогу машин средствами Delivery Groups.
Другие группы и пользователи на приведенном рисунке сигнализируют, что работы по изменению проводились на живой рабочей системе (страху натерпелся…)
5. Настройку мульти доменной аутентификации на NetScaler лучше всего вынести в отдельный пост со ссылками, откуда мне пришлось черпать информацию, со снимками политик авторизации под разные платформы и GSLB. Если этот пост одобрят, то обязательно это сделаю!
6. Мысль про расширение VDI под другие сервисы и задачи пришла в процессе внедрения мульти доменной аутентификации.
Средствами групповых политик пользователям по группам назначаются диски на файловые сервера дочерних компаний. Аутентификация в таком случае прозрачная.
Если кто знает, как пробросить DFS между лесами – готов к рекомендациям. Сейчас же просто указываю название сервера!!! Внутри компании используется DFS и ссылки вида \\ домен\dfs прекрасно работают, но в VDI домене они не определяются.
7. Добавление принтеров. У меня эта задача отобрала огромное количество времени. От Citrix было предложено создать принт-сервер в VDI и опубликовать принтеры из регионов. Хочу заметить, что при входе пользователя на свой родной принт-сервер все доступные этой учетной записи принтеры видны и их можно подключить. В последующем подключенный принтер подключался при входе пользователя в VDI. Но заставить пользователей это делать – это не наш метод. Было принято решение сделать импорт групповых политик привязки принтеров из доменов дочерних организаций в домен VDI.
8. При входе пользователь просто открывает OUTLOOK и получает подключение к своему почтовому серверу Exchange. Просто жмем Далее-Далее-Далее, как это делается в корпоративной сети с сервером Exchange.
И так, мы получили практически рабочее место пользователя. Но в компании повсеместно используют 1С. Вот именно с этим сервисом появились заминки. Нет, не в публикации баз или серверов, а в каналах связи.
При открытии приложения 1С Документооборот приложение пользователя скачивает с сервера почти 300Мб. Открытие зависает до 5-10 минут. Работать не возможно. С вязи с трудной работой на уровне сетевого оборудования (не будем о грустном), решать вопрос с сетью не представляется возможным. Было принято решение консолидировать 1С базы в головной организации. Такая судьба коснулась других корпоративных продуктов (специфичные).
Но, чем больше дают, тем больше хочется. Пользователям потребовался доступ к сервисам, которые пока еще не консолидированы.
Данный доступ предоставлен методом проброса RDP на терминальный сервер в региональном домене. Аутентификация прозрачная.
У пользователя в папке лежит файлик rdp, ведущий на RemoteApp на терминальном сервере, при открытии которого пользователю не нужно вводить логин и пароль. Удобно и работает.
Вывод
Появилась ясность функционала Citrix, его возможностей, необходимость запуска виртуальных машин на гипервизорах в региональных инфраструктурах. Для этого необходимо расширить лицензию, чем сейчас и занимаюсь. Все это может привести к окончательному переходу к тонким клиентам.
Интегратор на нашем vCenter развернул все необходимые сервисы:
- Отдельный лес AD с доменом virtual.local
- Citrix Studio, DDC, License Server
- NetScaler со всевозможными службами (HA, GSLB, SSO)
Пользователям предоставлена возможность работать под учетными записями домена virtual.local.
Специалисты SAP получали идентичный доступ и подключались к пользовательским виртуальным машинам VDI для технической поддержки.
Все это работало на протяжении нескольких лет без изменений. Но в 2017 году мне чертовски надоело создавать учетные записи для пользователей и сбрасывать им забытые пароли.
Что имелось на момент ухода от стандартной схемы от интегратора:
- Компании между собой общаются по внутренней сети (VPN) для работы в Terminal
- В каждой компании свой лес, со своим доменом на Windows 2012R2
- Отдельный домен для работы в VDI Windows2012R2
- Вход пользователей в Citrix производится с помощью Сitrix Receiver по внутренней сети
- Вход пользователей из Интернет происходит через NetCsaler
Мной было принято окончательное решение избавиться от рутины дублирования учетных записей и провести модернизацию VDI для использования более широкого спектра сервисов и приложений.
Ожидаемый результат:
- Авторизация пользователей под имеющимися учетными записями (мультидоменная авторизация)
- Создание и использование каталогов машин на гипервизорах дочерних предприятий
- Консолидация общих сервисов в головной организации
Приступим:
1. Для авторизации под учетными записями из другого домена требуется настроить доверительные отношения между удаленным доменом и доменом среды VDI (virtual.local).
Доверительные отношения
Для этого необходимо указать в DNS серверы условной пересылки
Для авторизации из другого домена использую политику
2. Приступаем к настройке Citrix.
В оснастке Citrix Studio добавляем доверенные домены
В трастовых доменах можно указать домен по умолчанию, показывать или скрывать список доменов при входе через Citrix Receiver, либо просто включить «Любой домен» (не рекомендую в целях безопасности и лишних нагрузок):
Configure Trusted Domains
3. При первом же входе выпала ошибка — пользователь не может войти в эту машину.
Не добавил пользователя в группу Пользователи виртуальной машины.
На golden image добавляем пользователей других доменов (или специально созданную группу) в группу локальных пользователей:
Настройки группы Пользователи
4. В домене virtual.local были созданы группы доступа к каталогу машин (по количеству подключенных доменов).
Группы доступа
Группы должны быть локальными
Группы пользователей по компаниям входят в группу DG_VDI_Regions. Эта группа применяется в настройках доступа к каталогу машин средствами Delivery Groups.
Свойства Delivery Groups
Другие группы и пользователи на приведенном рисунке сигнализируют, что работы по изменению проводились на живой рабочей системе (страху натерпелся…)
5. Настройку мульти доменной аутентификации на NetScaler лучше всего вынести в отдельный пост со ссылками, откуда мне пришлось черпать информацию, со снимками политик авторизации под разные платформы и GSLB. Если этот пост одобрят, то обязательно это сделаю!
Приведу пример, сколько политик получилось у меня
6. Мысль про расширение VDI под другие сервисы и задачи пришла в процессе внедрения мульти доменной аутентификации.
Средствами групповых политик пользователям по группам назначаются диски на файловые сервера дочерних компаний. Аутентификация в таком случае прозрачная.
Добавление файловых серверов
Если кто знает, как пробросить DFS между лесами – готов к рекомендациям. Сейчас же просто указываю название сервера!!! Внутри компании используется DFS и ссылки вида \\ домен\dfs прекрасно работают, но в VDI домене они не определяются.
7. Добавление принтеров. У меня эта задача отобрала огромное количество времени. От Citrix было предложено создать принт-сервер в VDI и опубликовать принтеры из регионов. Хочу заметить, что при входе пользователя на свой родной принт-сервер все доступные этой учетной записи принтеры видны и их можно подключить. В последующем подключенный принтер подключался при входе пользователя в VDI. Но заставить пользователей это делать – это не наш метод. Было принято решение сделать импорт групповых политик привязки принтеров из доменов дочерних организаций в домен VDI.
Выкладываю часть политик
8. При входе пользователь просто открывает OUTLOOK и получает подключение к своему почтовому серверу Exchange. Просто жмем Далее-Далее-Далее, как это делается в корпоративной сети с сервером Exchange.
Стандартное окно Outlook
И так, мы получили практически рабочее место пользователя. Но в компании повсеместно используют 1С. Вот именно с этим сервисом появились заминки. Нет, не в публикации баз или серверов, а в каналах связи.
При открытии приложения 1С Документооборот приложение пользователя скачивает с сервера почти 300Мб. Открытие зависает до 5-10 минут. Работать не возможно. С вязи с трудной работой на уровне сетевого оборудования (не будем о грустном), решать вопрос с сетью не представляется возможным. Было принято решение консолидировать 1С базы в головной организации. Такая судьба коснулась других корпоративных продуктов (специфичные).
Но, чем больше дают, тем больше хочется. Пользователям потребовался доступ к сервисам, которые пока еще не консолидированы.
Данный доступ предоставлен методом проброса RDP на терминальный сервер в региональном домене. Аутентификация прозрачная.
У пользователя в папке лежит файлик rdp, ведущий на RemoteApp на терминальном сервере, при открытии которого пользователю не нужно вводить логин и пароль. Удобно и работает.
Вывод
Появилась ясность функционала Citrix, его возможностей, необходимость запуска виртуальных машин на гипервизорах в региональных инфраструктурах. Для этого необходимо расширить лицензию, чем сейчас и занимаюсь. Все это может привести к окончательному переходу к тонким клиентам.