Jump to content

WebTrafficSecurity


Go to solution Solved by domovoy,

Recommended Posts

Posted (edited)

1. Неверный keytab-файл для Управляющего узла

делаю все по руководству https://support.kaspersky.com/KSMG/2.0/ru-RU/206091.htm

Цитата

ktpass -princ HTTP/*****@*****.tld -mapuser *****@*****.tld -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass grh35tgtftrj46y545t5t +dumpsalt -out c:\Temp\KasWTS.keytab

 

2022-06-09_135822.png

Что не так?

2. используем Kaspersky Anti-Virus for Proxy Server, как получить лицензию на WebTrafficSecurity ?

 

Edited by modul
поправил
Posted
Добрый день.
В цитате у вас не соблюдено условие:
"<realm имя домена Active Directory в верхнем регистре>".
 
То есть Вам надо в двух местах после собаки написать капсом: ...@DOMAIN.TLD
  • Confused 1
Posted

сделал несколько лишних пробелов, чтобы обмануть фильтр

доменные имена писались капсом в двух местах

 

ktpass -princ HTTP/kav-02. aaaa .loc @ AAAA .LOC -mapuser KasWTS @ AAAA .LOC -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass grh35tgtftrj46y545t5t +dumpsalt -out c:\Temp\KasWTS.keytab

  • 2 months later...
Posted

Здравствуйте, столкнулся с идентичной проблемой.

Указание после "@" рилмы прописью проблему не решает.

Подскажите, где ещё может быть косяк?

Posted
В 18.08.2022 в 11:33, domovoy сказал:

Здравствуйте, столкнулся с идентичной проблемой.

Указание после "@" рилмы прописью проблему не решает.

Подскажите, где ещё может быть косяк?

Добавлю:

тот же keytab-файл, на который ругается KWTS, при попытке использовать его для аутентификации входа доменных пользователей, отлично работает при настройке подключения по LDAP! Похоже, что либо в инструкции по его созданию что-то не учтено, либо сбоит функционал самого KWTS…

  • 2 weeks later...
  • Solution
Posted
В 18.08.2022 в 11:33, domovoy сказал:

Здравствуйте, столкнулся с идентичной проблемой.

Указание после "@" рилмы прописью проблему не решает.

Подскажите, где ещё может быть косяк?

Проблема решена:

 

В анамнезе:

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-серверами;

Posted
6 часов назад, domovoy сказал:

Проблема решена:

Небольшое уточнение — после публикации всех FQDN на DNS-серверах ОБЯЗАТЕЛЬНО проверить, что в обратных зонах созданы корректные, статические PTR-записи!..

Posted
В 01.09.2022 в 23:59, domovoy сказал:

Небольшое уточнение —

И ещё один «довесок» — если настраивается подчинённый узел, то в «web» keytab-файл также добавлять ТОЛЬКО то SPN, которое ссылается на «системное» имя подчинённого узла (hostnamectl status)! А FQDN-ы на DNS-серверах для него публикуются только в том случае, если они отличаются от тех, которые были опубликованы для основного…

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now


×
×
  • Create New...