Настройка squid squidguard ssl active directory ubuntu server
Обновлено: 04.07.2024
Разберем как настроить связь 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):
192.168.1.5 srv - squid - s . testzone . local srv - squid - sДля применения изменений перезагрузим систему:
Синхронизация времени
Для нормальной работы с доменом Active Directory и прохождения Kerberos-аутентификации важно чтобы время на текущей системе (srv-squid-s) и контроллере домена (SRV-DC1) было синхронизировано.
Для синхронизации времени установим необходимые программы:
В файле конфигурации (/etc/ntp.conf) удалим указанные там по умолчанию серверы синхронизации:
и укажем контроллер домена по которому будем сверять время:
Выполним немедленную синхронизацию времени с контроллером домена:
Проверить синхронизацию времени можно командой:
Настройка Active Directory Windows Server 2008 R2 (SRV-DC1)
Теперь проведем подготовительные работы в AD чтобы наша система и Squid могли авторизоваться в ней успешно. В оснастке DNS, в Forward Lookup Zones добавьте A-запись для нашей системы где у нас стоит Squid
Создаем в домене учетную запись служебного пользователя для работы Squid (в моем случае учетная запись будет squid-s)
Теперь создадим специальный keytab-файл с помощью утилиты ktpass. В дальнейшем keytab-файл будет использоваться Squid для аутентификации пользователей в AD. Откроем командную строку от имени администратора и введем следующую команду (соблюдая регистр):
Ответ об успешном создании keytab-файла будет вида:
Targeting domain controller : SRV - DC1 . testnone . localПередаем сгенерированный 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Все готово для установки Kerberos, установим пакет krb5-user
Перед конкурированием Kerberos создадим резервную копию файла конфигурации.
Редактируем файл /etc/krb5.conf
и приводим его к виду:
default_keytab_name = / etc / squid / srv - squid . keytab 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Проверим работу Kerberos, для этого выполним команду
Если получен ответ вида представленного ниже, то все нормально, билет получен и можно двигаться дальше.
Удаляем полученный билет, он нам не нужен.
Установим необходимую зависимость для работы Squid и AD
sudo apt - get install libsasl2 - modules - gssapi - mitУкажем Squid путь к нашему keytab-файлу, редактируем файл /etc/init.d/squid
и ниже прописываем следующее:
Осталось выполнить конфигурацию самого Squid для работы с AD. Редактируем конфигурационный файл /etc/squid3/squid.conf
У меня вот такой получился итоговый вариант конфигурации Squid. Конфиг с комментариями , поэтому разобраться что там за что отвечает не должно составить труда.
external_acl_type S_SQUID_ADMINS_IP ttl = 5 & nbsp ; 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 acl S_SQUID_BLOCK_INET external S_SQUID_BLOCK_INET acl S_SQUID_BLOCK_INET_WHITE external S_SQUID_BLOCK_INET_WHITE acl blocked ssl :: server _ name "/etc/squid/BlackList.txt" sslcrtd_program / usr / lib / squid / ssl_crtd - s / var / lib / ssl_db - M 4MBПерезапускаем службу Squid, чтобы применилась конфигурация.
Осталось только создать группы в AD которые мы указали в конфиге squid:
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 работает успешно, можно пользоваться.
Понравилась или оказалась полезной статья, поблагодари автора
(2 голос(ов), в среднем: 4,50 из 5)Всего комментариев: 22 Комментировать
Добрый день !
Если билетик 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, т.к. статья описывает использование именно этих версий.
Добрый день ! По логину и паролю и не будет работать в данном способе через Kerberos авторизацию. Для того чтобы работало по логину и паролю нужно делать все по этой инструкции
Данная статья не рассматривает и не коснется установки UBUNTU. Начнем с того момента, когда вы ее уже поставили.
Начнем
Для начала несколько вводных:
1. Обновим сервер
2. Начнем собирать наш новый прокси сервер.
Обновляемся еще раз.
Установим необходимые для установки пакеты:
При желании можно создать отдельную папку для сбоки прокси из исходников:
Скачиваем все необходимое для SQUID
В случае если появится ошибка о нехватке прав, накидываем их на скачанный файл и повторяем скачивание:
Переходим в папку с исходниками
Открываем файл, в котором укажем что необходимо установить и SSL
Для этого в разделе с устанавливаемыми модулями добавим сроки
Начинаем собирать DEB пакет, процесс долгий
Идем к собранным пакетам, на уровень повыше
Начинаем ставить пакет, установка завершится с ошибкой
Начинаем ставить пакет, установка завершится нормально
Проверяем версию установленного SQUID и проверим наличие упоминаний SSL
3. Добавление возможности авторизации пользователей домена и ограничение доступа по группам. Используем Kerberos.
Для начала на контроллере домена сгенерим keytab, с помощью которого наш сервер будет авторизовываться в AD.
Копируем файл на UBUNTU и копируем его в папку /etc/squid
Выдаем права для доступа к файлу демону proxy
Ставим Kerberos, при установке указываем наш домен заглавными буквами.
Очищаем дефолтную конфигурацию
Открываем файл конфигурации и исправляем его
Выполним проверку авторизации сервера в AD
Удалим выданный ключ
Если на этом этапе ошибок нет, переходим дальше к подмене сертификатов.
4. Подмена сертификатов
Создадим сертификат для установки его на компьютеры пользователей (корневой)
Генерируем файл параметров
Настроим права на использование файла SSL-сертификата и файла параметров
Создаем каталог для базы данных сертификатов и инициализируем базу данных
5. Файл конфигурации SQUID
Очистим файл от дефолтной конфигурации
Вставим в него следующее содержимое
Создадим файлы черного и белого списков
6. Дополнения
Задача : хочу чтобы пользователь авторизовывался на squid через AD с целью удобного мониторинга и составления в последствии отчета.
Цель заметки: Удобнее всего управлять разграничение доступа в сеть интернет централизовано. А централизовано — это управление через группы Active Directory, плюс к этому посредством GPO будет происходит четкое нацеливание создаваемых политик, что избавит Вас как системного администратора от беготни по рабочим местам. Но все выше сказанное справедливо если у Вас в локальной сети используется Active Directory и рабочие станции на базе Windows.
- На Ubuntu 14.04.5 Trusty Server amd64 Поставить SQUID(CPU = 2,HDD = 50, RAM = 2)
- Поднять домен (внутри создана учетная запись: squid@polygon.local, pass: Aa1234567)
- Настроить авторизацию Ubuntu Trusty системы через kerberos билет в домене.
- Поднять домен контроллер на базе Windows Server 2012 R2 Std
Итак развернув Ubuntu Trusty с необходимыми характеристиками и установив squid по ранее опубликованной заметке я сразу же после успешного завершения сохранил к себе в облачное хранилище OwnCloud на HP MicroServer Gen 8 все Deb файлы дабы не зависеть от прихотей разработчиков и владельца репозитария.
Точнее это пошаговая заметка с разборов всех нюансов которые у меня возникли.
Шаг №1: подготавливаю систему
$ sudo rm -Rf /var/lib/apt/lists/
$ sudo apt-get update && sudo apt-get upgrade -y
$ sudo apt-get install linux-generic-lts-xenial linux-image-generic-lts-xenial -y
$ sudo /etc/init.d/apparmor stop
$ sudo /etc/init.d/apparmor teardown
$ sudo update-rc.d -f apparmor remove
$ sudo apt-get remove apparmor -y
$ sudo rm -Rf /etc/apparmor /etc/apparmor.d/
$ sudo nano /etc/default/apport
$ sudo nano /etc/hosts
10.10.10.11 srv-squid.polygon.local srv-squid
10.10.10.2 srv-dc.polygon.local srv-dc
$ sudo nano /etc/hostname
$ sudo locale-gen ru_RU
$ sudo locale-gen ru_RU.UTF8
$ sudo dpkg-reconfigure locales
$ sudo nano /etc/profile
Теперь отредактирую файл /etc/locale.alias:
$ sudo nano +67 /etc/locale.alias
вместо: russian ru_RU.ISO-8859-5
изменяю на: russian ru_RU.UTF-8
По окончании изменений не забываем сохранить внесенные изменения в конфигурационный файл.
$ sudo rm /etc/localtime
$ sudo ln -s /usr/share/zoneinfo/Europe/Moscow /etc/localtime
$ sudo apt-get install ntp ntpdate -y
$ sudo nano /etc/ntp.conf
$ sudo service ntp restart
Mon Jul 10 07:28:07 MSK 2017
Затем перезагружаю систему:
14.04.1-Ubuntu SMP Mon Jun 26 18:10:19 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.5 LTS
Шаг №2 → Устанавливаю SQUID из deb пакетов взятых из собственного хранилища OwnCloud. Автор своего сайта свернул проект где ранее они находились да и к тому же по заметке где я собирал их вышли новые версии пакетов, а старые были удалены. Так что она тоже не удел, ее нужно перерабатывать. Всегда нужно надеяться только на себя.
$ scp -P 2222 Dropbox/tips_db_home/tips_nemdom/tips_squid_trusty/*.deb ekzorchik@100.70.90.82:/home/ekzorchik
$ ssh -l ekzorchik 100.70.90.82 -p 2222
$ sudo apt-get -y install devscripts build-essential fakeroot debhelper dh-autoreconf cdbs
$ sudo apt-get -y build-dep libecap
$ sudo apt-get -y build-dep squid3
$ sudo apt-get -y --purge remove libecap2-dev libecap2
$ sudo dpkg -i libecap3_1.0.1-3_amd64.deb libecap3-dev_1.0.1-3_amd64.deb
$ sudo dpkg -i squid-common_3.5.19-1_all.deb squid_3.5.19-1_amd64.deb squidclient_3.5.19-1_amd64.deb squid-dbg_3.5.19-1_amd64.deb squid-purge_3.5.19-1_amd64.deb squid-cgi_3.5.19-1_amd64.deb
$ sudo apt-get install -f -y
$ squid -v | head -n 2
Squid Cache: Version 3.5.19
Service Name: squid
$ sudo cp /etc/squid/squid.conf /etc/squid/squid.conf.backup
Теперь создаю сертификат текущего сервера с которым будет работать SQUID:
$ sudo mkdir /etc/squid/ssl
ekzorchik@srv-squid:/etc/squid/ssl$ sudo openssl req -new -newkey rsa:2048 -days 3650 -nodes -x509 -keyout squidca.pem -out squidca.pem
Common Name (e.g. server FQDN or YOUR name) []: srv-squid.polygon.local
ekzorchik@srv-squid:/etc/squid/ssl$ sudo chmod 400 squidca.pem
ekzorchik@srv-squid:/etc/squid/ssl$ cd
Шаг №3 → Устанавливаю пакет Kerberos в систему Ubuntu (Trusty)
Далее нужно получить для данной системы kerberos билет, как же это сделать смотрите ниже или что мне пришлось сделать, чтобы удовлетворить свое желание выполнив поставленную данной заметкой задачу.
$ sudo apt-get install krb5-user -y
Kerberos 5 version 1.12
$ sudo cp /etc/krb5.conf /etc/krb5.conf.backup
$ sudo bash -c "cat > /etc/krb5.conf"
$ sudo nano -Y sh /etc/krb5.conf
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
Win + X → Control Panel — Administrative Tools — DNS, Forward Lookup Zones — polygon.local
Шаг №6: Создаю на домен контроллере keytab файл аутентификации
Cоздаю в домене AD (srv-dc.polygon.local) служебную учетную запись пользователя (squid@polygon.local) и пароль Aa1234567 и предопределяю для нее следующие настройки:
srv-dc.polygon.local — Start — Control Panel — Administrative Tools — Active Directory Users and Computers — нахожу созданную учетную запись squid и открыв ее Properties (Свойства) — вкладка Account:
- User cannot change password: отмечаю галочкой
- Password never expires: отмечаю галочкой
А после создаю группы посредством которых будет идти управлением доступ к сети интернет:
- SQUID_ADMINS_IP → доступ в интернет без ограничений доступа
- SQUID_BLOCK_INET_WHITE → блокировать интернет всем кто в указанной ниже группе Active Directory, кроме белого списка адресов
,затем генерирую на контроллере домена для этой учетной записи keytab-файл, который затем скопирую на разворачиваемый прокси сервер (через pscp,winscp и т.д, главное чтобы было безопасно) где буду использовать его для аутентификации Kerberos на постоянной основе.
Win + X → Command Prompt (Admin)
C:\Windows\system32>mkdir c:\keytab
( -princ → Для какого компьютера настроить аутентификацию)
Targeting domain controller: SRV-dc.polygon.local
Using legacy password setting method
Output keytab to c:\keytab\srv-squid.keytab:
Keytab version: 0x502
vno 8 etype 0x1 (DES-CBC-CRC) keylength 8 (0x61c8bcbf732f8920)
vno 8 etype 0x3 (DES-CBC-MD5) keylength 8 (0x61c8bcbf732f8920)
vno 8 etype 0x17 (RC4-HMAC) keylength 16 (0x58705ad7aee5c92df1aa249430acad10)
vno 8 etype 0x12 (AES256-SHA1) keylength 32 (0xc70e504f9a07c932b311d28aff194326
- -princ — имя сервиса и принципала;
- -mapuser — аккаунт принципала;
- -crypto — используемый алгоритм шифрования;
- -pass — пароль к аккаунту принципала;
- -ptype — тип запроса от принципала;
- -out — файл для вывода кейтаба.
затем нужно полученный файл squid.keytab передать на систему которая является шлюзом (на srv-squid.polygon.local) любым способом, к примеру через клиент putty, pscp, winscp
Шаг №7 → Копирую переданный keytab файл в дефолтную директорию и с правильным именем. (читайте документацию выше на этот счет)
$ sudo mv srv-squid.keytab /etc/squid/
$ sudo chown proxy:proxy /etc/squid/srv-squid.keytab
$ sudo chmod 640 /etc/squid/srv-squid.keytab
$ sudo klist -k /etc/squid/srv-squid.keytab
Keytab name: FILE:/etc/squid/srv-squid.keytab
На заметку: советую сохранить где-нибудь в системе на всякий случай его копию
Шаг №8 → Проверяем возможность аутентификации в AD с помощью переданного с домен контроллера keytab файла. Сначала выполняем команду, которая должна отработать без ошибок:
Using default cache: /tmp/krb5cc_0
Authenticated to Kerberos v5
Ticket cache: FILE:/tmp/krb5cc_0
Valid starting Expires Service principal
07/10/2017 10:31:45 07/10/2017 20:31:45 krbtgt/POLYGON.LOCAL@POLYGON.LOCAL
renew until 07/11/2017 10:31:45
Шаг №9 → Устанавливаю необходимую зависимость для работы squid & Active Directory:
$ sudo apt-get install libsasl2-modules-gssapi-mit libsasl2-modules -y
Для того чтобы сквид знал, какой кейтаб использовать, ему нужно указать, где он лежит.
$ sudo nano /etc/init.d/squid
DESC="Squid HTTP Proxy"
Шаг №10 → Теперь нужно настроить конфигурационный файл squid на связь с доменом.
$ sudo apt-get install ldap-utils -y
$ sudo bash -c "cat > /etc/squid/squid.conf"
$ sudo nano /etc/squid/WhiteList.txt
$ sudo nano /etc/squid/BlackList.txt
$ sudo nano /etc/squid/squid.conf
auth_param negotiate children 50
auth_param negotiate keep_alive on
external_acl_type B_SQUID_ADMINS_IP ttl=5 negative_ttl=5 %LOGIN
/usr/lib/squid3/ext_kerberos_ldap_group_acl -a -g SQUID_ADMINS_IP -D
polygon.local
external_acl_type B_SQUID_BLOCK_INET_WHITE ttl=5 negative_ttl=5 %LOGIN
/usr/lib/squid3/ext_kerberos_ldap_group_acl -a -g
SQUID_BLOCK_INET_WHITE -D polygon.local
acl auth proxy_auth REQUIRED
acl SSL_ports port 443
acl CONNECT method CONNECT
acl SQUID_ADMINS_IP external SQUID_ADMINS_IP
acl SQUID_BLOCK_INET_WHITE external SQUID_BLOCK_INET_WHITE
acl WhiteList dstdomain "/etc/squid/WhiteList.txt"
acl BlackList dstdomain "/etc/squid/BlackList.txt"
always_direct allow all
sslproxy_cert_error allow all
acl blocked ssl::server_name "/etc/squid/BlackList.txt"
acl step1 at_step SslBump1
ssl_bump peek step1
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
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
maximum_object_size_in_memory 512 KB
После не забываем сохранить внесенные изменения.
Далее обязательно нужно проверить созданный и наполненный конфигурационный файл squid.conf на ошибки:
$ sudo squid -k check
$ sudo squid -k parse
вывод говорит, что ошибок нет, но не лишним будет запустить squid в режиме отладки и убедиться уже точно.
$ sudo squid -d info
2016/10/30 10:00:56| Squid is already running! Process ID 19068
$ sudo service squid start
$ sudo /etc/init.d/squid status
* squid is running
$ sudo netstat -tulpn | grep squid
tcp 0 0 10.10.10.11:3128 0.0.0.0:* LISTEN 2449/(squid-1)
tcp 0 0 10.10.10.11:3129 0.0.0.0:* LISTEN 2449/(squid-1)
tcp 0 0 10.10.10.11:3130 0.0.0.0:* LISTEN 2449/(squid-1)
udp 0 0 0.0.0.0:36464 0.0.0.0:* 2449/(squid-1)
udp6 0 0 . 51705 . * 2449/(squid-1)
Если запустилось то значит аутентификация Kerberos проходит успешно.
На заметку: Советую раздел /var/spool или указать отличный от системного раздела раздел для кеширования на другом диске и использовать LVM если вдруг чего понадобиться расширить.
На заметку: если меняется конфиг то service squid restart , если добавляются сайты в список то service squid reload
На заметку: Если у пользователя прописан адрес прокси сервера srv-squid.polygon.local:3130 но он не состоит ни в каких группах то на него распространяется правило BlackList.txt которое блокирует доступ к тем сайтам которые там указаны.
Теперь протестирую работу данного прокси сервера , к примеру у меня есть рабочая станция под управлением Windows 7 SP1 Корпоративная, она в домене.
Тестовая учетная запись: alektest, добавлена в группу: SQUID_BLOCK_INET_WHITE
Либо через GPO либо локально прописываю настройки прокси сервера в свойства обозревателя:
Пуск — Панель управления — Просмотр: Категория (Мелкие значки) — Свойства обозревателя — вкладка Подключения — Настройка сети:
- Использовать прокси-сервер для локальных подключений: отмечаем галочкой
- Адрес: srv-squid.polygon.local
- Порт: 3130
- Не использовать прокси-сервер для локальных адресов: отмечаем галочкой
После чего на рабочей станции нужно сделать Logoff & Logon и пойдет интернет, как и было задумано в данной заметке, которая была расписана во всех шагах, но только интернет будет работать для списка WhiteList, либо же если в доменную группу не добавлять, а прописать настройки прокси, то интернет будет для всего за исключением списка BlackList
Чтобы проверить, а сам сервис SQUID видит доменную группу и пользователя в ней:
$ sudo /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -d -i -g SQUID_BLOCK_INET_WHITE -D POLYGON.LOCAL
kerberos_ldap_group.cc(278): pid=3332 :2017/07/10 13:21:53| kerberos_ldap_group: INFO: Starting version 1.3.1sq
support_group.cc(382): pid=3332 :2017/07/10 13:21:53| kerberos_ldap_group: INFO: Group list SQUID_BLOCK_INET_WHITE
support_group.cc(447): pid=3332 :2017/07/10 13:21:53| kerberos_ldap_group: INFO: Group SQUID_BLOCK_INET_WHITE Domain NULL
support_netbios.cc(83): pid=3332 :2017/07/10 13:21:53| kerberos_ldap_group: DEBUG: Netbios list NULL
support_netbios.cc(87): pid=3332 :2017/07/10 13:21:53| kerberos_ldap_group: DEBUG: No netbios names defined.
support_lserver.cc(82): pid=3332 :2017/07/10 13:21:53| kerberos_ldap_group: DEBUG: ldap server list NULL
support_lserver.cc(86): pid=3332 :2017/07/10 13:21:53| kerberos_ldap_group: DEBUG: No ldap servers defined.
Alektest → вводим доменного пользователя
support_ldap.cc(1390): pid=3332 :2017/07/10 13:21:56| kerberos_ldap_group: DEBUG: Unbind ldap server
support_member.cc(125): pid=3332 :2017/07/10 13:21:56| kerberos_ldap_group: INFO: User alektest is member of group@domain SQUID_BLOCK_INET_WHITE@NULL
kerberos_ldap_group.cc(408): pid=3332 :2017/07/10 13:21:56| kerberos_ldap_group: DEBUG: OK
Как видно из сокращенного вывода статус равен OK значит все так и есть как есть в группе на контроллере домена оснастки Active Directory Users and Computers.
Далее если пользователь ни куда не добавлен но у него в настройках свойства обозревателя прописана прокся с портом, к нему лишь будут применима политика BlackList.txt.
Проверяем работу. Если на ПК вы авторизованны под доменной учетной записью, то интернет будет работать нормально. А если же вы на ПК не под доменной учетной записью, то при открытии любых страниц вам будет предложено ввести данные для доступа к сети интернет. К сожалению если попытаться ввести учетные данные доменного пользователя, то все равно доступа не будет к интернету. А может так и должно быть, что только те кто в домене и при использовании строки: acl auth proxy_auth REQUIRED должны быть идентифицированы. Если для всех то acl localnet src 10.10.10.0/24
На заметку: в поле прокси на ПК пользователя обязательно нужно указывать FQDN имя, если указать IP адрес то появляется окно где нужно ввести логин и пароль и так до бесконечности.
Заметка работоспособна. На этом всё, с уважением автор блога Олло Александр aka ekzorchik.
Настраиваем Squid для работы с Active Directory. Часть 1 - базовые настройки
В процессе подготовки данного материала мы не планировали отдельно останавливаться на подготовке сервера, намереваясь использовать для этого уже существующий материал: Ubuntu Server. Настраиваем роутер NAT + DHCP + Squid3. Однако, когда количество уточнений и отличий стало превышать разумные пределы, мы решили посвятить этому вопросу отдельную статью. В тоже время мы предполагаем, что читатель знаком с вышеуказанным материалом и поэтому не будем объяснять подробно многие используемые нами настройки и не будем останавливаться на второстепенных деталях.
Особенности интеграции с Active Directory
В чем смысл интеграции прокси-сервера Squid в Active Directory? Скажем сразу, что если ваша основная цель - просто раздать интернет всем и без ограничений, ну разве что закрыв социальные сети, то дальше можно не читать, уже описанная нами конфигурация полностью удовлетворит ваши потребности. Основное преимущество интеграции роутера в Active Directory - это использование единой точки аутентификации и управление доступом к сети интернет на базе уже существующих в домене учетных записей и групп безопасности.
Отсюда следуют некоторые особенности. Так прозрачный режим не поддерживает аутентификацию и от него придется отказаться, указывая настройки прокси непосредственно в настройках браузера. Этот процесс несложно автоматизировать при помощи DHCP-сервера и протокола WPAD.
В качестве DNS-серверов, в том числе и на роутере, должны обязательно указываться только доменные DNS, по умолчанию DNS-сервером является каждый контроллер домена. По этой причине роутер не должен иметь роли DNS-сервера. Также, для обеспечения интеграции с AD, роль DHCP-сервера также следует передать Windows Server, обычно на один или несколько контроллеров домена.
Теперь подходим к тому, ради чего все это затевалось. Аутентификация по доменным учетным записям позволяет использовать единую точку входа (SSO, Single Sign-On), когда пользователь вводит логин и пароль один раз - при входе в систему. Это достигается применением протокола Kerberos, который является способом аутентификации в AD по умолчанию. В отличии от авторов иных руководств, мы не видим смысла настраивать NTLM или Basic-аутентификацию, в первую очередь по соображениям безопасности. Тем более Kerberos поддерживают все современные операционные системы.
Следующим шагом является авторизация на основе существующих групп безопасности, это особенно актуально при переходе с Forefront TMG или ISA Server. Это позволяет один раз настроив Linux-сервер дальнейшее управление доступом осуществлять привычным способом - через группы Active Directory, что позволяет снизить порог вхождения для администраторов.
Так как Active Directory имеет более сложную структуру и большее количество "действующих лиц", то чтобы вы не запутались в используемых нами адресах и именах хостов мы подготовили небольшую схему:
В наших примерах будет использоваться домен Active Directory с FQDN именем interface31.lab, за который отвечают два контроллера домена SRV-DC01 и SRV-DC02 с адресами 192.168.31.101 и 102 соответственно. Оба контроллера реализованы на базе Windows Server 2012 R2.
Роутер выполнен на базе Ubuntu Server 14.04 (Debian 7/8) и имеет имя SRV-GW01 с адресом 192.168.31.100. Также в сети имеется группа серверов со статическими адресами 192.168.31.103-105 и клиентские ПК, адреса которым выдаются DHCP сервером из диапазона 192.168.31.111-199.
Настройка сети
Сеть настраивается традиционным образом, посредством правки конфигурационного файла /etc/network/interfaces. Примем что внешней сети соответствует интерфейс eth0, а внутренней eth1. В результате настройки у нас должно получиться примерно следующее:
Обратите внимание, что несмотря на то, что в настройках внешнего интерфейса использован внешний адрес и шлюз, адреса DNS-серверов указаны внутренние. Также указана опция dns-search, которая определяет домен для разрешения не FQDN-имен. Это означает, что к каждому короткому имени будет автоматически добавлен указанный домен, например, srv-dc01 будет дополнено до srv-dc01.interface31.lab.
Если вас смущает указание внутренних DNS в настройках внешней сетевой карты, то можете перенести эти строки в секцию eth1, на работу сервера это не повлияет.
DNS-сервера провайдера или публичные DNS следует указать в разделе Серверы пересылки внутреннего DNS-сервера на любом из контроллеров домена.
Если вы получаете сетевые настройки от провайдера по DHCP, то для использования внутренних серверов имен, вместо DNS провайдера секция eth0 должна иметь вид:
Таким образом явно указанные настройки перекроют полученные автоматом от провайдера.
Сохраняем содержимое файла, перезагружаемся. Проверяем наличие интернета на сервере и разрешение имен. Например, выполните команду:
Ответить вам должен первый указанный доменный сервер имен, в нашем случае 192.168.33.101 и выдать полное FQDN-имя хоста и его IP-адрес.
После чего проверьте разрешение внешних имен:
Вы также должны получить ответ от внутреннего сервера. На этом настройку сети можно считать законченной.
Настройка NAT и брандмауэра
Мы считаем, что прокси-сервер нужен в первую очередь для контроля пользователей, поэтому заворачивать на него сервера и служебные хосты, которые не предоставляют доступ к интернет пользователям, не видим никакого смысла.
Создадим и откроем файл /etc/nat
внесем в него следующее содержимое:
Сохраним файл и дадим ему права на исполнение:
Настройка синхронизации времени
Для успешной работы с доменом Active Directory и прохождения Kerberos-аутентификации важно чтобы часы роутера были синхронизированы с часами контроллера домена.
Затем откроем файл конфигурации /etc/ntp.conf и закомментируем все строки, начинающиеся на server. После чего добавим две свои записи:
Как вы уже, наверное, догадались, мы закомментировали записи сторонних серверов времени и добавили в этом качестве контроллеры домена.
Затем добавим в конец файла две строки, ограничивающие работу NTP-клиента внутренним интерфейсом:
Сохраняем файл и перезапускаем службу:
Чтобы убедиться, что NTP работает только на внутреннем интерфейсе, выполните:
В выводе команды должны быть только внутренние адреса и адреса локальной петли (localhost):
Проверить синхронизацию можно командой:
В выводе обращаем внимание на колонки: when -время с последнего ответа сервера, pool - время опроса сервера, offset - разница времени в секундах.
Если ваш роутер расположен в виртуальной среде, то при загрузке, пока система не знает с кем синхронизировать время, время внутри виртуальной машины синхронизируется с временем гипервизора. Поэтому либо отключите эту функцию в настройках виртуальной машины, либо синхронизируйте часы гипервизора с часами домена.
Настройка кеширующего прокси-сервера Squid3
Внимание! Если вы перенастраиваете сервер для рабочей группы, то обязательно удалите пакет dnsmasq или иные DNS и DHCP сервера!
Важно! Начиная с Debian 9 и Ubuntu 16.04 вместо пакета squid3 снова используется squid, также аналогичным образом следует изменить все пути, т.е. вместо /etc/squid3 использовать /etc/squid.
Установим прокси-сервер squid3 командой:
Откроем конфигурационный файл /etc/squid3/squid.conf и зададим минимальную конфигурацию, добавив или раскомментировав в соответствующих секциях указанные строки.
Укажем acl элемент для локальной сети:
Минимальный набор списков доступа:
Интерфейсы, порты и режимы работы прокси:
Для squid 3.1 и ниже первая строка должна выглядеть так:
Сохраните и проверьте конфигурацию:
Если нет ошибок, то перезапускаем squid:
На DNS-сервере домена добавьте A-запись для нашего роутера:
Теперь в настройках браузера укажите полное FQDN имя сервера и порт 3128:
Так как никаких ограничений пока не установлено, то вы должны получить доступ в интернет.
На этом базовую настройку будем считать законченной. Следующим этапом будет настройка Kerberos-аутентификации и автоматического распространения настроек прокси, о чем мы расскажем в следующей статье.
Читайте также: