Аутентифікація користувачів термінальних серверів на FirePOWER



Для нас, інженерів, стежити за появою нових версій 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» – член групи ІТ-відділ. Другий користувач «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.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.