Настраиваем Squid для работы с Active Directory. Часть 2 — Kerberos-аутентификация

Продолжаем цикл статей об интеграции прокси-сервера Squid и Active Directory. Одним из наиболее важных вопросов является прозрачная аутентификация пользователей домена на прокси-сервере. В этой части мы расскажем, как настроить аутентификацию по протоколу Kerberos, которая позволит использовать единую точку входа, когда пользователь вводит логин и пароль один раз — при входе в систему.

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

Подготовка Active Directory

Перед тем, как настраивать поддержку Kerberos-аутентификации на роутере, необходимо выполнить ряд подготовительных действий в Active Directory. Прежде всего заведем служебного пользователя, в нашем случае squid3.

AD-Squid-KRB5-001.jpg

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

AD-Squid-KRB5-002.jpgТеперь создадим специальный keytab-файл, который содержит имя Kerberos-принципала (имя хоста, пользователя и домен) и ключ, созданный на основе пароля. В дальнейшем keytab-файл будет использоваться squid для аутентификации пользователей в AD. Откроем командную строку и введем следующую команду (соблюдая регистр):

ktpass -princ HTTP/srv-gw01.interface31.lab@INTERFACE31.LAB -mapuser squid3 -pass Pa$$word123 -ptype KRB5_NT_PRINCIPAL -out C:\123\squid3.keytab

На первый взгляд команда довольно сложная. Разберем ее подробнее, ключ -princ обозначает Kerberos-принципала и содержит FQDN имя роутера и область Kerberos, которая совпадает с именем домена, но записывается в верхнем регистре, -mapuser и -pass имя пользователя и пароль соответственно, -ptype — тип принципала и -out — имя и расположение keytab-файла.

Если все сделано правильно, то команда должна отработать без ошибок.

AD-Squid-KRB5-003.jpgЗатем следует передать сгенерированный keytab-файл на роутер любым доступным образом, например, через WinSCP в домашнюю директорию пользователя.

AD-Squid-KRB5-004.jpgНастройка поддержки Kerberos в Ubuntu Server / Debian

После того, как мы передали keytab-файл на роутер, его следует разместить в надежном месте и ограничить доступ. Понятно, что домашняя директория пользователя не самое лучшее для этого место. Так как работать с ним будет squid, то логично будет расположить keytab-файл в папке с настройками прокси-сервера.

mv ~/squid3.keytab /etc/squid3

Затем изменим владельца и установим ограниченные права на файл:

 

chown proxy:proxy /etc/squid3/squid3.keytab
chmod 640 /etc/squid3/squid3.keytab

Для поддержки Kerberos установим пакет krb5-user:

apt-get install krb5-user

При установке следует указать область Kerberos по умолчанию, введите имя вашего домена в верхнем регистре:

AD-Squid-KRB5-005.jpgТеперь откроем файл /etc/krb5.conf, он содержит очень много ненужных параметров, поэтому удаляем или комментируем все лишнее, у вас должно остаться только то, что будет приведено ниже.

Первой идет секция libdefaults, которая содержит параметры по умолчанию, а именно область Kerberos (опция создается автоматически) и keytab-файл:

[libdefaults]
          default_realm = INTERFACE31.LAB
          default_keytab_name = /etc/squid3/squid3.keytab
          default_tkt_enctypes = rc4-hmac des-cbc-crc des-cbc-md5
          default_tgs_enctypes = rc4-hmac des-cbc-crc des-cbc-md5

Следующая секция realms описывает области Kerberos, у нас она одна — INTERFACE31.LAB

[realms]
        INTERFACE31.LAB = {
              kdc = srv-dc01.interface31.lab
              kdc = srv-dc02.interface31.lab
              admin_server = srv-dc01.interface31.lab
              default_domain = interface31.lab
        }

Здесь все понятно, единственного пояснения требует опция admin_server, в ее качестве указываем контроллер домена, исполняющий FSMO-роль PDC.

Последняя секция сопоставляет домены с областями Kerberos:

[domain_realm]
          .interface31.lab = INTERFACE31.LAB
          intreface31.lab = INTERFACE31.LAB

Сохраняем файл. Теперь проверим работу Kerberos, для этого выполним команду:

kinit -kV -p HTTP/srv-gw01.interface31.lab

Если все сделано правильно, вы должны получить сообщение об успешной аутентификации.

AD-Squid-KRB5-006.jpgУдалим полученный билет командой:

kdestroy

Настройка Kerberos-аутентификации в Squid

Прежде всего следует «научить» squid работать с keytab-файлом, для этого создадим специальный файл настроек:

touch /etc/default/squid3

И внесем в него следующие строки:

KRB5_KTNAME=/etc/squid3/squid3.keytab
export KRB5_KTNAME

Откроем конфигурационный файл /etc/squid3/squid.conf, найдем три строки, начинающиеся с auth_param negotiate, раскомментируем и приведем их к следующему виду:

auth_param negotiate program /usr/lib/squid3/negotiate_kerberos_auth -d -s HTTP/srv-gw01.interface31.lab
auth_param negotiate children 20 startup=0 idle=1
auth_param negotiate keep_alive off

Ключ -d в первой строке указан для отладки, убедившись, что все работает как надо его следует убрать, чтобы избежать чрезмерного раздувания логов.

В секцию с элементами ACL добавим:

acl auth proxy_auth REQUIRED

Данный элемент будет соответствовать всем пользователям, успешно прошедшим Kerberos-аутентификацию. Ниже, в секции со списками доступа, строку

http_access allow localnet

меняем на:

http_access allow auth

сохраняем изменения, перезагружаем сервер.

 

На любом ПК войдем в систему под доменным пользователем и откроем любую страницу в браузере (не забываем, что прокси указываем не по IP-адресу, а по FQDN-имени), все должно работать.

 

 

Теперь зайдем на том же ПК локальным пользователем, вместо доступа к сети увидим приглашение ввести логин и пароль:

Также заглянем в /var/log/squid3/cache.log, сюда squid пишет отладочную информацию, в самом конце строки можно увидеть, кто именно прошел аутентификацию и получил доступ.

 

 

Убедившись, что все работает как надо, выключаем сбор отладочной информации, убрав ключ -d из строки в /etc/squid3/squid.conf.

auth_param negotiate program /usr/lib/squid3/negotiate_kerberos_auth  -s HTTP/srv-gw01.interface31.lab

Как видим, настроить Kerberos-аутентификацию достаточно просто. В следующих материалах мы разберем, как обеспечить автоматическое распространение настроек прокси и авторизацию на основе доменных групп безопасности.

 

#############

squid.conf

 

auth_param negotiate program /usr/lib/squid3/negotiate_kerb_auth -s HTTP/gw.swat.local
auth_param negotiate children 20 startup=0 idle=1
auth_param negotiate keep_alive on

 

acl auth proxy_auth REQUIRE
acl localnet src 192.168.35.0/24
acl manager proto cache_object
acl localhost src 127.0.0.1/32 ::1
#acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1

 

acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT

 

 

http_access allow auth
http_access allow localnet
http_access allow localhost
http_access deny all

http_port 192.168.35.240:3128
http_port 127.0.0.1:3128

 

cache_mem 64 MB
maximum_object_size_in_memory 512 KB

cache_dir ufs /var/spool/squid3 2048 16 256

maximum_object_size 4 MB

 

access_log /var/log/squid3/access.log squid
logfile_rotate 31