Всем привет, в прошлой статье я рассказывал о нашем опыте миграции с 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. Весь процесс аутентификации выглядит следующим образом:

  1. Пользователь входит в домен 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

Что же мы будем использовать для прозрачной аутентификации?

  1. PowerShell – понадобится для logon/logoff-скриптов.

  2. GPO – для распространения logon/logoff-скриптов.

  3. Включенная Kerberos-аутентификация на Континент – для аутентификации пользователя.

  4. Включенный Портал аутентификации на Континент – для завершения сессии, т.к. кнопка завершения сессии находится на данном портале.

В 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 -UseDefaultCredentials

Logoff-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

Заключение

Таким образом нам удалось решить задачу прозрачной аутентификации с использованием скриптов.

Спасибо за уделенное время и до встречи в следующих статьях!

Комментарии (0)