Для нас, инженеров, следить за появлением новых версий FirePOWER – настоящее удовольствие. Каждый раз, открывая очередной Release Notes, мы с замиранием сердца (а иногда и с полной остановкой) изучаем новые фичи, добавленные разработчиками.
Одним из долгожданных нововведений стал Cisco Terminal Server Agent (далее TS Agent). Он предназначен для корректной аутентификации пользователей терминальных серверов (далее ТС). В данном материале расскажу, зачем он нужен и как работает.
Напомню, что проблема аутентификации на ТС в том, что в большинстве решений, подобных FirePOWER, она работает именно по IP-адресу, который для всех пользователей ТС одинаковый.
Например, на терминальном сервере одновременно работают Василий и Пётр. По корпоративным правилам Василию можно посещать соц. сети, а Пете — нет. МСЭ не сможет отделить трафики Василия и Петра друг от друга, не имея дополнительной информации, кроме IP-адреса. Поэтому, либо обоим сотрудникам будет запрещён доступ в соц. сети, либо обоим разрешён.
Есть разные способы решения проблемы. Например, «костыльный» вариант, с использованием технологии IP Virtualization на ТС. В этом случае, каждой новой сессии на ТС будет присвоен уникальный IP-адрес. Но сразу стоит отметить, что у такого подхода есть множество нюансов.
Web-прокси Cisco WSA вводит понятие Session-cookies (отпечаток сессии). Благодаря информации из Session-cookies WSA может отличить пользователей с одинаковыми IP-адресами. Но есть недостаток: cookies могут быть использованы только для браузерных сессий. Приложения, не поддерживающие cookies, работать не будут (Skype, TeamViewer и т.д.).
Использование агента, устанавливаемого на ТС, – наиболее универсальный метод решения проблемы. Identity Agent давно существует для решений Checkpoint. Теперь, наконец-то, и Cisco представила аналогичное решение для МСЭ на базе FirePOWER. Анонс состоялся 29 августа 2016 (мы об этом упоминали тут, UPD (02.09.2016)). Но доступным для скачивания агент стал только 26 января 2017. Из официального Release Notes для версии 6.1 FirePOWER Management Center (FMC, система управления FirePOWER) информация о терминальном агенте была убрана и перекочевала в Release Notes для 6.2. Таким образом, терминальный агент поддерживается на FMC, начиная с версии 6.2.
Как агент работает
Идея проста как тапок. Для каждого пользователя ТС транслируются source tcp/udp порты запускаемых сессий в определённый пул портов. Да-да, именно транслируются. Происходит PAT. При установке агента на сервер добавляется специальных низкоуровневый драйвер, который занимается преобразованием tcp/udp портов.
Информация о сопоставлении пользователя и пула портов передаётся на управлялку FMC (FirePOWER Management Center) по REST API.
Агент скачивается с cisco.com в виде установочного exe-файла. После выполнения инсталляции на ТС, открывается окно настройки агента:
Здесь мы можем задать, сколько пользователей могут одновременно использовать сервер (Max User Sessions). В данной версии агента 199 юзеров – максимум.
Выбираем сетевую карту сервера, и какие порты можем и не можем использовать для трансляции.
Чтобы система заработала, необходимо указать IP-адрес FMC и пользователя, обладающего правами использования REST VDI. По умолчанию правами обладают следующие роли пользователей:
- Access Admin
- Admin
- Network Admin
Можно создать на FMC отдельную роль для агента, что я и сделал для теста.
Вкладка System → Users → User Roles. Нажимаем Create User Role:
Выбираем из подменю «Rest VDI».
Далее, создаём пользователя ts-agent и присваиваем ему только что созданную роль TS Agent. На вкладке Users нажимаем Create User:
Возвращаемся к агенту, вводим IP-адрес FMC, пользователя ts-agent и его пароль. Нажимаем Test:
Нажимаем Save. Тут нюанс: агент попросит перезагрузить сервер. Ничего не поделать, подчиняемся воле бездушной машины. Кстати (или не кстати), внесение любых изменений в настройках агента тоже требует перезагрузки.
Всё готово. Можно проверить, что получилось. Сделаем два правила доступа на FMC. Первое правило для группы из AD «IT-отдел», по нему будет разрешён полный доступ в Интернет. Второе правило для всех остальных пользователей. По этому правилу блокируем доступ к соц. сетям. Настройка:
Заходим под двумя пользователями на ТС. Первый пользователь “Uskov” – член группы IT-отдел. Второй пользователь “Vasiliy” – не входит в IT-отдел. Соответственно, для “Uskov” будет разрешено ходить в соц. сети, для «Vasiliy» — запрещено. Проверяем.
Для «Uskov»:
Для «Vasiliy»:
Фух, не обманули цискоделы, работает! Посмотрим логи. В агенте видно, какие диапазоны портов выданы пользователям:
На FMC на вкладке Analysis → Users → User Activity появилась информация по портам:
Всё работает, как задумывалось.
На что агент устанавливается
- Windows Server 2008 R2;
- Windows Server 2012;
- Windows Server 2012 R2.
Поддерживаются следующие системы виртуализации:
- Citrix XenDesktop
- Citrix XenApp
- Xen Project Hypervisor
- VMware vSphere Hypervisor/VMware ESXi 6.0
- Windows Terminal Services/Windows Remote Desktop Services (RDS)
Ограничения и замечания для первой версии агента (1.0.0-36)
- До 199 пользователей на ТС;
- Может использоваться только одна сетевая карта ТС;
- Время на ТС должно быть синхронизировано со временем на FMC;
- На FMC информация о пользователях, полученная от TS Agent приоритетнее, чем информация от других источников пассивной аутентификации: User Agent и Cisco ISE. Это логично, иначе чуда бы не было. Активную аутентификацию не следует использовать в паре с TS Agent.
Автор: CBS
