Всем привет, в прошлой статье я рассказывал о нашем опыте миграции с Palo Alto на Континент 4. В этой статье расскажу, как мы настроили прозрачную аутентификацию на межсетевом экране Континент 4.
Введение
Одним из важных отличий межсетевого экрана L3/L4 от NGFW, является то, что при фильтрации трафика имеется возможность в качестве источника указать не IP-адрес, а пользователя/группу пользователей. В Palo Alto для аутентификации пользователей использовался User-ID Agent который считывал события входа/выхода с контроллеров домена.
При выборе методов аутентификации были сформированы следующие требования:
Аутентификация должна происходить после входа пользователя в сессию и разрываться при блокировке экрана, выхода из сессии.
Аутентификация должна выполняться прозрачно и не должна требовать явного ввода логина/пароля или взаимодействия с браузером.
Аутентификация должна выполняться для ОС под управлением Windows/Linux.
Трудности выбора
Кратко расскажу о методах аутентификации пользователей, доступных в Континент 4 и почему ни один из вариантов нам не подошел. В качестве каталога пользователей используется Microsoft Active Directory и доступны следующие способы аутентификации:
Агент идентификации.
Captive Portal.
Прозрачная аутентификация по протоколу Kerberos.
Агент идентификации
Агент идентификации представляет собой приложение под Windows, в котором требуется указать доменное имя Узла безопасности на котором требуется аутентифицироваться.
Для аутентификации на УБ необходимо после входа в пользовательскую сессию открыть Агент аутентификации и явно ввести логин/пароль пользователя.
Captive Portal
При аутентификации с использованием данного метода пользователям необходимо явно перейти на адрес портала аутентификации, либо, если настроены правила автоматического перенаправления, пользователь при открытии произвольной страницы в браузере будет перенаправлен на веб-форму, где необходимо явно ввести логин/пароль.
Для завершения сессии пользователю требуется нажать кнопку на Портале.
KERBEROS
В Континент реализован механизм браузерной прозрачной аутентификации с использованием протокола SPNEGO. Весь процесс аутентификации выглядит следующим образом:
-
Пользователь входит в домен Windows со своей рабочей станции и пытается получить доступ в интернет с помощью веб-браузера. Веб-браузер отправляет HTTP-запрос, который перехватывается узлом безопасности.
2. Перехватив запрос клиента, УБ отправляет ему обратно HTTP-ответ с кодом 401 (Unauthorized) и заголовком авторизации "WWW-Authenticate: Negotiate".
3. Веб-браузер распознает заголовок Negotiate. Затем запускается поиск имени УБ в DNS, используя которое вычисляется имя участника — службы (SPN).
4. Используя SPN, сервис проверки подлинности локальной системы запрашивает билет Kerberos у центра распределения ключей (KDC) — начинается последовательность аутентификации Kerberos, своеобразный диалог между клиентом и KDC. В результате клиент получает сервисный билет (ST), на основе которого УБ будет доверять ему.
5. Веб-браузер повторно отправляет исходный HTTP-запрос, но на этот раз аутентификационные данные пользователя содержатся в зашифрованном билете Kerberos, инкапсулированном в токен SPNEGO, который передается в заголовке авторизации HTTP.
6. УБ видит в запросе входящий токен SPNEGO, затем извлекает информацию из сервисного билета Kerberos, который содержит всю необходимую для аутентификации информацию.
Все перечисленные методы аутентификации не подошли т.к. требуют явного взаимодействия с браузером и/или ручного ввода логина/пароля.
Доработка для АРМ Windows
Что же мы будем использовать для прозрачной аутентификации?
PowerShell – понадобится для logon/logoff-скриптов.
GPO – для распространения logon/logoff-скриптов.
Включенная Kerberos-аутентификация на Континент – для аутентификации пользователя.
Включенный Портал аутентификации на Континент – для завершения сессии, т.к. кнопка завершения сессии находится на данном портале.
В PowerShell мы будем использовать командлет, который позволяет отправлять запросы HTTP/HTTPS/FTP ресурсам.
Для аутентификации используем команду:
Invoke-WebRequest -Uri https://k4-auth.lab.local/sso/login -UseDefaultCredentialsПараметр UseDefaultCredentials указывает, что командлет использует учетные данные текущего пользователя для отправки веб-запроса.
Для завершения сессии используем команду:
Invoke-WebRequest -Uri https://k4-auth.lab.local/user-auth/user-exit -UseDefaultCredentials -Method POSTПриступаем к настройке Континент 4.
Длительность сеанса пользователя выставляем максимальную, при включении портала аутентификации обязательно требуется указать Диапазон перенаправляемых адресов, но т.к. у нас аутентификация будет выполняться с использованием PowerShell, то указываем адрес Узла Безопасности (можно указать произвольный адрес, т.к. функция перенаправления не будет использоваться).
Настраиваем запуск PowerShell сценариев при входе/выходе пользователя в систему с использованием планировщика.
Для этого создаём новую групповую политику – Изменить – Конфигурация пользователя – Настройка – Параметры панели – Назначенные задания – Создать Запланированная задача (Windows 7 и выше).
Logon-script
Во вкладке Общие выбираем «Выполнять только для зарегистрированного пользователя», во вкладке Триггеры выбираем «При входе в систему», «При разблокировании рабочей станции». На вкладке Действия настраиваем Запуск программы, указываем полный путь «C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe» в качестве аргументов указываем команду:
-WindowStyle hidden -command Invoke-WebRequest -Uri https://k4-auth.lab.local/sso/login -UseDefaultCredentialsLogoff-script
Во вкладке Общие выбираем «Выполнять только для зарегистрированного пользователя», во вкладке Триггеры выбираем «При блокировании рабочей станции любым пользователем», «По Событию - Журнал Security – Код 4647»
На вкладке Действия настраиваем Запуск программы,
указываем полный путь «C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe»
в качестве аргументов указываем команду:
-WindowStyle hidden -command Invoke-WebRequest -Uri https://k4-auth.lab.local/user-auth/user-exit -UseDefaultCredentials -Method POSTПроверим работу скрипта: на доменном АРМ аутентифицируемся в доменную УЗ и убеждаемся, что в интерфейсе Мониторинга отображается аутентифицированный пользователь.
Доработка для АРМ Linux
В качестве АРМ используется Astra Linux, поэтому настройки приведены для данной ОС. Для прозрачной аутентификации мы будем использовать curl.
Для аутентификации пользователя создаём скрипт /etc/profile.d/auth.sh, который будет выполняться для всех пользователей после выполнения аутентификации.
#!/bin/bash
/bin/curl -v -u : --negotiate https://k4-auth.lab.local/sso/login &> /dev/nullДля пользователя создаём скрипт /etc/X11/Xreset.d/logout, который будет выполняться при завершении графической сессии.
bin/curl -v -X POST -u : --negotiate https://k4-auth.lab.local/user-auth/user-exitНеобходимо разрешить запуск скрипта:
chmod +x /etc/X11/Xreset.d/logoutЗаключение
Таким образом нам удалось решить задачу прозрачной аутентификации с использованием скриптов.
Спасибо за уделенное время и до встречи в следующих статьях!