Настройка squid на windows server 2008 - Доктор Windows

Приветствую всех, гостей и постоянных читателей блога. Сегодня попробую изложить информацию о методах аутентификации в squid, а так же интегрировать suid в доменную инфраструктуру Active Directory на Windows Server 2008 R2. То есть заставить squid разрешать доступ к интернету на основе доменных учетных записей. Для понимания происходящего, советую ознакомиться с предыдущими статьями о настройке сети в Linux и вводной статье о squid. Итак, приступим…

Введение

Из прошлой статьи о squid мы знаем, что в прозрачном режиме squid не способен аутентифицировать пользователей. Поэтому придется настроить пользовательские браузеры. Кроме того, мы знаем, что хороший админ — это ленивый админ и ходить пешком по рабочим станциям и настраивать вручную браузеры пользователей он не станет. Поэтому расскажу как через GPO мы настроим IE (для пользователей бабушек с особо клиническим случаем и для сайтов, использующих ActiveX…), Firefox и Google Chrome. Все эти 3 браузера умеют настраиваться через GPO.

Squid в части авторизации и аутентификации подобен Web-серверу Apache и поддерживает те же способы аутентификации, что и Apache. На текущий момент существуют четыре основных типа проверки подлинности в HTTP протоколе:

Basic — самая первая схема, часто используемая по текущий момент
NTLM — это первая попытка Microsoft к SSO (single-sign-on) единого входа для ресурсов локальной сети
Digest — она же дайджет аутентификация. Чуть защищенней basic
Negotiate (aka SPNEGO) — она же Kerberos SPN generation — вторая попытка реализации Microsoft SSO

В статье я рассмотрю пример реализации basic аутентификации и Kerberos и кратко опишу NTLM и Digest.

Настройка адреса прокси через GPO в Windows Server 2008 R2

Настройка Internet Explorer через GPO

Желательно на всех машинах локальной сети обновить Internet Explorer до 7 версии, ибо с IE 6 доменная проверка подлинности не будет работать. Об этом Mictosoft официально заявляет. Настройка параметров прокси сервера задается в объекте групповой политики в разделе Конфигурация пользователя — Политики — Конфигурация Windows — Настройка Internet Explorer — Подключение — Параметры прокси-сервера: Т.к. данная настройка расположена в конфигурации пользователя, то и применяться будет к пользователям, расположенным в текущем подразделении OU, к которому будет применен Объект групповой политики.

Настройка Mozilla Firefox через GPO

1. Качаем MSI пакет FrontMotion Firefox Community Edition с http://www.frontmotion.com/FMFirefoxCE/download_fmfirefoxce.htm. (Обязательно Community Edition, ибо кроме CE-версии на данном сайте предлагается обычная сборка msi пакета, которая не принимает настройки из реестра GPO). Оттуда же качаем файлы административных шаблонов mozilla.admx и mozilla.adml, которые собственно и задают настройки групповых политик. Если у Вас сервер AD 2003 версии, то нужно скачивать firefox.adm и mozilla.adm.

2. Распространяем скачанный MSI пакет через объект GPO (как это сделать я описывал в статье установка программ через AD GPO).

3. Кладем скачанные файлы административных шаблонов…:

Если используется централизованное хранилище, то mozilla.admx кладется в каталог %logonserver%sysvol%userdnsdomain%policiesPolicyDefinitions, а mozilla.adml — в %logonserver%sysvol%userdnsdomain%policiesPolicyDefinitionsen-US.
Если используется локальное хранилище административных шаблонов, то mozilla.admx кладется в каталог %systemroot%PolicyDefinitions, а mozilla.adml — в %systemroot%PolicyDefinitionsen-US. После этого появиться новый раздел в настройках GPO.

4. Задаем настройки браузера в созданном объекте групповой политики. Настройки прокси-сервера задаются в разделе Конфигурация компьютера — Политики — Административные шаблоны — Mozilla Advanced Options — Locked Settings — network:

Т.к. данная настройка расположена в конфигурации компьютера, то и применяться будет к компьютеру всем пользователям, вошедшим в компьютер, расположенный в текущем подразделении OU, к которому будет применен Объект групповой политики. Кроме настроек прокси, браузер поддерживает еще туеву хучу настроек, о которых можно почитать тут http://kb.mozillazine.org/About:config_entries.

Настройка Google Chrome через GPO

1. Качаем MSI пакет Chrome с https://www.google.com/intl/en/chrome/business/browser/ или http://www.google.com/chrome/intl/ru/business/index.html. Качаем файлы административных шаблонов chrome.admx и chrome.adml, которые собственно и задают настройки — отсюда http://dl.google.com/dl/edgedl/chrome/policy/policy_templates.zip.

3. В скачанном архиве policy_templates.zip имеются каталоги policy_templateswindowsadmx, из данного каталога кладем файлы административных шаблонов…:

Если используется централизованное хранилище административных шаблонов, то chrome.admx кладется в каталог %logonserver%sysvol%userdnsdomain%policiesPolicyDefinitions, а chrome.adml — в %logonserver%sysvol%userdnsdomain%policiesPolicyDefinitionsru-RU.
Если используется локальное хранилище административных шаблонов, то ruchrome.admx кладется в каталог %systemroot%PolicyDefinitions, а ruchrome.adml — в %systemroot%PolicyDefinitionsen-US. После этого появиться новый раздел в настройках GPO.

4. Задаем настройки браузера в созданном объекте групповой политики. Настройки прокси сервера задаются в разделе Конфигурация пользователя — Политики — Административные шаблоны — Google — Google Chrome — Прокси-сервер:

Т.к. данная настройка расположена в конфигурации пользователя, то и применяться будет к пользователям, расположенным в текущем подразделении OU, к которому будет применен Объект групповой политики. Кроме настроек прокси, браузер Crome поддерживает еще много настроек, о которых можно почитать в скачанном архиве в файле policy_templatescommonhtmlruchrome_policy_list.html. Кроме того, можно ознакомиться с Кратким руководством от гугла http://support.google.com/a/bin/answer.py?hl=ru&answer=187202.

Методы аутентификации SQUID

Начну с рассмотрения общих принципов организации аутентификации в squid. Если быть точным, то сам squid не выполняет никаких функций аутентификации. Работа squid по аутентификации заключается в декодировании HTTP заголовка Authorization и передаче декодированной информации — так называемому хелперу. Если предоставленная информация верна, то доступ пользователю предоставляется, если же не верна или отсутствует, то squid возвращает клиенту HTTP код 407. Более подробно этот процесс будет рассмотрен далее. Т.о. всю основную работу по проверке подлинности пользователей выполняют сторонние модули (они же — хелперы, они же helpers). Расположение этих модулей зависит от дистрибутива и версии SQUID, например в Debian+squid3 они расположены в каталоге /usr/lib/squid3, в Red Hat скорее всего их расположение будет в /usr/lib/squid. Просмотреть, какие методы проверки подлинности поддерживает Ваш сквид, размещение хелперов и многие другие параметры, можно командой squid3 -v, вывод которой содержит опции, с которыми squid был сконфигурирован, например:

--prefix=/usr - префикс для других ключей:
--libexecdir=${prefix}/lib/squid3 - каталог с исполняемыми модулями (в том числе и хелперы)
--enable-auth=basic,digest,ntlm,negotiate - поддерживаемые модули аутентификации. Кроме того
                                            имеется множество дополнительных ключей,
                                            позволяющих настраивать отдельные методы аутентификации:
--enable-basic-auth-helpers=LDAP,MSNT,NCSA... - список программ для аутентификации basic
--with-logdir=/var/log/squid3
и др.

Когда Squid стартует, он запускает несколько подпроцессов, выполняющих аутентификацию. Эти процессы согласно своей схемы аутентификации проверяют подлинность пользователя и возвращают положительный результат сквиду либо отрицательный. Подобная техника позволяет использовать большое количество различных схем аутентификации, однако при подключении возможно использовать только одну схему:

squid ~ # pstree -ap 14068
squid3,14068 -YC -f /etc/squid3/squid.conf
  └─squid3,14070 -YC -f /etc/squid3/squid.conf
      ├─ncsa_auth,14089 /etc/squid3/squidusers
      ├─ncsa_auth,14090 /etc/squid3/squidusers
      ├─ncsa_auth,14091 /etc/squid3/squidusers
      ├─ncsa_auth,14092 /etc/squid3/squidusers
      ├─ncsa_auth,14093 /etc/squid3/squidusers
      ├─squid_kerb_auth,14079 -s HTTP/squid.domain.local@DOMAIN.LOCAL
      ├─squid_kerb_auth,14080 -s HTTP/squid.domain.local@DOMAIN.LOCAL
      ├─squid_kerb_auth,14081 -s HTTP/squid.domain.local@DOMAIN.LOCAL
      ├─squid_kerb_auth,14082 -s HTTP/squid.domain.local@DOMAIN.LOCAL
      └─unlinkd,14094

Взаимодействие и описание настроек сторонних модулей аутентификации производится с помощью параметра auth_param. Клиент будет поочередно пытаться использовать схемы аутентификации в том порядке, в котором они заданы в squid.conf. При этом (ходят слухи, но я с этим не столкнулся), у IE есть баг, который заставляет использовать сначала basic аутентификацию, даже если до basic заданы другие более безопасные схемы.

Новая настроенная схема аутентификации вступит в силу только после перезапуска squid, при этом, внесение изменений в уже существующие настроенные схемы может производится без перезапуска демона (достаточно дать команду squid3 -k reconfigure или /etc/init.d/squid3 reload). Настроенный внешний модуль проверки подлинности еще не означает, что эта проверка будет работать и пускать пользователя в интернет. Для контроля доступа в интернет, необходимо создать acl, который будет задействовать настроенный модуль аутентификации. Для этого, acl в поле тип_отбора должен иметь значение proxy_auth, proxy_auth_regex или external с использованием переменной %LOGIN. И, естественно, для заданного acl необходимо иметь разрешение на доступ в параметре http_access.

Формат указания типа используемой аутентификации (формат использования параметра auth_param) следующий:

auth_param схема_аутентификации параметры_схемы [значения_параметров]

где, схема_аутентификации — одна из вышеуказанных схем (basic, digest,…), параметры_схемы — задают настройки указанной схемы и в разных схемах могут различаться, значения_параметров — в этом поле описываются значения параметров_схемы. К каждой схеме аутентификации могут использоваться сколько угодно разные внешние модули, вплоть до использования и самописных скриптов bash. Обычно при установке squid устанавливаются все необходимые модули согласно поддерживаемым схемам аутентификации. Описание их работы и настройки от разработчиков можно найти на этой странице.

Для дальнейшей настройки прокси-сервера я буду использовать «умолчательный» конфиг из коробки, в котором пока разрешен доступ только с петлевого интерфейса:

squid ~ # grep -v ^# /etc/squid3/squid.conf | grep -v ^$
acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32
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 manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost
http_access deny all
http_port 3128
hierarchy_stoplist cgi-bin ?
coredump_dir /var/spool/squid3
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

Basic — метод аутентификации в squid (NCSA)

Давайте рассмотрим простейший способ аутентификации, который существовал еще со времен протокола HTTP/1.0. Basic метод аутентификации основан на предоставлении клиентом (веб-браузером или другой программой) — учетных данных (имени и пароля) при запросе какой-либо страницы. При этом, имя пользователя, объединенное двоеточием с паролем кодируется в кодировку base64 и передается в http-запросе в поле Authorization. Например имя пользователя Mc.Sim и пароль 12345 в виде строки Mc.Sim:12345 будут переданы в кодированном виде: TWMuU2ltOjEyMzQ1 . Кодирование текста в кодировку base64 не является защитой!!! Фактически пароль передается в открытом виде!!! Единственным преимуществом этой схемы является то, что любой браузер? каким бы он старым не был, поддерживает данный вид аутентификации.

Давайте рассмотрим практический пример basic-аутентификации:

Клиент запрашивает страницу, которая требует проверки подлинности (в нашем случае — клиент обращается к серверу squid), но не указывает имя пользователя и пароль.
```
    GET /path/index.html HTTP/1.1
    Host: localhost
```

Сервер отвечает клиенту с кодом 407 (» Proxy Authentication Required»), в ответ включается список поддерживаемых методов аутентификации и заголовок (realm)

    HTTP/1.1 401 Authorization Required
    Server: HTTPd/1.0
    Date: Mon, 27 Feb 2012 11:18:15 GMT
    WWW-Authenticate: Basic realm="Сервер безопасности"
    Content-Type: text/html
    Content-Length: 311

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
    <HTML>
       <HEAD>
          <TITLE>Error</TITLE>
          <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8">
       </HEAD>
       <BODY><H1>401 Unauthorized.</H1></BODY>
    </HTML>

Клиент представит аутентификационную информацию (при этом браузер отобразит окно ввода логина/пароля и пользователь должен его ввести, либо отменить)
После того, как пользователь ввел имя и пароль, браузер (или другая программа), склеит имя пользователя и пароль двоеточием, закодирует символы в base64, подставит это значение исходных запрос в поле Authorization и направит серверу.
```
    GET /path/index.html HTTP/1.1
    Host: localhost
    Authorization: Basic TWMuU2ltOjEyMzQ1
```

Сервер проверяет подлинность пароля и логина и предоставляет доступ.

    HTTP/1.1 200 OK
    Server: HTTPd/1.0
    Date: Mon, 27 Nov 2012 11:19:07 GMT
    Content-Type: text/html
    Content-Length: 1076

Либо не предоставляет доступ, если данные не верны.

За хранение паролей в Basic аутентификации отвечает обычный текстовый файл, в котором хранятся стоки с логином и паролем в закодированном в base64 виде. Управление данным файлом удобно осуществлять с помощью утилиты htpasswd. В Debian/ubuntu данная утилита входит в пакет apache2-utils. В squid, по умолчанию, для реализации данного метода аутентификации используется хелпер /usr/lib/squid3/ncsa_auth, который проверяет соответствие логина и пароля в соответствии с заданным файлом и возвращает «OK» или «ERR» в бесконечном цикле. Синтаксис команды htpasswd следующий:

squid ~ # htpasswd -c /создаваемый/файл/паролей имя_пользователя
New password:
Re-type new password:
Adding password for user имя_пользователя
squid ~ # htpasswd /редактируемый/фвйл/паролей имя_пользователя2
New password:
Re-type new password:
Adding password for user имя_пользователя2
squid ~ #  ##############################################################
squid ~ #  # с ключом -с команда htpasswd выполняется первый раз (создает новый файл), пример:
squid ~ # htpasswd -c /etc/squid3/squidusers mc.sim
New password:
Re-type new password:
Adding password for user mc.sim
squid ~ # cat /etc/squid3/squidusers
mc.sim:rpSb8bNGJSfTw
squid ~ # # без ключа -c происходит добавление пользователей к уже существующему файлу:
squid ~ #  htpasswd /etc/squid3/squidusers mc.sim2
New password:
Re-type new password:
Adding password for user mc.sim2
squid ~ # cat /etc/squid3/squidusers
mc.sim:rpSb8bNGJSfTw
mc.sim2:cXIAu76Wn9/7I
squid ~ # # для созданного файла желательно установить права на чтение
squid ~ # # только пользователю и группе, от которой работает демон:
squid ~ # chmod 440 /etc/squid3/squidusers
squid ~ # chown proxy:proxy /etc/squid3/squidusers

Для работы basic аутентификации в squid, необходимо задать параметр, указывающий на описанный нами хелпер, который взаимодействует с созданным нами файлом паролей. Кроме того, необходимо описать acl содержащий список пользователей, которые могут получить доступ к интернету (эти пользователи должны присутствовать в списке паролей), либо вместо пользователей указать значение REQUIRED, которое «включит» в созданный acl всех пользователей, прошедших аутентификацию. Ну и конечно необходимо разрешить доступ созданному acl с помощью параметра http_access. Живой пример:

squid ~ # grep -v ^# /etc/squid3/squid.conf | grep -v ^$
auth_param basic program /usr/lib/squid3/ncsa_auth /etc/squid3/squidusers
acl lan proxy_auth REQUIRED
http_access allow lan
<....>

Собственно, с данной конфигурацией уже вполне можно работать (не забудьте перезапустить squid). У параметра auth_param basic есть дополнительные настройки (например, количество одновременных соединений — auth_param basic concurrency n, время хранения/кэширования успешных авторизаций — auth_param basic credentialsttl 2 hours и др.), с которыми можно ознакомиться в squid.conf.

Кроме хранения паролей в файле, при basic аутентификации можно использовать еще великое множество источников информации о пользователе/пароле, например:

LDAP — хелпер squid_ldap_auth
PAM — хелпер pam_auth
SASL — хелпер sasl_auth
NIS — хелпер yp_auth
MySQL — хелпер squid_db_auth
RADIUS — хелпер squid_radius_auth
и др

Digest — метод аутентификации в squid

Этот метод более защищен, нежели basic-аутентификация, т.к. использует MD5-шифрование для отправки пароля через сеть. Схема работы взаимодействия аналогична basic, за тем лишь исключением, что на 2-ом и последующих шагах в ответ сервера и ответы клиента в поля аутентификации добавляются некоторые дополнительные параметры и случайные значения, которые используются для шифрования пароля. Сам пароль передается в виде хэша, который шифруется и дешифруется с использованием случайного числа. Для создания файла паролей используется утилита htdigest, которая находится в пакете apache2-utils. Используется хелпер /usr/lib/squid3/digest_pw_auth с указанием файла паролей. Вообще, этот хелпер поддерживает файл паролей в открытом виде, вроде user:password. Может так же использоваться ldap для извлечения информации о пользователях, но опять же — низкий уровень безопасности. Для LDAP — хелпер /usr/lib/squid3/digest_ldap_auth.

NTLM — метод аутентификации в squid

Про протокол NTLM и его особенности и недостатки я рассказывал в первой статье о samba. В данной теме особенно делать упор на этот протокол не буду, ибо — небезопасен. Для проверки подлинности используется хелпер /usr/lib/squid3/ntlm_auth. Данный вид аутентификации работает в браузерах IE, Mozilla, Opera, Crome.

Negotiate — метод аутентификации в squid

Теперь перейдем к самому интересному. Итак, Kerberos — аутентификация в squid в домене на Windows 2008 R2. Проверять валидность пользователя через Kerberos можно разными путями, например многие советуют использовать SAMBA+Winbind, но нам на сервере лишние службы не нужны, поэтому будем использовать другой способ — пакет krb5-user и файл krb5.conf. Пакет krb5-user и его зависимости содержит утилиты, разработанные Massachusetts Institute of Technology (MIT). Существует еще версия, разработанная hedimal, но мне с ней работать не приходилось. Способ аутентификации на основе MIT Kerberos на примере NFS я рассматривал в статье использование AD на Windows 2008 R2 как KDC для NFS, которую очень желательно почитать перед тем как приступать к текущему разделу. Большая часто теории — в указанной статье. Здесь я лишь частично опишу необходимые действия, отличные от NFS.

Схема наших действий примерно следующая:

1. Настроить squid и проверить работоспособность без Kerberos с доступом по IP, либо basic-аутентификация.
2. Настроить Kerberos

Предварительная настройка DNS и контроллера домена.
Настройка синхронизации времени (на основе демона ntpd)
Настроить и проверить Kerberos на идентификацию пользователя без ключевого файла krb5.keytab.
Создать ключевой файл krb5.keytab на KDC (контроллер домена Windows 2008 R2)
Настроить и проверить работу Kerberos для авторизации через krb5.keytab и корректность созданного keytab-файла.

3. Настроить squid на проверку подлинности через Kerberos.
4. Настроить веб-браузеры на Kerberos аутентификацию.

Давайте подробней разберем каждый шаг.

Исходные данные для организации NEGOTIATE — схемы аутентификации

домен — DOMAIN.LOCAL
DNS-имя контроллера домена — DC.DOMAIN.LOCAL
IP-адрес контроллера домена — 10.0.0.4
прокси-сервер squid
- DNS-имя SQUID сервера — SQUID.DOMAIN.LOCAL
- IP-адрес SQUID сервера — 10.0.0.10

1. Настроить squid и проверить работоспособность без Kerberos с доступом по IP, либо basic-аутентификация.

Данный пункт был реализован согласно приведенных в заголовке ссылок — ранее. Но есть некоторые нюансы конфигурирования сетевой подсистемы для корректной работы с Kerberos. Необходимо обязательно правильно настроить файлы /etc/hosts, /etc/hostname, /etc/resolv.conf, ну и конечно /etc/network/interfaces. (приведенные настройки рассмотрены для Debian/Ubuntu, но если учесть особенности другого дистрибутива, то общая схема настройки будет вполне пригодна)

squid ~ # cat /etc/hosts
10.0.0.10       squid.DOMAIN.local    squid
127.0.0.1       localhost
# для Kerberos советуют указывать именно такой порядок
# то есть первой строкой именно 10.0.0.10 (внешний IP, не loopback)
squid ~ # cat /etc/hostname
squid
squid ~ # cat /etc/resolv.conf
domain DOMAIN.local
search DOMAIN.local
nameserver 10.0.0.4
squid ~ # cat /etc/network/interfaces
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
        address 10.0.0.10
        netmask 255.255.0.0

2. Настройка Kerberos

2.1. Предварительная настройка DNS и контроллера домена.

Для корректной работы Kerberos необходимо иметь корректные прямые (A) записи и соответствующие обратные (PTR) записи для сервера squid.

2.2. Настройка синхронизации времени

Настройку синхронизации времени я описывал в статье о NFS в Windows AD. Здесь лишь кратко скажу, что я использую для этих целей NTP-сервер (пакет ntp) и следующий конфиг:

root@nfsd:~# cat /etc/ntp.conf
server dc.domain.local
restrict default ignore
restrict dc.domain.local
restrict 127.0.0.1 nomodify notrap

2.3. Настроить и проверить Kerberos на идентификацию пользователя без ключевого файла krb5.keytab.

Данный шаг так же описан в статье о NFS в Windows AD, здесь он абсолютно идентичен.

2.4. Создать ключевой файл krb5.keytab на KDC (контроллер домена Windows 2008 R2)

Далее, необходимо создать кейтаб-файл на контроллере домена (файл ключей, который будет использоваться для взаимодействия с Active Directory). Вся необходимая теория опять же есть в статье о NFS — создание keytab. Для squid команда создания keytab файла будет выглядеть так:

C:Windowssystem32>ktpass.exe /princ HTTP/squid.domain.local@DOMAIN.LOCAL 
/mapuser squid$@DOMAIN.LOCAL /crypto ALL /ptype KRB5_NT_PRINCIPAL 
/pass +rndpass /out C:tmpsquid.keytab
Targeting domain controller: DC.domain.local
Using legacy password setting method
Successfully mapped HTTP/squid.domain.local to SQUID$.
WARNING: Account SQUID$ is not a user account (uacflags=0x1021).
WARNING: Resetting SQUID$'s password may cause authentication problems if SQUID$ is being used as a server.

Reset SQUID$'s password [y/n]? y
WARNING: pType and account type do not match. This might cause problems.
Key created.
Key created.
Key created.
Key created.
Key created.
Output keytab to C:tmpsquid.keytab:
Keytab version: 0x502
keysize 54 HTTP/squid.domain.local@DOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0
x1 (DES-CBC-CRC) keylength 8 (0x2c3b98e6e052ef15)
keysize 54 HTTP/squid.domain.local@DOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0
x3 (DES-CBC-MD5) keylength 8 (0x2c3b98e6e052ef15)
keysize 62 HTTP/squid.domain.local@DOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0
x17 (RC4-HMAC) keylength 16 (0x85a6dea042798a45a547f8450e1115fc)
keysize 78 HTTP/squid.domain.local@DOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0
x12 (AES256-SHA1) keylength 32 (0x4c7b89004af3a67866db313e05592568995e31ce4554ef
a695532300bb2aca7c)
keysize 62 HTTP/squid.domain.local@DOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0
x11 (AES128-SHA1) keylength 16 (0x40e69a57b011ac68e08f23b7d1133f33)

Итого, мы получили keytab в каталоге C:tmp — squid.keytab. Теперь этот файл ключей Kerberos необходимо БЕЗОПАСНО скопировать на сервер squid, например чрез WinSCP и приступить к следующему шагу. Так же нужно задать права кейтабу.

2.5. Настроить и проверить работу Kerberos для авторизации через krb5.keytab и корректность созданного keytab-файла.

Допустим, лежит наш keytab в /etc/squid3/squid.keytab, давайте проверим корректность работы данного кейтаба с текущей ОС:

squid ~ # kinit -V -k -t /etc/squid3/squid.keytab  HTTP/squid.domain.local
Authenticated to Kerberos v5
squid ~ # klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: HTTP/squid.domain.local@DOMAIN.LOCAL

Valid starting     Expires        em    Service principal
02/29/12 11:20:24  02/29/12 21:20:24  krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL
        renew until 03/01/12 11:20:24
squid ~ # kdestroy
squid ~ # chown -v proxy:proxy /etc/squid3/squid.keytab
изменён владелец «/etc/squid3/squid.keytab» на proxy:proxy
squid ~ # chmod -v u=rw,go-rwx /etc/squid3/squid.keytab
права доступа «/etc/squid3/squid.keytab» изменены на 0600 (rw-------)

Что мы сделали в текущем листинге? Утилитой kinit мы инициировали получение и положили в кэш билет от KDC для SPN-записи HTTP/squid.domain.local с использованием ключа (т.е. не пароля, параметр -k) размещение которого задано с помощью параме. Для/emтра -t /etc/squid3/squid.keytab. Параметр -V заставляет утилиту выводить сообщение при удачной аутентификации. Далее, с помощью klist мы просматриваем полученный билет, который размещен в кэше. С помощью kdestroy мы уничтожаем все, что есть в кэше. Далее, мы ограничивает права доступа к нашему кейтабу, тем самым разрешаем доступ только пользователю, под которым работает сквид. АХТУНГ!!! Если на данном этапе kinit выдал ошибки, то далее настраивать смысла нет, ибо Kerberos клиент работает не корректно. Необходимо избавиться от ошибок.

3. Настройка squid на проверку подлинности через Kerberos в домене Windows 2008 R2.

Для того чтобы сквид знал, какой кейтаб использовать, ему нужно указать, где он лежит. Для этого нужно создать и заполнить файл /etc/default/squid3 следующим содержимым (задать переменную, хранящую путь к кейтаб файлу, которую читает сквид):

squid ~ # cat /etc/default/squid3
KRB5_KTNAME=/etc/squid3/squid.keytab
export KRB5_KTNAME

Так же, необходимо в squid.conf настроить схему аутентификации, для этого нужно добавить следующие строки:

# указание, какой хелпер использовать с каким SPN
auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -s HTTP/squid.domain.local@DOMAIN.LOCAL
# сколько параллельных потоков запускать для обслуживания аутентификации клиентов
auth_param negotiate children 10
# указывает поддерживать связь, а не обрывать, когда браузер опрашивает схемы аутентификации
auth_param negotiate keep_alive on

В некоторых конфигурациях в «сети» приводятся примеры без указания параметра -s и SPN, но у меня такая конфигурация не заработала. Так же, не забываем о наличии строк, разрешающим доступ для авторизованных пользователей:

acl lan proxy_auth REQUIRED
http_access allow lan

Примечание: вместо SPN можно использовать значение GSS_C_NO_NAME, в данном случае, squid будет использовать любой (какой? в какой последовательности?) SPN из keytab файла. Строка будет выглядеть так: <…>ate program /usr/lib/squid3/squid_kerb_auth -s GSS_C_NO_NAME (спасибо за дополнение комментатору selivan)

На этом можно считать настойку сквида законченной (не забудте сделать рестарт сквида). Если необходимо пускать не в всех пользователей в интернет, а только избранных, то в acl необходимо указать имя пользователя в том формате, в котором squid распознает пользователя. Этот формат можно посмотреть в логе access.log. Например для нашего случая имя пользователя имеет следующий вид:

1330858897.314 86 10.0.1.48 TCP_MISS/200 491 GET http://www.google-analytics.com/__utm.gif? test2@DOMAIN.LOCAL DIRECT/173.194.69.113 image/gif
1330858898.296 94 10.0.1.48 TCP_MISS/204 192 GET http://support.google.com/accounts/bin/stats? test2@DOMAIN.LOCAL DIRECT/173.194.69.100 -

то есть имя пользователя имеет формат имя_пользователя@ОБЛАСТЬ_ДОМЕНА. При этом, как показала практика, регистр букв имеет значение, то есть если в acl указать имя пользователя tEst2@DOMAIN.LOCAL или test2@DOMAIN.local, а в AD он заведен как test2 и область домена в верхнем регистре, то доступ пользователю предоставлен не будет. То есть нужно быть внимательным при указании пользователя в acl. Так же, можно задать список пользователей, перечислив их в отдельном файле и указав этот файл как значение для acl, например:

squid ~ # cat /etc/squid3/usersallow
ultest@DOMAIN.LOCAL
test2@DOMAIN.LOCAL
...
testn@DOMAIN.LOCAL
squid ~ # grep allow /etc/squid3/squid.conf
acl allowinet proxy_auth "/etc/squid3/usersallow"
http_access allow allowinet

Кроме данного способа, есть возможность предоставить доступ пользователей к интернету на основе членства в доменных группах. Но для данной задачи используется отдельный хелпер и список доступа в формате external_acl и хелпер /usr/lib/squid3/squid_ldap_group. В сети можно найти много примеров. Конфигурацию на основе доменных групп я постараюсь рассмотреть в следующих статьях.

4. Настроить веб-браузеры на Kerberos аутентификацию в squid.

Собственно, настройка браузеров для SQUID заключается в использовании FQDN-имени в адресе прокси-сервера вместо IP-адреса. То есть делаем все по инструкции Настройка адреса прокси через GPO в Windows Server 2008 R2, но адрес прокси указываем не 10.0.0.10, а squid.domain.local. Корректная работа с Kerberos у меня получилась только в браузерах IE старше 7 версии, Firefox и Chrome. Про IE версии ниже 7 версии можно почитать статью от microsoft.

После попытки доступа мы видим в логе access.log заветные строки:

1330506205.277 828 10.0.1.48 TCP_MISS/204 313 GET http://www.google.ru/client_204? test@DOMAIN.LOCAL DIRECT/209.85.173.94 text/html

Финальный вид настроек в squid.conf

squid ~ # grep -v ^# /etc/squid3/squid.conf | grep -v ^$
 # указание, какой хелпер использовать с каким SPN для negotiate авторизации
auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -s HTTP/squid.domain.local@DOMAIN.LOCAL
 # сколько параллельных потоков запускать для обслуживания аутентификации клиентов через kerberos
auth_param negotiate children 10
 # указывает поддерживать связь, а не обрывать, когда браузер опрашивает схемы аутентификации
auth_param negotiate keep_alive on
 # если клиент не прошел negotiate аутентификацию, ему будет выдан запрос логина/пароля для Basic аутентификации
auth_param basic program /usr/lib/squid3/ncsa_auth /etc/squid3/squidbasicusers
 # сколько параллельных потоков запускать для обслуживания basic аутентификации клиентов
auth_param basic children 10
 # создание списка контроля доступа с пользователями, которым далее разрешим доступ
acl allowinet proxy_auth "/etc/squid3/usersallow"
acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32
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
 # разрешаем доступ acl allowinet
http_access allow allowinet
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost
http_access deny all
http_port 3128
hierarchy_stoplist cgi-bin ?
coredump_dir /var/spool/squid3
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

Таким образом, мы требуем от клиента — Kerberos (negotiate) аутентификации, если клиент не принадлежит домену, то он должен аутентифицироваться через Basic аутентификацию. Это очень удобно, когда всем доменным пользователям предоставляется доступ по их доменной учетной записи, а «гостям», например с ноутбуками — выдаем логин/пароль для basic аутентификации. Эти логины/пароли храним в файле /etc/squid3/squidbasicusers. Список всех, кому разрешаем доступ мы храним в файле /etc/squid3/usersallow.

Траблешуттинг

Напомню такой нюанс: на контроллере домена возможно привязать несколько SPN к одной учетной записи, но это может привести к некоторым проблемам, поэтому я бы не советовал этого делать. Пример такой проблемы хорошо раборали товарсчи с форума ixbt. Кроме того, в сети идет много дебатов о том, привязывать SPN к учетной записи компьютера или к учетной записи пользователя, некоторую полезную информацию об этом можно найти тут.

Для корректной работы kerberos необходимо иметь открытый доступ для исходящих пакетов на tcp/dst-порт 88. Как это сделать, описано в статьях об iptables.

Для диагностики SQUID и Kerberos можно в строке

auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -s HTTP/squid.domain.local@DOMAIN.LOCAL

добавить ключ -d — это заставит хелпер быть более разговорчивым. При ошибках аутентификации сообщения будут появляться в логе /var/log/squid3/cache.log. Например, когда я неверно указал адрес прокси в браузере (указад ip вместо DNS FQDN), то в лог сыпались вот такие ошибки:

2012/02/28 23:06:46| authenticateNegotiateHandleReply: Error validating user via Negotiate. Error returned 'BH received type 1 NTLM token'
2012/02/28 23:06:49| squid_kerb_auth: DEBUG: Got 'YR TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAFASgKAAAADw==' from squid (length: 59).
2012/02/28 23:06:49| squid_kerb_auth: DEBUG: Decode 'TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAFASgKAAAADw==' (decoded length: 40).
2012/02/28 23:06:49| squid_kerb_auth: WARNING: received type 1 NTLM token

Резюме

Фух, статья завершена. Долго пришлось повозиться со всеми этими схемами и приведенными в интернете примерами. Уж очень большое количество комбинаций схем и хелперов поддерживает сквид. По началу можно запутаться, но надеюсь. что моя статья вам помогла в этом всем разобраться. Следующая статья о сквид планирует содержать правила ограничения доступа к интернету, как по посещаемым ресурсам, скорости, так и по времени и, возможно, другим критериям. Так же, планирую создать отдельную статью с тонкими настройками сквида.

Что еще почитать

Примеры использования LDAP групп в AD:
http://ru.gentoo-wiki.com/wiki/Настройка_авторизации_SQUID_в_Active_Directory_по_протоколу_LDAP
http://www.lissyara.su/?id=2101

Использование Kerberos в Web-сервере
ttp://www.grolmsnet.de/kerbtut/

Интересный нюанс работы squid и в целом аутентификации (первый и последний пост):
http://forum.ru-board.com/topic.cgi?forum=8&topic=11275

Отличная книга Squid Proxy Server 3.1 Beginner’s Guide

Upd 2012.04.08: добавил книгу Squid Proxy Server 3.1 Beginner’s Guide
Upd 2013.10.26: добавил инфу о GSS_C_NO_NAME

С Уважением, Mc.Sim!

Теги: Active Directory, Debian, kerberos, Linux, 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

Источник

Первое что нужно сделать — это присоединить наш сервер к домену Active Directory. Для этого в обязательном порядке необходимо синхронизировать время на всех серверах.

# apt-get install ntp

Редактируем /etc/ntp.conf — отключаем все сервера по умолчанию и добавляем свой:

server ntp.mydomain.ru

И перезапускаем сервис:

# service ntpd restart

Установка Kerberos

Для подключения нам нужно установить Kerberos

Устанавливаем Kerberos:

# apt-get install krb5-admin-server krb5-config krb5-kdc krb5-user

ОБЯЗАТЕЛЬНО устанавливаем пакет libsasl2-modules-gssapi-mit для правильной работы с Active Directory

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

Настройка Kerberos

Удаляем или переименовываем оригинальный файл /etc/krb5.conf и создаем новый со следующими настройками:

Регистр написания — очень важен!

[libdefaults]
    default_realm = MYDOMAIN.RU

[realms]
    MYDOMAIN.RU = {
        kdc = dc.mydomain.ru
    }

Получаем билет от контроллера домена:

# kinit domain_admin

где domain_admin — логин с правами Domain Administrator, а пароль будет запрошен в приглашении.

Смотрим получен ли билет:

# klist

Создаем keytab-файл на контроллере домена

keytab-файл это «связка ключей», файл содержащий в себе одну или несколько записей — ключей, которые используются вместо логина/пароля при запросе доступа у сервера KDC к какому-либо ресурсу. Другими словами, машина предоставляет данный файл серверу KDC как подтверждение своей достоверности, когда запрашивает у контроллера домена (KDC) доступ к какому-либо ресурсу (например доступ к службе или сетевому каталогу). В большинстве случаев, при настройке какой-либо службы в связке с Kerberos проблемы возникают именно на данном этапе, т.к. именно этот файл является связующим звеном между Windows 2008 и Linux (в нашем случае — Debian). Проблемы обычно связаны с различными типами шифрования, которые поддерживает Windows, но не поддерживает Linux и наоборот.

На контроллере домена даем команду (запустить из-под администратора):

C:Windowssystem32ktpass.exe /princ HTTP/[email protected] /mapuser [email protected] /crypto ALL /ptype KRB5_NT_PRINCIPAL /pass +rndpass /out C:tmpproxy.keytab

Где proxy.mydomain.ru — FQDN нового прокси-сервера, а [email protected] — логин пользователя, от имени которого будут делаться запросы в AD

Теперь этот ключ Kerberos необходимо БЕЗОПАСНО скопировать на наш прокси (например чрез WinSCP) и приступить к следующему шагу.

Устанавливаем:

# apt-get install squid

И приводим конфигурационный файл /etc/squid3/squid.conf к такому виду (описание групп доступа и их настройки см. ниже):

# Аутентификация в Active Directory
auth_param negotiate program /usr/lib/squid3/negotiate_kerberos_auth -s HTTP/[email protected]
auth_param negotiate children 10
auth_param negotiate keep_alive on
external_acl_type inet_medium ttl=300 negative_ttl=60 %LOGIN /usr/lib/squid3/ext_kerberos_ldap_group_acl -g [email protected]
external_acl_type inet_full ttl=300 negative_ttl=60 %LOGIN /usr/lib/squid3/ext_kerberos_ldap_group_acl -g [email protected]
external_acl_type inet_low ttl=300 negative_ttl=60 %LOGIN /usr/lib/squid3/ext_kerberos_ldap_group_acl -g [email protected]

# Стандартные порты
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

# Белый и черный список
acl white_list url_regex -i "/etc/squid3/white_list"
acl black_list url_regex -i "/etc/squid3/black_list"

# Определяем группы доступа
acl my_full external inet_full
acl my_medium external inet_medium
acl my_low external inet_low

# Перечень сетей
acl all src all
acl our_networks src 192.168.102.0/24

# Авторизация требуется ОБЯЗАТЕЛЬНО, без нее никого не пускать
acl nt_group proxy_auth REQUIRED

# Стандартные разрешения
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager

# Права доступа для наших групп пользователей
http_access allow my_low white_list
http_access deny my_low
http_access deny my_medium black_list
http_access allow my_medium
http_access allow my_full

# Разрешаем локалхост
http_access allow localhost

# Запрещаем все остальное
http_access deny all

# Ограничение пропускной способности интернет-канала
delay_pools 3
delay_class 1 1
delay_class 2 1
delay_class 3 1
delay_parameters 1 -1/-1 -1/-1
delay_parameters 2 384000/384000
delay_parameters 3 32000/32000
delay_access 1 allow Full
delay_access 2 allow Medium
delay_access 3 allow Low

# Порты прокси-сервера
http_port 192.168.1.1:3128
http_port 192.168.1.1:3127 transparent

# Выделяем 3,5 Гб памяти для прокси
cache_mem 3584 MB

# Выделяем место на жестком диске для хранения файлов кэша
cache_dir ufs /var/spool/squid3 100 16 256

# Куда и в каком объеме будем писать логи
access_log /var/log/squid3/access.log
logfile_rotate 100
coredump_dir /var/spool/squid3

# Настройки кэширования
refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern -i (/cgi-bin/|?) 0     0%      0
refresh_pattern (Release|Packages(.gz)*)$      0       20%     2880
refresh_pattern -i .(gif|png|jpg|jpeg|ico)$    3600    90%     43200
refresh_pattern .               0       20%     4320

# Запрещаем отображение версии прокси-сервера и имени
httpd_suppress_version_string on
visible_hostname PROXYSERVER

# Включаем русский язык для сообщений сервера
error_directory /usr/share/squid3/errors/Russian-1251
error_default_language ru

# Принудительно задаем желаемый DNS-сервер
dns_nameservers 192.168.1.3
dns_v4_first on

Проверяем конфиг на ошибки:

# squid3 -k parse

Если парсер не обнаружил никаких ошибок, можно применить новую конфигурацию Squid:

# squid3 -k reconfigure

или

# service squid3 restart

Чтобы Squid и соответствующие хелперы умели работать с Kerberos надо добавить в скрипт запуска Squid (или создать файл /etc/default/squid3) следующие строки:

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

По умолчанию в Squid 3.3.8-1ubuntu6.1 не включен хелпер ext_kerberos_ldap_group_acl — а это значит что нельзя будет узнавать в какие группы включен пользователь. Для исправления это недостатка необходимо врукопашную собрать этот хелпер. Для этого необходимо установить пакет build-essential и все что ему нужно:

# apt-get install build-essential

Качаем с сайта http://www.squid-cache.org/ нужную версию Squid, в моем случае это http://www.squid-cache.org/Versions/v3/3.3/squid-3.3.8.tar.bz2 и разворачиваем куда-нибудь, например /usr/src/squid/squid-3.3.8

В этой папке делаем следующее:

# ./configure --enable-external-acl-helpers="kerberos_ldap_group" --libexecdir=/usr/lib/squid3 --sysconfdir=/etc/squid3
# make

Теперь все готово для сборки самого хелпера:

# cd /usr/src/squid/squid-3.3.8/helpers/external_acl/kerberos_ldap_group
# make

Если все прошло без ошибок, в папке /usr/src/squid/squid-3.3.8/helpers/external_acl/kerberos_ldap_group можно найти готовый собранный хелпер ext_kerberos_ldap_group_acl и скопировать его в /usr/lib/squid3/ не забыв сделать исполняемым:

# chmod +x ext_kerberos_ldap_group_acl
# cp ext_kerberos_ldap_group_acl /usr/lib/squid3/

По условиям у нас в Active Directory есть 3 группы доступа:

Сопоставление групп идет в следующем кусочке:

# Определяем группы доступа
acl my_full external inet_full
acl my_medium external inet_medium
acl my_low external inet_low

Завернуть всех пользователей (если PROXY является еще и шлюзом):

iptables -t nat -A PREROUTING -s 192.168.1.0/24 -p tcp —dport 80 -j REDIRECT —to-port 3127

Завернуть если PROXY — отдельный сервер:

iptables -t nat -A PREROUTING -s 192.168.1.0/24 -p tcp —dport 80 -j DNAT —to 192.168.1.1:3127

где 192.168.1.1 — IP нашего PROXY

Так же можно средствами Group Policy прописать прокси-сервер требуемым объектам GPO

Остался последний этап — отображать красивую статистику посещений сайтов пользователями. Самый простой и красивый инструмент для этого — LightSquid.

# apt-get install apache2 lightsquid

Приводим файл /etc/apache2/conf-available/lightsquid.conf в такой вид (доступ на просмотр даем всем):

Alias   /lightsquid/    /usr/lib/cgi-bin/lightsquid/

<Location "/lightsquid/">
        Options +ExecCGI
        Require local
        Require ip 192.168.1.0/24
</Location>

Раскомментируем строку 219 в файле /etc/apache2/mods-enabled/mime.conf

AddHandler cgi-script .cgi .pl

Запускаем все это дело:

# a2enmod cgi
# a2enconf lightsquid
# service apache2 restart

Необходимо поставить пакет libnet-ldap-perl:

# apt-get install libnet-ldap-perl

Очень хочется чтобы в отчете фигурировало полное ФИО пользователя, а не доменное имя или IP-адрес. Для этого нужно заменить оригинальный файл /usr/share/lightsquid/ip2name/ip2name.squidauth следующим:

#contributor: esl
#specialy for squid with turned on user authentication
#simple version
 
use strict;
use warnings;
use Net::LDAP;
use Encode;
 
my $ldap;
my $message;
my %hDisplayName;
 
sub StartIp2Name() {
        my $server = "ldap://dc.mydomain.ru";
        $ldap = Net::LDAP->new( $server );
        return if(!defined $ldap);
        $message = $ldap->bind(q(mydomain.rulightsquid), password => "my_password");
}
 
sub Ip2Name($$$) {
  # $Lhost,$user,$Ltimestamp
  my $Lhost=shift;
  my $user =shift;
  $user    =URLDecode($user); #decode user name
  $user = substr($user, 0, index($user, "@mydomain.ru"));
  return $Lhost if ($user eq "-");
  return $user if (!defined $ldap);
  return $user if ($message->code());
 
  if (!defined $hDisplayName{$user})
  {
 
    my $result = $ldap->search(
    base        => "dc=mydomain,dc=ru",
    filter      => "(&(objectCategory=person)(objectClass=user)(sAMAccountName=" . $user . "))",
    );
 
my $first_entry = $result->entry(0);
if (!defined $first_entry)
  {
    return $Lhost;
  }
 
my $pure_displayName = $first_entry->get_value("displayName");
$pure_displayName =~ s/ /_/g;
Encode::from_to($pure_displayName, 'utf-8', 'windows-1251');
 
  $hDisplayName{$user}=$pure_displayName;
  }
 
  return $hDisplayName{$user};
}
 
 
sub StopIp2Name() {
        return if (!defined $ldap);
        $message = $ldap->unbind;
}
 
#warning !!!
1;

В этом файле исправляем нижеуказанные строки на свои:

...
        my $server = "ldap://dc.mydomain.ru";
...
        $message = $ldap->bind(q(MYDOMAIN.RULightSquid), password => "PASSWORD");
...
    base        => "dc=MYDOMAIN,dc=RU",
...

Теперь в /etc/lightsquid/lightsquid.cfg включаем преобразование логина в ФИО:

$ip2name="squidauth"

Запускаем /usr/share/lightsquid/check-setup.pl и если все хорошо, можно запускать /usr/share/lightsquid/lightparser.pl

В папке /var/lib/lightsquid/report должны появиться отчеты, которые можно поглядеть по адресу: http://192.168.1.1/lightsquid/

Ошибка «kerberos_ldap_group: ERROR: Error while binding to ldap server with SASL/GSSAPI: Local error»

Необходимо установить библиотеку Cyrus-SASL, в убунте она называется libsasl2-modules-gssapi-mit

Источник

🔗 Does Squid run on Windows ?

Squid can compile and run on Windows as a system service using the
Cygwin emulation environment, or can be
compiled in Windows native mode using the MinGW + MSYS
development environment. All modern Windows versions are supported

The original development code name of the 2.5 project port was
SquidNT, but after the 2.6.STABLE4 release, this project was
complete. So when speaking about Squid on Windows, people should
always refer to Squid, instead to the old SquidNT name.

🔗 Known Limitations

🔗 Unavailable features

DISKD: still needs to be ported
Transparent Proxy: missing Windows non commercial interception
driver
WCCP: these features have not been ported. Without transparent
proxy support there is no need or use.
SMP support: Windows equivalent of UDS sockets has not been
implemented
Some code sections can make blocking calls.
Some external helpers may not work.
File Descriptors number hard-limited to 2048 when building with
MinGW.

🔗 Pre-Built Binary Packages

Packages available for Squid on multiple environments.

🔗 Squid-4

Maintainer: Rafael Akchurin, Diladele B.V.

Bug Reporting: (about the installer only)
https://github.com/diladele/squid-windows/issues

MSI installer packages for Windows are at:

64-bit: http://squid.diladele.com/

🔗 Squid-3.3

Bug Reporting: see https://cygwin.com/problems.html

Binary packages for the Cygwin environment on Windows are at:

32-bit: https://cygwin.com/packages/x86/squid/
64-bit: https://cygwin.com/packages/x86_64/squid/

🔗 Installing Squid

🔗 Service

Some new command line options were added for the Windows service
support:

-n switch to specify the Windows Service Name. Multiple Squid
service instances are allowed. Squid is the default when the
switch is not used. All service control operations use this switch
to identify the destination instance being targeted.
-i switch to install the Windows service. It’s possible to use
-f switch at the same time to specify a different squid.conf
file for the Squid Service that will be stored on the Windows
Registry. To install the service, the syntax is:
```
  squid -i [-f file] [-n service-name]
```
-r switch will uninstall the Windows service. Use the
appropriate -n switch to determine which service instance is
being removed. To uninstall the service, the syntax is:
```
  squid -r [-n service-name]
```
- -k switch is not new, but requires the use of -n to target
  the service instance. The syntax is:
```
squid -k command [-f file] [-n service-name]
```

🔗 Command Line

To use the Squid original command line, the new -O switch must be
used ONCE, the syntax is:

squid -O cmdline [-n service-name]

If multiple service command line options must be specified, use quote.
The -n switch is needed only when a non default service name is in
use.

Don’t use the “Start parameters” in the Windows 2000/XP/2003 Service
applet. They are specific to Windows services functionality and
Squid is not able to interpret and use them.

In the following example the command line of the “squidsvc” Squid
service is set to “-D -u 3130”:

squid -O "-u 3130" -n squidsvc

🔗 Cache Manager CGI on Windows

On Windows, cache manager
can be used with Microsoft IIS or Apache. Some specific configuration
could be needed:

IIS 6 (Windows 2003):
- On IIS 6.0 all CGI extensions are denied by default for security
  reason, so the following configuration is needed:
  - Create a cgi-bin Directory
  - Define the cgi-bin IIS Virtual Directory with read and CGI
    execute IIS permissions, ASP scripts are not needed. This
    automatically defines a cgi-bin IIS web application
  - Copy cachemgr.cgi into cgi-bin directory and look to file
    permissions: the IIS system account and SYSTEM must be able
    to read and execute the file
  - In IIS manager go to Web Service extensions and add a new
    Web Service Extension called “Squid Cachemgr”, add the
    cachemgr.cgi file and set the extension status to Allowed

Apache:
On Windows, cachemgr.cgi needs to create a temporary file, so
Apache must be instructed to pass the TMP and TEMP Windows
environment variables to CGI applications:

  ScriptAlias /squid/cgi-bin/ "c:/squid/libexec/"
  <Location /squid/cgi-bin/cachemgr.cgi>
      PassEnv TMP TEMP
      Order allow,deny
      Allow from workstation.example.com
  </Location>

🔗 Configuration Guides

Windows Update
Active Directory Authentication
Kerberos Authentication
NTLM Authentication
These and many other general manuals in the ConfigExamples
section.

🔗 Registry DNS lookup

On Windows platforms, if no value is specified in the
dns_nameservers
option in squid.conf or in the /etc/resolv.conf file, the list of DNS
name servers are taken from the Windows registry, both static and
dynamic DHCP configurations are supported.

🔗 Compatibility Notes

It’s recommended to use ‘/’ char in Squid paths instead of ‘’
Paths with spaces (like ‘C:Programs FilesSquid) are NOT
supported by Squid
When using ACL like
‘acl aclname acltype “file”’
the file must be in DOS text format (CR+LF) and the full
Windows path must be specified, for example:
```
  acl blocklist dstdomain "c:/squid/etc/blocked1.txt"
```
The Windows equivalent of ‘/dev/null’ is ‘NUL’
Squid doesn’t know how to run external helpers based on scripts,
like .bat, .cmd, .vbs, .pl, etc. So in squid.conf the interpreter
path must be always specified, for example:
```
  url_rewrite_program c:/perl/bin/perl.exe c:/squid/libexec/redir.pl
  url_rewrite_program c:/winnt/system32/cmd.exe /C c:/squid/libexec/redir.cmd
```
When Squid runs in command line mode, the launching user account
must have administrative privilege on the system
“Start parameters” in the Windows 2000/XP/2003 Service applet cannot
be used
On Windows Vista and later, User Account Control (UAC) must be
disabled before running service installation

🔗 Compiling

configure options

–enable-win32-service
–enable-default-hostsfile

Unsupported configure options:

–with-large-files: No suitable build environment is available on
both Cygwin and MinGW, but –enable-large-files works fine

🔗 Compiling with Cygwin

This section needs re-writing. Is has very little in compiling
Squid and much about installation.**

In order to compile Squid, you need to have Cygwin fully installed.

The usage of the Cygwin environment is very similar to other Unix/Linux
environments, and -devel version of libraries must be installed.

Squid will by default, install into /usr/local/squid.
If you wish to install somewhere else, see
the –prefix option for configure

Now, add a new Cygwin user — see the Cygwin user guide — and map it to
SYSTEM, or create a new NT user, and a matching Cygwin user and they
become the squid runas users.

Read the squid FAQ on permissions if you are using CYGWIN=ntsec.

When that has completed run:

If that succeeds, try:

Squid should start. Check that there are no errors. If everything looks
good, try browsing through squid.

Now, configure cygrunsrv to run Squid as a service as the chosen
username. You may need to check permissions here.

🔗 Compiling with MinGW

In order to compile squid using the MinGW environment, the packages
MSYS, MinGW and msysDTK must be installed. Some additional libraries and
tools must be downloaded separately:

OpenSSL: Shining Light Productions Win32 OpenSSL
libcrypt: MinGW packages repository
db-1.85: TinyCOBOL download area

3.2+ releases require a newer 4.6 or later version of libdb

Before building Squid with SSL support, some operations are needed (in
the following example OpenSSL is installed in C:OpenSSL and MinGW in
C:MinGW):

Copy C:OpenSSLlibMinGW content to C:MinGWlib
Copy C:OpenSSLincludeopenssl content to
C:MinGWincludeopenssl
Rename C:MinGWlibssleay32.a to C:MinGWliblibssleay32.a

Unpack the source archive as usual and run configure.

The following are the recommended minimal options for Windows:

Squid-3 : (requires Squid-3.5
or later, see porting efforts section below)

--prefix=c:/squid
--enable-default-hostsfile=none

Then run make and install as usual.

Squid will install into c:squid. If you wish to install somewhere
else, change the –prefix option for configure.

When that has completed run:

If that succeeds, try:

squid should start. Check that there are no errors. If everything
looks good, try browsing through squid.

Now, to run Squid as a Windows system service, run squid -n, this will
create a service named “Squid” with automatic startup. To start it run
net start squid from command line prompt or use the Services
Administrative Applet.

Always check the provided release notes for any version specific detail.

🔗 Compiling with msys2

to be completed

🔗 Squid-3 porting efforts

Squid series 3 has major build issues on all Windows compiler systems.
Below is a summary of the known status for producing a useful Squid 3.x
for Windows. In a rough order of completeness as of the last page
update.

The TODO list for Windows has additional wishlist items that also need
to be sorted out:

Separate Windows AIOPS logics from Unix AIO logics. The two are
currently mashed together where they should be in separate
conditionally built library modules.
Windows OIO support. Alternative to Unix AIO and AIOPS disk I/O
functionality.
Building an installer

🔗 Cygwin

Cygwin has working builds and available packages sponsored by
Diladele.

🔗 MinGW-w64

As of
Squid-3.5 :

the default featu re set builds without extra special ./configure
options.
missing shared socket support available in Vista and later.
Necessary for SMP workers.

AmosJeffries is cross-compiling with Mingw-w64 build
environment on Debian, with
occasional native MinGW-w64 environment builds for confirmation of
changes. As this is spare-time work progress is slow.

cross-compiling:

    # Debian Packages Required:
    #
    # g++
    #       provides GCC base compiler. GCC 4.9.1 or later required.
    #
    # mingw-w64
    #       provides GCC cross-compiler. GCC 4.9.1 or later required.
    #
    # mingw-w64-tools
    #       provides pkg-config and other build-time tools used by autoconf
    #

    ./configure 
            --host=i686-w64-mingw32 
            CXXFLAGS="-DWINVER=0x601 -D_WIN32_WINNT=0x601" 
            CFLAGS="-DWINVER=0x601 -D_WIN32_WINNT=0x601" 
            BUILDCXX="g++" 
            BUILDCXXFLAGS="-DFOO" 
            --enable-build-info="Windows (MinGW cross-build)"

This builds
The squidclinet tool operates well, other helpers and tools are yet
untested but expected to be fine.
The main Squid binary still lacks SMP support and will only operate
with the -N command line option.

Native build:

Requires the latest packages from
http://sourceforge.net/projects/mingw-w64/ with GCC 4.9 series
compiler.

sh ./configure 
        CXXFLAGS="-DWINVER=0x601 -D_WIN32_WINNT=0x601" 
        CFLAGS="-DWINVER=0x601 -D_WIN32_WINNT=0x601" 
        --enable-build-info="Windows (MinGW-w64)"

🔗 MinGW32

Sponsorship from iCelero produced a working
Squid-3.2
and
Squid-3.3.
Unfortunately the product and sponsorship dropped before the final
stages of this work could be cleaned up for GPL release.

As ofSquid-3.5:

the default feature set builds without extra special ./configure
options.

missing shared socket support available in Vista and later.
Necessary for SMP workers.

  ./configure 
          CXXFLAGS="-DWINVER=0x601 -D_WIN32_WINNT=0x601" 
          CFLAGS="-DWINVER=0x601 -D_WIN32_WINNT=0x601" 
          --enable-build-info="Windows (MinGW32)"

This builds for Squid-3.5
but not later code. A newer GCC version than supplied with
MingW32 is required.
The main Squid binary still lacks SMP support and will only operate
with the -N command line option.

There also appears to be some work done by Joe Pelaez Jorge
(https://code.launchpad.net/~joelpelaez/squid/win32).

🔗 Visual Studio

Almost no work on this environment has been done since
Squid-2.7.

Entirely new .sln, .sdf and .vcxproj build files need to be generated.
Ideally these would mirror the on-Windows style of convenience libraries
assembled to produce a number of different binaries. Experiments along
those lines have some nice results.

Categories: KnowledgeBase

Navigation: Site Search,
Site Pages,
Categories, 🔼 go up

Источник

Введение

В данной статье рассматривается довольно сложная тема как подружить прокси сервер squid с Active Directory (AD) используя kerberos.

Почему был выбран kerberos — это один из самых безопасных сетевых протоколов аутентификации который используется в AD и можно использовать в linux системах.
Сразу предупреждаю новичкам следует начать с чего-нибудь попроще т. к. kerberos очень привередлив к настройкам, а причины ошибок kerberos зачастую весьма туманны. Особое внимание нужно уделять регистру написания доменов. Ещё в разных версиях squid любят переименовывать параметры и названия хелперов. И как обычно одна неправильная точка, запятая, или имя компьютера может изрядно попортить вам нервы так что будьте внимательны и аккуратны.

Итак что у нас есть:

1. Контроллеры домена на windows 2008 R2 или 2012 R2 — serverdc (192.168.0.8), serverdc2 (192.168.0.9) которые управляют доменном mydomain.local

2. Прокси сервер на debian (ubuntu server) — proxy (192.168.0.6)
Начнём с настройки прокси сервера.

3. Клиенты windows XP и/или windows 7,8,10

Обращаю особое внимание что на всех серверах ip адреса должны быть статическими на клиентах можно использовать и динамические.

Настройки контроллера домена

Предполагается что контроллер домена уже настроен и все клиенты в него заведены. Нам нужно добавить A запись на DNS сервере:

proxy       узел(A)     192.168.0.6

Проверим запись:

nslookup proxy.mydomain.local

Теперь нужно создать тикет (кейтаб) для пользователя, от имени которого будет проверяться валидность пользователя интернета.

В АД создаем пользователя например squid с вечным паролем и не блокируемым.

Генерим сам кейтаб для этого используем утилитку ktpass на контроллере доменна:

ktpass -princ HTTP/proxy.mydomain.local@MYDOMAIN.LOCAL -mapuser squid@mydomain.local -crypto RC4-HMAC-NT -pass Secretpassw0rd -ptype KRB5_NT_PRINCIPAL -out proxy.keytab

Важно указать «принципалом» именно hostname линукс сервера (в данном примере — proxy) потому что, в свойствах браузеров FireFox или IE нужно указать proxy.mydomain.local а не IP. Если необходимо указывать другое имя, а не то, что отдает дебиан по hostname -a, его нужно указать в конфиге сквида в параметре visible_hostname.

Копируем созданный файл proxy.keytab на прокси сервер в файл /etc/krb5.keytab он нам ещё понадобиться.

Настройка DNS

Переходим к настройкам линукса в современных дистрибутивах /etc/resolv.conf генерится автоматически и есть разные варианты настройки поэтому нужно смотреть инструкцию на свой дистрибутив но в конечном итоге должно получиться примерно так:

domain MYDOMAIN.LOCAL
search MYDOMAIN.LOCAL
nameserver 192.168.0.8
nameserver 192.168.0.9

Проверяем что контроллер домена доступен:

nslookup serverdc.mydomain.local
ping serverdc.mydomain.local

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

Kerberos не будет проходить аутентификацию, если время между клиентом, прокси сервером и контроллером домена будет отличатся более чем на 3 минуты с учётом часовых поясов. Если что то не работает в первую очередь нужно проверить что время везде одинаковое и часовые пояса правильные.
Чтобы время всегда было правильным ставим демона (службу) который будет синхронизировать время с контроллером домена

apt-get install ntp

Добавим в /etc/ntp.conf с кем нужно синхронизироваться:

# Specify one or more NTP servers.
server serverdc.mydomain.local
server serverdc2.mydomain.local

Остановим ненадолго демона

/etc/init.d/ntp stop

Проверим время и заодно синхронизируем часы

ntpdate serverdc

Запускаем демона теперь он сам будет следить за временем

/etc/init.d/ntp start

Настройка kerberos

Поставим утилиты и библиотеки необходимые для работы kerberos:

apt-get install krb5-user krb5-config libkrb53

Теперь нужно привести файл настроек /etc/krb5.conf к виду

[appdefaults]
pam = {
	debug = false
	alt_auth_map = %s@MYDOMAIN.LOCAL
	force_alt_auth = true
	ticket_lifetime = 24h
	renew_lifetime = 24h
	forwardable = true
	krb4_convert = false
}

[libdefaults]
default_realm = MYDOMAIN.LOCAL
ticket_lifetieme = 24h
dns_lookup_realm = false
dns_lookup_kdc = false
kdc_timesync = 1
ccache_type = 4
forwardable = yes
rdns = no
default_keytab_name = /etc/krb5.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
clock_skew = 300

[realms]
MYDOMAIN.LOCAL = {
	kdc = serverdc.mydomain.local:88
	kdc = serverdc2.mydomain.local:88
	admin_server = serverdc.mydomain.local:749
	default_domain = MYDOMAIN.LOCAL
}

[domain_realm]
.mydomain.local = MYDOMAIN.LOCAL
mydomain.local = MYDOMAIN.LOCAL

[logging]
default = FILE:/var/log/krb5lib.log
kdc = FILE:/var/log/krb5kdc.log
kdc = SYSLOG:INFO AEMON
admin_server = FILE:/var/log/kadmin.log

Проверим правильность настройки kerberos

kinit usertest

usettest это может быть любой пользователь их AD если после ввода пароля не было никаких сообщений значит все хорошо можно двигаться дальше, если есть ошибки стоит ещё раз внимательно перепроверить файл /etc/krb5.conf.

Теперь проверим кейтаб который мы сделали ранее на контроллере домена:

kinit -V -k -t /etc/krb5.keytab HTTP/proxy.mydomain.local@MYDOMAIN.LOCAL

Должно быть сообщение об успешной авторизации. Если наблюдаются ошибки то здесь они могут быть самыми не очевидными например не поддерживается алгоритм шифрования однако лечится генерацией кейтаба с исправленным hostname. Короче нужно ещё раз внимательно проверить что кейтаб был сгенерирован с правильными параметрами с полным доменным именем прокси сервера. Ещё помнится как то долго бился пока не заменил везде hostname на более короткий. Также нужно убедиться что в DNS сделана правильная A запись для прокси сервера.

Установка SQUID

Теперь перейдем к установке squid

apt-get install squid3 libpam-krb5

Скажем squid создать кэш и перезапустим чтобы проверить что он работает.

squid3 -z
/etc/init.d/squid3 restart

Cоздаем файл /etc/pam.d/squid в который пишем:

auth required pam_krb5.so
session required pam_krb5.so
account required pam_krb5.so
password required pam_krb5.so

Теперь нужно дописать в начало файла (после второй строки) /etc/init.d/squid3

KBR5_KTNAME=/etc/krb5.keytab
export KRB5_KTNAME

И назначим права на кейтаб:

chown proxy:proxy /etc/krb5.keytab
chmod 664 /etc/krb5.keytab

Переходим к редактированию конфига /etc/squid3/squid.conf

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 manager localhost
http_access deny manager
include /etc/squid3/auth.conf
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost
http_access deny all
http_port 3128
hierarchy_stoplist cgi-bin ?
coredump_dir /var/spool/squid3
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

Конфиг на самом деле дефолтный кроме строки номер 18 где опцией unclude подключается файлик с дополнительными настройками.

Создаем файлик include /etc/squid3/auth.conf в котором пишем самое главное:

#Используем специальный helper для прозрачной аутентификации через kerberoos
#auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -d -s HTTP/proxy.mydomain.local@MYDOMAIN.LOCAL
auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -s HTTP/proxy.mydomain.local@MYDOMAIN.LOCAL
auth_param negotiate children 20
auth_param negotiate keep_alive on

#Используем kerberos через систему pam для базовой авторизации с запросом пароля
auth_param basic program /usr/lib/squid3/basic_pam_auth -n squid
auth_param basic children 10
auth_param basic credentialsttl 2 hours
auth_param basic realm MYDOMAIN.LOCAL

#Необходимо для поиска групп в AD
#external_acl_type ldap_check ttl=1200 children=15 %LOGIN /usr/lib/squid3/squid_ldap_group -R -b "dc=mydomain,dc=local" -f "(&(objectclass=person)(sAMAccountName=%v)(memberof=cn=%a,ou=Groups,ou=MainUsers,dc=mydomain,dc=local))" -D "squid@mydomain.local" -w "MegaPass123" -K -d 192.168.0.8
external_acl_type ldap_check ttl=1200 children=15 %LOGIN /usr/lib/squid3/squid_ldap_group -R -b "dc=mydomain,dc=local" -f "(&(objectclass=person)(sAMAccountName=%v)(memberof=cn=%a,ou=Groups,ou=MainUsers,dc=mydomain,dc=local))" -D "squid@mydomain.local" -w "MegaPass123" -K 192.168.0.8

#Описание групп доступа из AD
acl all_it external ldap_check IT
acl all_student external ldap_check Students
acl all_inet external ldap_check inet

#Описываем пользователей которые невходят в другие группы
acl auth proxy_auth admin@MYDOMAIN.LOCAL
acl auth proxy_auth sasha@MYDOMAIN.LOCAL

#Назначаем разрешения кому можно ходить в интернет
http_access allow all_student
http_access allow all_inet
http_access allow all_it
http_access allow auth

Строчки 2 и 13 отличаются от 3 и 14 только параметром -d который можно использовать чтобы получить более подробную информацию о процессе авторизации в логах для обычной работы он ненужен.

Перезапускаем squid

/etc/init.d/squid3 restart

проверим что в логах нет ошибок

tail -n 50 /var/log/squid3/access.log

Если все впорядке то осталось настроить браузер на клиенте.

Настройка браузера

Для прозрачной авторизации нужен Internet Explorer 7 версии и выше т.к. на более ранних версиях протокол kerberos не поддерживается. В настройках нужно указывать обязательно полное имя прокси сервера proxy.mydomain.local и порт 3128.

Краткая инструкция по настройки прокси есть в отдельной статье тут.

На этом всё, комментарии, исправления и дополнения приветствуются.

Источник