Работа Squid с Active Directory. Kerberos-аутентификация. Права доступа на основе групп Active Directory.

Разберем как настроить связь Squid 3.5 c Active Directory через kerberos авторизацию, чтобы доступ в интернет предоставлялся только по доменным учетным записям, а так же возможность использования Active Directory групп для разграничения прав доступа в интернет.

 

 

Исходные данные:

  • Установленный на Ubuntu 14.04 Trusty Tahr (srv-squid-s) Squid 3.5
  • Домен контроллер SRV-DC1 (testzone.local) на базе Windows Server 2008 R2

 

Подготовка системы Ubuntu 14.04 Trusty Tahr (srv-squid-s)

Укажем корректное имя системы для работы с Active Directory. В файле (/etc/hostname) дописываем к имени системы название вашего домена (в моем случае я дописываю .testzone.local):

srv-squid-s.testzone.local

В файле (/etc/hosts) под записью «127.0.0.1 localhost» прописываем данные нашей системы:

192.168.1.5 srv-squid-s.testzone.local srv-squid-s

Для применения изменений перезагрузим систему:

sudo reboot

 

Синхронизация времени

Для нормальной работы с доменом Active Directory и прохождения Kerberos-аутентификации важно чтобы время на текущей системе (srv-squid-s) и контроллере домена (SRV-DC1) было синхронизировано.

 

Для синхронизации времени установим необходимые программы:

sudo apt-get install ntp ntpd -y

В файле конфигурации (/etc/ntp.conf) удалим указанные там по умолчанию серверы синхронизации:

#server 0.ubuntu.pool.ntp.org
#server 1.ubuntu.pool.ntp.org
#server 2.ubuntu.pool.ntp.org
#server 3.ubuntu.pool.ntp.org

и укажем контроллер домена по которому будем сверять время:

server SRV-DC1.testzone.local

 

Выполним немедленную синхронизацию времени с контроллером домена:

sudo /etc/init.d/ntp stop
sudo ntpdate SRV-DC1
sudo /etc/init.d/ntp start

 

Проверить синхронизацию времени можно командой:

sudo ntpq -p
when — время с последнего ответа сервера
pool — время опроса сервера
offset — разница времени в секундах.

 

Настройка Active Directory Windows Server 2008 R2 (SRV-DC1)

Теперь проведем подготовительные работы в AD чтобы наша система и Squid могли авторизоваться в ней успешно. В оснастке DNS, в Forward Lookup Zones добавьте A-запись для нашей системы где у нас стоит Squid

squid-ad-1

Обязательно при добавлении записи, отмечаем галочкой пункт: Create associated pointer (PTR) record

 

Создаем в домене учетную запись служебного пользователя для работы Squid (в моем случае учетная запись будет squid-s)

squid-ad-2 squid-ad-3

 

Теперь создадим специальный keytab-файл с помощью утилиты ktpass. В дальнейшем keytab-файл будет использоваться Squid для аутентификации пользователей в AD. Откроем командную строку от имени администратора и введем следующую команду (соблюдая регистр):

ktpass -princ HTTP/srv-squid.testzone.local@TESTZONE.LOCAL -mapuser squid-s -pass Aa1234567 -ptype KRB5_NT_PRINCIPAL -out C:\srv-squid.keytab

Ответ об успешном создании keytab-файла будет вида:

Targeting domain controller: SRV-DC1.testnone.local
Using legacy password setting method
Successfully mapped HTTP/srv-squid.testzone.local to squid-s.
Key created.
Output keytab to C:\srv-squid.keytab:
Keytab version: 0x502
keysize 80 HTTP/srv-squid.testzone.local@TESTZONE.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x17 (RC4-HMAC) keylength 16 (0x58705ad7aee5c92df1aa249430acad10)

Передаем сгенерированный keytab-файл на систему где развернут Squid любым доступным образом.

После того, как мы передали keytab-файл на систему со Squid, переместим его в папку с настройками Squid и ограничим к нему доступ.

sudo mv /home/admin/srv-squid.keytab /etc/squid/srv-squid.keytab

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

sudo chown proxy:proxy /etc/squid/srv-squid.keytab
sudo chmod 640 /etc/squid/srv-squid.keytab

Все готово для установки Kerberos, установим пакет krb5-user

sudo apt-get install krb5-user
Если в ходе установки появится запрос указать «Область по умолчанию для Kerberos«, то необходимо его указать в заглавном виде (прим. TESTZONE.LOCAL)

 

Перед конкурированием Kerberos создадим резервную копию файла конфигурации.

sudo cp /etc/krb5.conf /etc/krb5.conf.backup

Редактируем файл /etc/krb5.conf

sudo nano /etc/krb5.conf

и приводим его к виду:

[libdefaults]

default_realm = TESTZONE.LOCAL
ticket_lifetieme = 24h
dns_lookup_realm = false
dns_lookup_kdc = false
default_keytab_name = /etc/squid/srv-squid.keytab
forwardable = yes
clock_skew = 300

default_tgs_enctypes = des-cbc-crc rc4-hmac des-cbc-md5
default_tkt_enctypes = des-cbc-crc rc4-hmac des-cbc-md5
permitted_enctypes = des-cbc-crc rc4-hmac des-cbc-md5

[realms]

TESTZONE.LOCAL = {
kdc = srv-dc1.testzone.local
admin_server = srv-dc1.testzone.local
default_domain = TESTZONE.LOCAL
}

[domain_realm]

.testzone.local = TESTZONE.LOCAL
testzone.local = TESTZONE.LOCAL

 

Проверим работу Kerberos, для этого выполним команду

sudo kinit -kV -p HTTP/srv-squid.testzone.local

Если получен ответ вида представленного ниже, то все нормально, билет получен и можно двигаться дальше.

Using default cache: /tmp/krb5cc_0
Using principal: HTTP/srv-squid.testzone.local@TESTZONE.LOCAL
Authenticated to Kerberos v5

Удаляем полученный билет, он нам не нужен.

sudo kdestroy

Установим необходимую зависимость для работы Squid и AD

sudo apt-get install libsasl2-modules-gssapi-mit

Укажем Squid путь к нашему keytab-файлу, редактируем файл /etc/init.d/squid

sudo nano /etc/init.d/squid

находим строку:

DESC="Squid HTTP Proxy"

и ниже прописываем следующее:

KRB5_KTNAME=/etc/squid/srv-squid.keytab
export KRB5_KTNAME

 

Осталось выполнить конфигурацию самого Squid для работы с AD. Редактируем конфигурационный файл /etc/squid3/squid.conf

sudo nano /etc/squid/squid.conf

У меня вот такой получился итоговый вариант конфигурации Squid. Конфиг с комментариями , поэтому разобраться что там за что отвечает не должно составить труда.

##################################
# Настройка авторизации Kerberos #
##################################
# Параметры авторизации Squid в AD
auth_param negotiate program /usr/lib/squid/negotiate_kerberos_auth -s HTTP/srv-squid.testzone.local
auth_param negotiate children 50
auth_param negotiate keep_alive on
# Здесь задаются какие группы в AD будет использоваться при доступе в интернет для пользователей
external_acl_type S_SQUID_ADMINS_IP ttl=5 negative_ttl=5 %LOGIN /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -g S_SQUID_ADMINS_IP -D TESTZONE.LOCAL
external_acl_type S_SQUID_BLOCK_INET ttl=5 negative_ttl=5 %LOGIN /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -g S_SQUID_BLOCK_INET -D TESTZONE.LOCAL
external_acl_type S_SQUID_BLOCK_INET_WHITE ttl=5 negative_ttl=5 %LOGIN /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -g S_SQUID_BLOCK_INET_WHITE -D TESTZONE.LOCAL
######################################
# Обслуживаемые прокси-сервером сети #
######################################
# Правило указывающее доступ в интернет только через авторизацию Kerberos
acl auth proxy_auth REQUIRED
#################################################
# Правила какие порты разрешены прокси-сервером #
#################################################
# Порт SSL для подключений по HTTPS-протоколу
acl SSL_ports port 443
# Список портов, к которым разрешен доступ через прокси-сервер по протоколу HTTP
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
################################################################
# Пути к файлам запрещающих, разрешающих определенные действия #
################################################################
# Группа в AD на которую не распространяются запреты
acl S_SQUID_ADMINS_IP external S_SQUID_ADMINS_IP
# Группа в AD в которой запрещен интернет
acl S_SQUID_BLOCK_INET external S_SQUID_BLOCK_INET
# Группа в AD в которой запрещен интернет кроме Белого списка
acl S_SQUID_BLOCK_INET_WHITE external S_SQUID_BLOCK_INET_WHITE
# Путь к белому списку сайтов
acl WhiteList dstdomain "/etc/squid/WhiteList.txt"
# Путь к черному списку сайтов
acl BlackList dstdomain "/etc/squid/BlackList.txt"
#########################
# Параметры DNS записей #
#########################
# Список DNS серверов(IP адреса), которые будут использоваться вместо тех, что определены в /etc/resolv.conf файле
dns_nameservers 192.168.1.2
#########################################
# Правила ограничений доступа клиентов #
#########################################
# Запретить доступ к портам, отсутствующим в списке выше
http_access deny !Safe_ports
# Запретить метод CONNECT не на SSL-порт
http_access deny CONNECT !SSL_ports
# Разрешить только локальное управление кэшем
http_access allow localhost manager
http_access deny manager
# Не ограничивать локальный доступ с сервера
http_access allow localhost
# Доступ в интернет без ограничения доступа
http_access allow S_SQUID_ADMINS_IP
# Блокировать интернет всем кто в указанной ниже группе AD, кроме белого списка адресов
http_access deny S_SQUID_BLOCK_INET_WHITE !WhiteList
# Блокировать интернет всем кто в указанной ниже группе AD
http_access deny S_SQUID_BLOCK_INET
# Блокировать запрещенные сайты
http_access deny BlackList
# Правила разрешающего доступ в интернет только авторизованным пользователям AD
http_access allow auth
# Блокирует все, что не было разрешено выше
http_access deny all
################################################
# Правила подключений клиентов к прокси-серверу#
################################################
# Подключения через прозрачный порт
http_port 192.168.1.5:3128 intercept options=NO_SSLv3:NO_SSLv2
# Подключение через указания прокси-сервера на строне клиента
http_port 192.168.1.5:3130 options=NO_SSLv3:NO_SSLv2
# Подключение по HTTPS через прозрачный порт с параметрами подставки сертификата
https_port 192.168.1.5:3129 intercept ssl-bump options=ALL:NO_SSLv3:NO_SSLv2 connection-auth=off cert=/etc/squid/squidca.pem
# Принимаем сертификаты, даже если они не прошли проверку.
always_direct allow all
sslproxy_cert_error allow all
sslproxy_flags DONT_VERIFY_PEER
# Укажем список блокируемых ресурсов (в файле домены вида .domain.com) и правила блокировки их
acl blocked ssl::server_name "/etc/squid/BlackList.txt"
# Устанавливаем защищенное соединение и считываем заголовок HTTP
acl step1 at_step SslBump1
ssl_bump peek step1
# Закрываем соединение, если клиент заходит на ресурс указанные в blocked
ssl_bump terminate blocked
ssl_bump splice all
sslcrtd_program /usr/lib/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB
#########################################
# Дополнительные параметры конфигурации #
#########################################
# Путь для дискового кеширования
cache_dir aufs /var/spool/squid 20000 49 256
# Путь сохранения дампов аварийного завершения
coredump_dir /var/spool/squid
# Время жизни объектов для протоколов FTP и GOPHER
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
# Нулевое время жизни для динамического контента
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
# Время жизни по умолчанию
refresh_pattern . 0 20% 4320
maximum_object_size 61440 KB
minimum_object_size 3 KB
cache_swap_low 90
cache_swap_high 95
# Максимальный размер объекта, сохраняемого в оперативной памяти
maximum_object_size_in_memory 512 KB
memory_replacement_policy lru
logfile_rotate 4

 

 

Перезапускаем службу Squid, чтобы применилась конфигурация.

sudo service squid restart

На этом настройка полностью завершена. На пользовательских ПК в Свойствах обозревателя — Подключения — Настройка сети в поле Адрес указываем FQDN имя системы где у нас стоит Squid, в моем случае это srv-squid.testzone.local

squid-ad-4

Проверяем работу. Если на ПК вы авторизованны под доменной учетной записью, то интернет будет работать нормально. А если же вы на ПК не под доменной учетной записью, то при открытии любых страниц вам будет предложено ввести данные для доступа к сети интернет. К сожалению если попытаться ввести учетные данные доменного пользователя, то все равно доступа не будет к интернету… победить данный случай мне пока что не удалось.

Осталось только создать группы в AD которые мы указали в конфиге squid:

S_SQUID_ADMINS_IP - Доступ без ограничений
S_SQUID_BLOCK_INET - Запрет доступа в интернет
S_SQUID_BLOCK_INET_WHITE - Запрет доступа в интернет, кроме белого списка адресов

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

Так же проверить видит ли Squid пользователя в какой то определенной группе, можно выполнив команду

sudo /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -d -i -g S_SQUID_ADMINS_IP -D TESTZONE.LOCAL

и ввести имя пользователя AD. Если пользователь находится в данной группе то увидим в конце запроса ОК, если пользователя нет, то ERR

squid-ad-5

Убедились что все отрабатывает успешно. Система Squid с авторизацией AD работает успешно, можно пользоваться.

 

При работе в прозрачном (transparent) режиме, аутентификация пользователей невозможна! Подробнее: http://wiki.squid-cache.org/Features/Authentication#Authentication_in_interception_and_transparent_modes
 

ПОНРАВИЛАСЬ ИЛИ ОКАЗАЛАСЬ ПОЛЕЗНОЙ СТАТЬЯ, ПОБЛАГОДАРИ АВТОРА

БесполезноСлабоватоПриемлемоОтличноПревосходно (2 голос(ов), в среднем: 4,50 из 5)
Загрузка...

Всего комментариев: 22 Комментировать

  1. daniyar /

    Добрый день!
    Может подскажете, снес все и настроил все по мануалу билетик получает по команде проверки и группу проверяет показывает пользователя «ОК», но уже под доменной учеткой открываю страничку в бразере выходит окошко аутентификации, хотя у пользователя есть доступ. Как и у Вас ручной ввод ничего не дает, не принимает. целый день сижу уже два раза ставил на чистую систему. у меня squid 3.5.12 ubuntu последняя 16.04

    1. Жаконда / Автор записи

      Добрый день !
      Если билетик Squid получает и при проверки нахождения пользователя в группе AD вы получаете правильный ответ, то у вас все правильно настроено и Squid и модуль negotiate_kerberos_auth отрабатывает правильно ! Вероятней всего проблема в самом домен контроллере, проверками прогоните службы на ошибки.

      У меня была ситуация точно такая же как и у вас. Только у меня все работало прекрасно, но в один момент появились все аналогичные симптомы. Все так же проверки авторизации Squid были успешны, билет получался, пользователей видел в группе. Пробовал создать нового пользователя в AD и сделать по него новый keytab, не помогало. Решение оказалось простым, выяснилось что синхронизация между домен контроллерами была нарушена и не проходила. Исправили данную проблему и все заработало в нормальном режиме.

      Так что мой совет сейчас проверить свой домен контроллер, т.к. повторюсь у вас все настроено правильно если все проверки Squid успешны.

      P.S. мануал полностью рабочий и порядка 5 раз разворачивался и все работает. Так же может играть роль версий как самого Squid так и системы на которую он ставится.
      P.S.2 попробуйте пройти полностью по шагам как написано в статье, устанавливая версию Squid 3.5.19 на Ubuntu server 14.04, т.к. статья описывает использование именно этих версий.

  2. макс /

    Все настроил все работает кроме аутентификации пологину и паролю… В чем может быть причина?? Неохота все заново переделывать новый мануал искать…

    1. Жаконда / Автор записи

      Добрый день ! По логину и паролю и не будет работать в данном способе через Kerberos авторизацию. Для того чтобы работало по логину и паролю нужно делать все по этой инструкции

  3. Андрей /

    Здравствуйте! Вы пишете: «В оснастке DNS, в Forward Lookup Zones добавьте A-запись для нашей системы где у нас стоит Squid» а где эту оснастку найти стоит Server 2008 r2

  4. Андрей /

    Нашел, только не пойму откуда у вас взялся айпи 192.168.1.20

    1. Жаконда / Автор записи

      Это мой локальный IP адрес

  5. Андрей /

    Ничего не работает билетик не получает!

  6. Андрей /

    Может подскажите что не так делаю?

  7. Xxx /

    В dns вместо srv-squid ошибочно указан srv-squid-s.

  8. Александр /

    Спасибо за статью!
    Проверку при помощи /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -d -i -g S_SQUID_ADMINS_IP -D TESTZONE.LOCAL проходит. НО! при попытки авторизоваться в браузере, не принимает логин пароль, в лог высыпается
    ERROR: Negotiate Authentication validating user. Result: {result=BH, notes={message: received type 1 NTLM token; }}

    1. Жаконда / Автор записи

      Пожалуйста !
      И не примет, т.к. для того чтобы авторизация в браузере заработала, нужно использовать метод NCSA-авторизация

  9. Александр /

    А есть какой то другой метод связи с вами ? Делал все по этой статье и у меня браузер запрашивает логин\пароль

  10. Александр /

    Все мои коменты можно удалить. Всем советую ВНИМАТЕЛЬНО читать статью) И еще раз спасибо.

    1. Жаконда / Автор записи

      Рад что у вас в итоге все получилось 🙂

  11. DmitryDom /

    прописывать адрес прокси каждому ПК обязательно??? Вроде конфиг сделан с прозрачным прокси?

    1. Жаконда / Автор записи

      Да, обязательно ! В прозрачном режиме, аутентификация в AD Не будет проходить.

  12. Дима /

    Добрый день
    negotiate_kerberos_auth_test выдает ошибку spnego cannot find mechanisms to negotiate все остальные проверки ОК
    Что можно поправить?

  13. Игорь /

    Работать будет или нет?
    sudo iptables -t nat -A PREROUTING -s 10.5.5.0/24 -p tcp -m multiport —dports 80,8080 -j REDIRECT —to-ports 3130
    sudo iptables -t nat -A PREROUTING -s 10.5.5.0/24 -p tcp -m multiport —dports 443 -j REDIRECT —to-ports 3129

    1. Жаконда / Автор записи

      Ну если вы пытаетесь реализовать прозрачную аутентификацию с Kerberos-аутентификацией, то у вас ничего не получится.

  14. Евгений /

    С Праздниками!

    чет так и не взлетело в Centos 7 + 2008R2, делал по статье…

    проверки все проходит (тикет получает, в группах видит), а в браузере все равно выдает окно на ввод логин/пароль (ПК и юзер в домене, юзер входит на ПК под доменной учеткой)

    ЧЯДН? =) куда еще покопать?

    и еще если просветите может…. в статье на — (-) keytab генереиться с типом KRB5_NT_SRV_HST, а у Вас KRB5_NT_PRINCIPAL.

    в чем разница?

    1. Жаконда / Автор записи

      Спасибо! Взаимно!

      А прописали прокси-сервер на клиентских машинах ? (как в статье указано).

      При работе в прозрачном (transparent) режиме, аутентификация пользователей невозможна! Подробнее: http://wiki.squid-cache.org/Features/Authentication#Authentication_in_interception_and_transparent_modes

Оставить ответ Жаконда Отменить ответ

тринадцать + девятнадцать =

© IT-блог Жаконды All Rights Reserved.
Яндекс.Метрика