Работа 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
[stextbox id=’info’]when — время с последнего ответа сервера
pool — время опроса сервера
offset — разница времени в секундах.[/stextbox]
Настройка Active Directory Windows Server 2008 R2 (SRV-DC1)
Теперь проведем подготовительные работы в AD чтобы наша система и Squid могли авторизоваться в ней успешно. В оснастке DNS, в Forward Lookup Zones добавьте A-запись для нашей системы где у нас стоит Squid
[stextbox id=’warning’]Обязательно при добавлении записи, отмечаем галочкой пункт: Create associated pointer (PTR) record[/stextbox]
Создаем в домене учетную запись служебного пользователя для работы Squid (в моем случае учетная запись будет squid-s)
Теперь создадим специальный 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
[stextbox id=’warning’]Если в ходе установки появится запрос указать «Область по умолчанию для Kerberos«, то необходимо его указать в заглавном виде (прим. TESTZONE.LOCAL)[/stextbox]
Перед конкурированием 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
Проверяем работу. Если на ПК вы авторизованны под доменной учетной записью, то интернет будет работать нормально. А если же вы на ПК не под доменной учетной записью, то при открытии любых страниц вам будет предложено ввести данные для доступа к сети интернет. К сожалению если попытаться ввести учетные данные доменного пользователя, то все равно доступа не будет к интернету… победить данный случай мне пока что не удалось.
Осталось только создать группы в 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 работает успешно, можно пользоваться.
[stextbox id=’info’]При работе в прозрачном (transparent) режиме, аутентификация пользователей невозможна! Подробнее: http://wiki.squid-cache.org/Features/Authentication#Authentication_in_interception_and_transparent_modes[/stextbox]
ПОНРАВИЛАСЬ ИЛИ ОКАЗАЛАСЬ ПОЛЕЗНОЙ СТАТЬЯ, ПОДДЕРЖИ АВТОРА ДОНАТОМ
С Праздниками!
чет так и не взлетело в Centos 7 + 2008R2, делал по статье…
проверки все проходит (тикет получает, в группах видит), а в браузере все равно выдает окно на ввод логин/пароль (ПК и юзер в домене, юзер входит на ПК под доменной учеткой)
ЧЯДН? =) куда еще покопать?
и еще если просветите может…. в статье на — (-) keytab генереиться с типом KRB5_NT_SRV_HST, а у Вас KRB5_NT_PRINCIPAL.
в чем разница?
Спасибо! Взаимно!
А прописали прокси-сервер на клиентских машинах ? (как в статье указано).
Работать будет или нет?
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
Ну если вы пытаетесь реализовать прозрачную аутентификацию с Kerberos-аутентификацией, то у вас ничего не получится.
Добрый день
negotiate_kerberos_auth_test выдает ошибку spnego cannot find mechanisms to negotiate все остальные проверки ОК
Что можно поправить?
прописывать адрес прокси каждому ПК обязательно??? Вроде конфиг сделан с прозрачным прокси?
Да, обязательно ! В прозрачном режиме, аутентификация в AD Не будет проходить.
Все мои коменты можно удалить. Всем советую ВНИМАТЕЛЬНО читать статью) И еще раз спасибо.
Рад что у вас в итоге все получилось 🙂
А есть какой то другой метод связи с вами ? Делал все по этой статье и у меня браузер запрашивает логин\пароль
Спасибо за статью!
Проверку при помощи /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; }}
Пожалуйста !
И не примет, т.к. для того чтобы авторизация в браузере заработала, нужно использовать метод NCSA-авторизация
В dns вместо srv-squid ошибочно указан srv-squid-s.
Может подскажите что не так делаю?
Ничего не работает билетик не получает!
Нашел, только не пойму откуда у вас взялся айпи 192.168.1.20
Это мой локальный IP адрес
Здравствуйте! Вы пишете: «В оснастке DNS, в Forward Lookup Zones добавьте A-запись для нашей системы где у нас стоит Squid» а где эту оснастку найти стоит Server 2008 r2
Все настроил все работает кроме аутентификации пологину и паролю… В чем может быть причина?? Неохота все заново переделывать новый мануал искать…
Добрый день ! По логину и паролю и не будет работать в данном способе через Kerberos авторизацию. Для того чтобы работало по логину и паролю нужно делать все по этой инструкции
Добрый день!
Может подскажете, снес все и настроил все по мануалу билетик получает по команде проверки и группу проверяет показывает пользователя «ОК», но уже под доменной учеткой открываю страничку в бразере выходит окошко аутентификации, хотя у пользователя есть доступ. Как и у Вас ручной ввод ничего не дает, не принимает. целый день сижу уже два раза ставил на чистую систему. у меня squid 3.5.12 ubuntu последняя 16.04
Добрый день !
Если билетик 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, т.к. статья описывает использование именно этих версий.