Jump to content

domovoy

Members
  • Posts

    5
  • Joined

  • Last visited

Everything posted by domovoy

  1. И ещё один «довесок» — если настраивается подчинённый узел, то в «web» keytab-файл также добавлять ТОЛЬКО то SPN, которое ссылается на «системное» имя подчинённого узла (hostnamectl status)! А FQDN-ы на DNS-серверах для него публикуются только в том случае, если они отличаются от тех, которые были опубликованы для основного…
  2. Небольшое уточнение — после публикации всех FQDN на DNS-серверах ОБЯЗАТЕЛЬНО проверить, что в обратных зонах созданы корректные, статические PTR-записи!..
  3. Проблема решена: В анамнезе: 1. Сервер Ubuntu 22.04, зарегистрирован в домене Windows 2. SQUID-Proxy v.5.2, настроена kerberos-аутентификация в домене Windows 3. Kaspersky Web Traffic Security v.6.1- триальная, девяностодневная версия… Задачи: a) Уговорить Kaspersky Web Traffic Security отслеживать работу доменных пользователей (подключение к доменным LDAP-серверам для запроса информации о расположении учётных записей пользователей в структуре AD); b) Немного упростить себе жизнь и настроить в Kaspersky Web Traffic Security систему единого входа, позволяющую авторизованным доменным пользователям подключаться к нему для решения задач администрирования через WEB-интерфейс. Примечание: Мануалы, опубликованные здесь и здесь не имеют к реальному положению дел никакого отношения. По второй ссылке (создание keytab-файла для соединения с LDAP-серверами) вообще опубликован кривой листинг кода... Решение: 1. Создать для каждого сервера SQUID-Proxy по ДВЕ ОТДЕЛЬНЫХ, "ПЕРСОНАЛЬНЫХ" сервисных учётных записи: 1.1) Первая из них будет использована для настройки аутентификации пользователей в WEB-интерфейсе администрирования Kaspersky Web Traffic Security с помощью технологии единого входа; # напр. <server-domain-name01>.spn.kwts.web@<domain>.<name> <server-domain-name02>.spn.kwts.web@<domain>.<name> ... <server-domain-name##>.spn.kwts.web@<domain>.<name> В этих учётных записях будут зарегистрированы SPN ссылающиеся на СИСТЕМНЫЕ имена SQUID-Proxy серверов, а также SPN с FQDN-синонимами, которые будут использоваться для доступа к WEB-интерфейсам KWTS 1.2) Вторая будет использоваться для подключения Kaspersky Web Traffic Security, установленного на SQUID-Proxy серверы, к доменным LDAP-серверам # напр. <server-domain-name01>.spn.kwts.ldap@<domain>.<name> <server-domain-name02>.spn.kwts.ldap@<domain>.<name> ... <server-domain-name##>.spn.kwts.ldap@<domain>.<name> В учётных записях, которые предназначены для подключения к LDAP-серверам будет зарегистрировано ТОЛЬКО по ОДНОМУ SPN. 1.3) В свойствах каждой созданной учётной записи: - УСТАНОВИТЬ флаг "This account supports Kerberos AES 256 bit encryption" ("Данная учётная запись поддерживает 256-разрядное шифрование"); - СНЯТЬ флаг "Без предварительной проверки подлинности Kerberos" 2. Определить две гуппы FQDN, которые позже будут опубликованы на доменых DNS-серверах: 2.1) Первая группа (назовём её "KWTS-PROXY") будет содержать FQDN, предназначенные для обеспечения работоспособности аутентификации пользователей в WEB-интерфейсах администрирования узлов Kaspersky Web Traffic Security, с помощью технологии единого входа; # напр.: <server-domain-name01>.kwts.proxy.<domain>.<name> <server-domain-name02>.kwts.proxy.<domain>.<name> ... <server-domain-name##>.kwts.proxy.<domain>.<name> 2.2) Во второй группе (назовём её "LDAP-KWTS-PROXY") будут содержаться FQDN, которые потребуются для обеспечения подключения узлов KWTS к доменным LDAP-серверам # напр.: <server-domain-name01>.ldap.kwts.proxy.<domain>.<name> <server-domain-name02>.ldap.kwts.proxy.<domain>.<name> ... <server-domain-name##>.ldap.kwts.proxy.<domain>.<name> 3. Создать keytab-файлы для обеспечения работоспособности модулей на узлах Kaspersky Web Traffic Security, которым требуется kerberos-аутентификация (WEB-интерфейсы и LDAP). 3.1) Keytab-файл для включения аутентификации в WEB-интерфейсе узла KWTS с помощью технологии единого входа (имя файла - <server-domain-name##>.spn.kwts.web.keytab) 3.1.1) Зайти на SQUID-Proxy сервер через терминал, запросить и записать для дальнейшего использования, настроенное имя хоста: hostnamectl status # Пример вывода Static hostname: <server-name> ... (!!!) ВАЖНО (!!!) Для дальнейшей настройки понадобится ПОЛНОЕ ЗНАЧЕНИЕ параметра "Static hostname", в каком бы формате оно не было (это может быть как краткое имя, так и имя в формате FQDN) 3.1.2) На контроллере домена: 3.1.2.1) С помощью утилиты ktpass создать "web" keytab-файл: a) При создании "web" keytab-файла использовать сервисную учётную запись, созданную в п.1.1, и содержащую в имени название настраиваемого сервера # напр.: <server-domain-name##>.spn.kwts.web b) ЕДИНСТВЕННОЕ SPN, которое должно быть добавлено в "web" keytab-файл, ОБЯЗАТЕЛЬНО ДОЛЖНО ссылаться на НАСТРОЕННОЕ ИМЯ ХОСТА, полученное в п.3.1.1: (!!!) ВАЖНО (!!!) Если <server-name> имеет краткий формат, то SPN должно содержать именно КРАТКИЙ ФОРМАТ. # напр.: HTTP/<server-name>@<DOMAIN>.<NAME> Если же <server-name> имеет формат FQDN, то SPN должно содержать FQDN # напр.: HTTP/<server-name>.<domain>.<name>@<DOMAIN>.<NAME> C:\Windows\system32\ktpass.exe -princ HTTP/<server-name>@<DOMAIN>.<NAME> -mapuser <server-domain-name##>.spn.kwts.web@<DOMAIN>.<NAME> -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass * -out <path>\<to>\<keytab>\<file>\<server-domain-name##>.spn.kwts.web.keytab 3.1.2.2) В оснастке Active Directory Users and Computers, добавить в настройках сервисной учётной записи (атрибут servicePrincipalName) SPN, ссылающееся на FQDN, определённое для настраиваемого сервера в п.2.1 (из группы "KWTS-PROXY"): # напр. HTTP/<server-domain-name##>.kwts.proxy.<domain>.<name> (!!!) REALM-name (@<DOMAIN>.<NAME>) не указывать Для этого: a) В меню "Вид" установить флаг "Дополнительные компоненты"; b) Перейти в свойства нужной учётной записи и открыть вкладку "Редактор атрибутов"; c) В списке атрибутов найти атрибут "servicePrincipalName" и открыть его для редактирования; d) В форме редактора... - В поле "Добавляемое значение:" ввести название нового SPN, содержащее настраиваемое FQDN, напр. HTTP/<server-domain-name##>.kwts.proxy.<domain>.<name> - Нажать кнопку "Добавить", расположенную справа от поля "Добавляемое значение"; - После окончания редактирования, нажать кнопку "ОК" в форме редактора атрибута; - Нажать кнопки "Применить" и "ОК" в форме свойств учётной записи. 3.1.3) Опубликовать на доменных DNS-серверах FQDN, определённое для настраиваемого сервера в п.2.1 и использованное в предыдущем пункте (в примерах - <server-domain-name##>.kwts.proxy.<domai>.<name>) 3.1.4) Открыть в браузере, от имени локального администратора узла KWTS, WEB-интерфейс узла KWTS, для которго производилось создание keytab-файла a) Перейти "Параметры" --> "Доступ к программе" --> "Вход с помощью службы единого входа"; b) Включить опцию "Использовать Kerberos"; c) Загрузить, ранее созданный, "web" keytab-файл; d) Нажать кнопку "Сохранить"; e) Закрыть страницу браузера с WEB-интерфейсом узла KWTS; f) Перезагрузить браузер. После произведённых настроек, аутентификации в WEB-интерфейсе узла KWTS с помощью технологии единого входа будет доступна ТОЛЬКО если к нему обращаться по FQDN, опубликованному для этого узла в п.3.1.3. При использовании любого другого FQDN доступ к WEB-интерфейсу будет возможен только от имени локального администратора узла KWTS. 3.2) Keytab-файл для настройки соединения узла KWTS с доменными LDAP-серверами (имя файла - <server-domain-name##>.spn.kwts.ldap.keytab) 3.2.1) На контроллере домена, с помощью утилиты ktpass создать "ldap" keytab-файл: a) При создании "ldap" keytab-файла использовать сервисную учётную запись, созданную в п.1.2, и содержащую в имени название настраиваемого сервера # напр.: <server-domain-name##>.spn.kwts.ldap b) ЕДИНСТВЕННОЕ SPN, которое должно быть добавлено в "ldap" keytab-файл, должно ссылаться на FQDN, определённое для настраиваемого сервера в п.2.2 (из группы "LDAP-KWTS-PROXY"): # напр.: HTTP/<server-domain-name##>.ldap.kwts.proxy.<domain>.<name> (!!!) ВНИМАНИЕ (!!!) KEYTAB-ФАЙЛ, используемый Kaspersky Web Traffic Security для подключения к LDAP-серверу, должен содержать НЕ БОЛЕЕ ОДНОГО SPN. C:\Windows\system32\ktpass.exe -princ HTTP/<server-domain-name##>.ldap.kwts.proxy.<domain>.<name>@<DOMAIN>.<NAME> -mapuser <server-domain-name##>.spn.kwts.ldap@<DOMAIN>.<NAME> -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass * -out <path>\<to>\<keytab>\<file>\<server-domain-name##>.spn.kwts.ldap.keytab 3.2.2) Опубликовать на доменных DNS-серверах FQDN, определённое для настраиваемого сервера в п.2.2 и использованное в предыдущем пункте (в примерах - <server-domain-name##>.ldap.kwts.proxy.<domain>.<name>) 3.2.3) Открыть в браузере, WEB-интерфейс узла KWTS, для которго производилось создание "ldap" keytab-файла a) Перейти "Параметры" --> "Внешние службы" --> "Соединение c LDAP-сервером"; b) Нажать кнопку "Добавить"; c) В поле "Имя" ввести любое информативное название подключения, напр. <sub-domain>.<domain>.<name> d) Загрузить, ранее созданный, "ldap" keytab-файл; e) В поле "База поиска" ввести DN (Distinguished Name – уникальное имя) объекта каталога, начиная с которого KWTS будет осуществлять поиск записей (напр. DC=<sub-domain>, DC=<domain>, DC=<name>); f) Нажать кнопку "Добавить"; g) В окне формы "Соединение c LDAP-сервером" нажать кнопку "Синхронизировать" и, перейдя по ссылке "Перейти в раздел узлы", проверить результаты синхронизации узла KWTS c LDAP-серверами;
  4. Добавлю: тот же keytab-файл, на который ругается KWTS, при попытке использовать его для аутентификации входа доменных пользователей, отлично работает при настройке подключения по LDAP! Похоже, что либо в инструкции по его созданию что-то не учтено, либо сбоит функционал самого KWTS…
  5. Здравствуйте, столкнулся с идентичной проблемой. Указание после "@" рилмы прописью проблему не решает. Подскажите, где ещё может быть косяк?
×
×
  • Create New...