Настройка аутентификации в Active Directory через Kerberos на прокси

В данной инструкции описывается настройка прозрачной и автоматической аутентификации пользователей на веб-прокси через протокол Kerberos в устройстве Traffic Inspector Next Generation.

Данный функционал особенно актуален в доменной среде Active Directory, где данная технология позволяет реализовать аутентификацию в стиле Single Sign On (SSO).

SSO-аутентификация избавляет доменного пользователя от повторных запросов на прохождение аутентификации. Пользователь вводит доменный логин / пароль всего один раз - при логоне в операционную систему. При последующем обращении в Интернет через прокси Traffic Inspector Next Generation, аутентификация происходит прозрачно и автоматически.

В нашем примере используется следующая схема сети:

_images/scheme_kerberos.png

Контроллер домена имеет IP-адрес 192.168.137.2 и DNS-имя controller.dom.loc.

Устройство Traffic Inspector Next Generation имеет IP-адрес 192.168.137.8 и DNS-имя tinga.dom.loc.

Настройка доменного DNS-сервера

Проверьте существование на доменном DNS-сервере нужных ресурсных записей

  • в прямой доменной зоне - записи типа A, позволяющей осуществлять прямое преобразование DNS-имени контроллера домена в его IP-адрес
_images/dc_a_rec.png
  • в обратной доменной зоне - записи типа PTR, позволяющей осуществлять обратное преобразование IP-адреса контроллера домена в его DNS-имя
_images/dc_ptr_rec.png

Создайте на доменном DNS-сервере нужные ресурсные записи

  • добавьте в прямую доменную зону запись типа A, позволяющую осуществлять прямое преобразование DNS-имени устройства Traffic Inspector Next Generation в его IP-адрес
_images/ting_a_rec.png
  • добавьте в обратную доменную зону запись типа PTR, позваляющую осуществлять обратное преобразование IP-адреса устройства Traffic Inspector Next Generation в его DNS-имя
_images/ting_ptr_rec.png

Проверка настроек доменного DNS-сервера

Проверьте прямое и обратное разрешение DNS-записей с устройства Traffic Inspector Next Generation.

Прямое преобразование DNS-имени устройства TING:

drill tinga.dom.loc

Пример успешного результата:

;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 24200
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; tinga.dom.loc.       IN      A

;; ANSWER SECTION:
tinga.dom.loc.  3600    IN      A       192.168.137.8

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: 192.168.137.2
;; WHEN: Tue Oct  3 11:21:18 2017
;; MSG SIZE  rcvd: 47

Обратное преобразование IP-адреса устройства TING:

drill –x 192.168.137.8

Пример успешного результата:

;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 29393
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; 8.137.168.192.in-addr.arpa.  IN      PTR

;; ANSWER SECTION:
8.137.168.192.in-addr.arpa.     3600    IN      PTR     tinga.dom.loc.

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: 192.168.137.2
;; WHEN: Tue Oct  3 11:24:52 2017
;; MSG SIZE  rcvd: 71

Прямое преобразование DNS-имени контроллера домена:

drill controller.dom.loc

Пример успешного результата:

;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 36454
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; controller.dom.loc.  IN      A

;; ANSWER SECTION:
controller.dom.loc.     3600    IN      A       192.168.137.2

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: 192.168.137.2
;; WHEN: Tue Oct  3 11:14:12 2017
;; MSG SIZE  rcvd: 52

Обратное преобразование IP-адреса контроллера домена:

drill –x 192.168.137.2

Пример успешного результата:

;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 35328
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; 2.137.168.192.in-addr.arpa.  IN      PTR

;; ANSWER SECTION:
2.137.168.192.in-addr.arpa.     3600    IN      PTR     controller.dom.loc.

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: 192.168.137.2
;; WHEN: Tue Oct  3 11:19:54 2017
;; MSG SIZE  rcvd: 76

Настройка устройства Traffic Inspector Next Generation

Настройка DNS-параметров устройства Traffic Inspector Next Generation

Пройдите в раздел Система -> Настройки -> Общие настройки.

  • В поле Имя хоста укажите полное DNS-имя устройства TING.
  • В поле Домен укажите полное DNS-имя домена.
  • В поле DNS-серверы, укажите IP-адрес доменного DNS-сервера. В нашем примере, это IP-адрес 192.168.137.2.
  • В поле Настройки DNS-сервера, установите флаг напротив опции Не используйте перенаправляющий DNS-сервер или DNS-преобразователь в качестве DNS-сервера для межсетевого экрана
_images/dns_settings1.png

Проверка DNS-параметров устройства Traffic Inspector Next Generation

Подключитесь к устройству TING с помощью SSH-клиента Putty.

Выполните команду:

cat /etc/resolv.conf

В выводе вы должны увидеть:

domain dom.loc
nameserver 192.168.137.2

Настройка сетевого времени

Настройка времени на устройстве производится в рамках работы мастера первоначальной настройки, который доступен в разделе Система -> Мастер. Также, настройки времени доступны в разделе Службы -> Сетевое время -> Общие настройки. В поле Серверы времени укажите ваш предпочитаемый сервер времени, например, time.bakulev.ru.


Настройка LDAP-коннектора

Для успешного подключения к базе пользователей Active Directory нужно настроить параметры подключения.

Пройдите в раздел Система -> Доступ -> Серверы, в правом верхнем углу нажмите на кнопку Добавить сервер и задайте следующие настройки:

   
Описательное имя LDAP connector
Тип LDAP
Имя хоста или IP-адрес 192.168.137.2
Значение порта 389
Транспортный протокол TCP
Версия протокола 3
Привязать параметры доступа Уникальное имя пользователя: имя доменной учетной записи с правами чтения из домена; Пароль: пароль для учетной записи
Область поиска Уровень: единичный; База поиска: DC = dom, DC = loc (наш домен имеет DNS-имя dom.loc)
Контейнеры для аутентификации Выберите контейнеры, в которых располагаются доменные учетные записи (например, CN=Users,DC=dom,DC=loc)
Начальный шаблон Microsoft AD
Атрибут присвоения имени пользователю samAccountName

Включение веб-прокси и выключение механизмов перехвата HTTP/HTTPS

В разделе Службы -> Веб-прокси -> Администрирование, на вкладке General Proxy Settings, установите флаг Включить прокси, если он еще не установлен.

_images/enable_proxy.png

В разделе Службы -> Веб-прокси -> Администрирование, на вкладке Forward Proxy, в меню General Forward Settings снимите флаги Включить прозрачный HTTP-прокси и Включить режим SSL, если они установлены.

_images/disable_interception.png

Примечание

Использование механизмов прозрачного HTTP-проксирования или перехвата / дешифровки SSL не совместимо ни с одним методом аутентификации. Чтобы использовать Kerberos-аутенитификацию, данные механизмы должны быть выключены.


В разделе Службы -> Веб-прокси -> Администрирование, на вкладке Forward Proxy, в меню Authentication Settings, в поле Метод аутентификации выберите ранее созданный LDAP-коннектор.

_images/enable_ldap_auth.png

Установка плагина для Kerberos-аутентификации на прокси

Пройдите в раздел Система -> Прошивка -> Обновления. На вкладке Плагины нажмите на кнопку + напротив плагина os-proxy-sso для его установки.

Плагин os-proxy-sso содержит часть веб-интерфейса, ответственного за настройки Kerberos для прокси Squid, и содержит скрипты, ответственные за генерацию конфигурационного файла для Kerberos.

_images/os_proxy_sso_plugin.png

После установки плагина os-proxy-sso, в разделе Службы -> Веб-прокси появляется подраздел Single Sign On.


Генерация конфигурационного файла Kerberos и загрузка хелпера для Squid

В разделе Службы -> Веб-прокси -> Single Sign On, на вкладке Общие настройки, установите флаг Включить Single Sign On.

В поле Реализация AD Kerberos выберите значение Windows 2008 with AES.

_images/kerberos_general_settings.png

При нажатии на кнопку Применить будут произведены следующие действия.

  • Происходит автогенерация конфигурационного файла для библиотеки Kerberos. В krb5.conf указывается общие параметры работы Kerberos-библиотеки, задается Kerberos-область, указывается IP-адрес KDC-сервера для области и прочее.
  • Модифицируется конфигурационный файл /usr/local/sbin/squid.conf для веб-сервера Squid. Теперь Squid будет дополнительно загружать хелпер Kerberos-аутентификации negotiate_kerberos_auth, позволяющий ему поддерживать механизм HTTP-аутентификации Negotiate и через него - Kerberos аутентификацию по HTTP.
  • Производится перезапуск веб-сервера Squid.

Проверка конфигурационного файла Kerberos и хелпера для Squid

Подключитесь к устройству TING по SSH c помощью клиента Putty.

Выполните команду:

cat /etc/krb5.conf

Вы должы увидеть, что были добавлены следующие строки:

[libdefaults]
                 default_realm = DOM.LOC
                 dns_lookup_kdc = no
                 dns_lookup_realm = no
                 ticket_lifetime = 24h
                 default_keytab_name = /usr/local/etc/squid/squid.keytab
                 default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
                 default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
                 permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
[realms]
                 DOM.LOC = {
                                 kdc = 192.168.137.2
                                 admin_server = 192.168.137.2
                                 default_domain = dom.loc
                 }
[domain_realm]
                 .dom.loc = DOM.LOC
                 dom.loc = DOM.LOC

Выполните команду:

cat /usr/local/etc/squid/pre-auth/20-negotiate.auth.conf

Вы должы увидеть вывод:

auth_param negotiate program /usr/local/libexec/squid/negotiate_kerberos_auth -d -i -s HTTP/tinga.dom.loc@DOM.LOC
auth_param negotiate keep_alive on
auth_param negotiate children 5

Выполните команду:

ps lax | grep negotiate_kerberos_auth

Вы должы увидеть запущенные процессы хелпера negotiate_kerberos_auth:

UID   PID  PPID CPU PRI NI    VSZ   RSS MWCHAN   STAT TT        TIME COMMAND
100 60833 46251   0  20  0  55744  8700 sbwait   I     -     0:00.02 (negotiate_kerberos_auth) -d -i -s HTTP/tinga.dom.loc@DOM.LOC (negotiate_kerberos_)
100 60867 46251   0  21  0  55744  8700 sbwait   I     -     0:00.02 (negotiate_kerberos_auth) -d -i -s HTTP/tinga.dom.loc@DOM.LOC (negotiate_kerberos_)
100 60979 46251   0  22  0  55744  8692 sbwait   I     -     0:00.02 (negotiate_kerberos_auth) -d -i -s HTTP/tinga.dom.loc@DOM.LOC (negotiate_kerberos_)
100 61257 46251   0  22  0  55744  8696 sbwait   I     -     0:00.02 (negotiate_kerberos_auth) -d -i -s HTTP/tinga.dom.loc@DOM.LOC (negotiate_kerberos_)
100 61480 46251   0  20  0  55744  8696 sbwait   I     -     0:00.02 (negotiate_kerberos_auth) -d -i -s HTTP/tinga.dom.loc@DOM.LOC (negotiate_kerberos_)

Создание принципалов в каталоге AD и генерация keytab-файла

Пройдите в раздел Службы -> Веб-прокси -> Single Sign On, на вкладку Аутентификация по протоколу Kerberos.

В поле Имя администратора AD, укажите имя учетной записи администратора домена.

В поле Пароль администратора AD, укажите пароль для учетной записи администратора домена. Нажмите на кнопку Создать keytab-файл.

_images/generate_keytab.png

В поле Результат, вы должны увидеть вывод утилиты msktutil, которая создает учетную запись для устройства TING в каталоге AD, прописывает необходимые Kerberos-принципалы / ключи в каталоге AD и создает keytab-файл на устройстве TING c теми же принципалами / ключами.


Проверка создания принципалов в каталоге AD и keytab-файла

Нажмите на кнопку Показать keytab-файл.

В поле Результат, Вы должны увидеть содержимое keytab-файла /usr/local/etc/squid/squid.keytab:

/usr/local/etc/squid/squid.keytab:

Vno  Type                     Principal                   Aliases
  4  arcfour-hmac-md5         [email protected]
  4  aes128-cts-hmac-sha1-96  [email protected]
  4  aes256-cts-hmac-sha1-96  [email protected]
  4  arcfour-hmac-md5         HTTP/[email protected]
  4  aes128-cts-hmac-sha1-96  HTTP/[email protected]
  4  aes256-cts-hmac-sha1-96  HTTP/[email protected]
  4  arcfour-hmac-md5         host/[email protected]
  4  aes128-cts-hmac-sha1-96  host/[email protected]
  4  aes256-cts-hmac-sha1-96  host/[email protected]
  4  arcfour-hmac-md5         host/[email protected]
  4  aes128-cts-hmac-sha1-96  host/[email protected]
  4  aes256-cts-hmac-sha1-96  host/[email protected]

На контроллере домена AD, через оснастку Пользователи и компьютеры Active Directory, в контейнере Computers, проверьте существование аккаунта для Вашего устройства TING. В нашем случае, созданный аккаунт называется TINGA-K.

Проверьте наличие принципалов (SPN) в аккануте. Для этого на контроллере домена AD выполните команду:

setspn -l TINGA-K

Вы должны увидеть следующий вывод:

Registered ServicePrincipalNames for CN=TINGA-K,CN=Computers,DC=dom,DC=loc:
        host/tinga.dom.loc
        HTTP/tinga.dom.loc

Настройка компьютера пользователя

На компьютере пользователя задайте явные настройки на прокси, аналогично тому, как показано на скриншоте:


_images/proxy_settings.png

Примечание

Важно указывать прокси как DNS-имя, а не как IP-адрес!


Проверка Kerberos-аутентификации на прокси

Проверьте возможность аутентификации с помощью Kerberos.

Пройдите в раздел Службы -> Веб-прокси -> Single Sign On, на вкладку Аутентификация по протоколу Kerberos.

Укажите имя и пароль существующего доменного пользователя и нажмите на кнопку Проверить вход через Kerberos.

В поле Результат, вы должны увидеть вывод аналогичный тому, который приведен ниже:

AF oRQwEqADCgEAoQsGCSqGSIb3EgECAg== khilchenko@DOM.LOC
BH quit command

Настройка прозрачной Kerberos-аутентификации на веб-прокси в домене Active Directory завершена.