Аутентификация и авторизация squid (basic, Digest, NTLM, negotiate)

5 марта, 2012 Рубрики: Active Directory, Linux, SQUID, Настройка сервера Linux

Приветствую всех, гостей и постоянных читателей блога. Сегодня попробую изложить информацию о методах аутентификации в 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%\policies\PolicyDefinitions\, а mozilla.adml – в %logonserver%\sysvol\%userdnsdomain%\policies\PolicyDefinitions\en-US\.
Если используется локальное хранилище административных шаблонов, то mozilla.admx кладется в каталог %systemroot%\PolicyDefinitions\, а mozilla.adml – в %systemroot%\PolicyDefinitions\en-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_templates\windows\admx, из данного каталога кладем файлы административных шаблонов…:

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

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

Т.к. данная настройка расположена в конфигурации пользователя, то и применяться будет к пользователям, расположенным в текущем подразделении OU, к которому будет применен Объект групповой политики. Кроме настроек прокси, браузер Crome поддерживает еще много настроек, о которых можно почитать в скачанном архиве в файле policy_templates\common\html\ru\chrome_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/[email protected]
      ├─squid_kerb_auth,14080 -s HTTP/[email protected]
      ├─squid_kerb_auth,14081 -s HTTP/[email protected]
      ├─squid_kerb_auth,14082 -s HTTP/[email protected]
      └─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:\Windows\system32>ktpass.exe /princ HTTP/[email protected] \
/mapuser [email protected] /crypto ALL /ptype KRB5_NT_PRINCIPAL \
/pass +rndpass /out C:\tmp\squid.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:\tmp\squid.keytab:
Keytab version: 0x502
keysize 54 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0
x1 (DES-CBC-CRC) keylength 8 (0x2c3b98e6e052ef15)
keysize 54 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0
x3 (DES-CBC-MD5) keylength 8 (0x2c3b98e6e052ef15)
keysize 62 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0
x17 (RC4-HMAC) keylength 16 (0x85a6dea042798a45a547f8450e1115fc)
keysize 78 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0
x12 (AES256-SHA1) keylength 32 (0x4c7b89004af3a67866db313e05592568995e31ce4554ef
a695532300bb2aca7c)
keysize 62 HTTP/[email protected] 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/[email protected]

Valid starting     Expires        em    Service principal
02/29/12 11:20:24  02/29/12 21:20:24  krbtgt/[email protected]
        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/[email protected]
# сколько параллельных потоков запускать для обслуживания аутентификации клиентов
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? [email protected] 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? [email protected] DIRECT/173.194.69.100 -

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

squid ~ # cat /etc/squid3/usersallow
[email protected]
[email protected]
...
[email protected]
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? [email protected] 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/[email protected]
 # сколько параллельных потоков запускать для обслуживания аутентификации клиентов через 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/[email protected]

добавить ключ -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!

Другие материалы в категории Настройка сервера Linux

Теги: Active Directory, Debian, kerberos, Linux, SQUID

Оставить комментарий | Trackback

148 комментариев к “Аутентификация и авторизация squid (basic, Digest, NTLM, negotiate)”

Anber

10 марта, 2012 at 23:31

1

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

Reply
- Mc.Sim
  
  11 марта, 2012 at 02:28
  
  2
  
  Спасибо. Приходите еще!!!
  
  Reply
zhum

12 марта, 2012 at 14:22

3

респект автору. Многое прояснил. На самом деле куча топиков на тему, но не многие (если не все) комментируют подробно тот или иной параметр.

p/s Пошел дальше ковырять аутентификацию через kerberos.

Reply
- Mc.Sim
  
  12 марта, 2012 at 16:35
  
  4
  
  пожалуйста!
  Приходите еще
  
  Reply
Павел

14 марта, 2012 at 09:22

5

Здравствуйте Mc.Sim.
Меня мучает вопрос,а можно ли использовать 2 вида аутентификации?
Пример:
Часть пользователей могут быть членами домена и будут авторизовываться через Negotiate.
А остальные участники ipad’s,iphone’s,mac book’s,Windows Vista Home Basic. Соответственно они все не могут быть членами домена и их авторизовать через Basic

Reply
- Mc.Sim
  
  14 марта, 2012 at 22:38
  
  6
  
  можно. я попробовал использовать negotiate и basic, но при использовании данной схемы – пользователям довольно часто вываливается окно с логином/паролем, которое можно игнорировать, нажав ок\отмена, но это сообщение несколько напрягает…
  поэтому пока только на negotiate использую.
  
  Reply
Павел

15 марта, 2012 at 07:11

7

Спасибо Mc.Sim.
Значит буду экспериментировать

Reply
- zhum
  
  16 марта, 2012 at 15:35
  
  8
  
  Павел,
  такую схему я тоже пытаюсь реализовать. Я включил 2 вида аутентификации, negotiate и basic. Через керберос у меня все отрабатывает корректно.
  А вот с компами которые не в домене действительно проблема. Как упомянул Mc.Sim, там окошко выскакивает, при чем на разных броузерах по разному. Если не включать “auth_param negotiate keep_alive on” то IE8 на компе вне домена не переключается на basic. А mozilla переключается и выдает приглашение на basic но при этом в логах скуид ругань типа:
  squid_kerb_auth: WARNING: received type 1 NTLM token
  2012/03/16 17:29:43| authenticateNegotiateHandleReply: Error validating user via Negotiate. Error returned ‘BH received type 1 NTLM token’
  
  такое ощущение что на самом деле не basic а ntlm включается на стороне броузера.
  
  Reply
Mc.Sim

8 апреля, 2012 at 23:22

9

Добавил отличную книгу в раздел что еще почитать

Reply
sinder

15 мая, 2012 at 12:13

10

Отлично написанная статья, да и сам блог при первом пролистывании интересен. Буду время от времени почитывать, спасибо за труд.

Reply
pwthrash

18 июня, 2012 at 00:32

11

Уже неделю бьюсь с авторизацией Сквида в AD. Все настроил, как в статье, с помощью kinit получаю тикет как с кейтабом, так и без. Однако когда, доходит дело до авторизации пользователей, в access логе нет никакой информации о каких-либо учетных записях… Уже не знаю куда копать. Днс работает корректно…

Reply
- Mc.Sim
  
  19 июня, 2012 at 20:34
  
  12
  
  ну показывайте команду:
  # kinit -V -k -t /путь/к/созданному/кейтаб HTTP/свой_SPN.имя.домена
  Естественно, HTTP/squid.domain.local – зменить на свое.
  После вышеуказанного kinit, выполните klist и тоже покажите вывод.
  
  Reply
ppp

25 июня, 2012 at 19:31

13

mai e cool

Reply
Константин

11 июля, 2012 at 09:13

14

Отличная статья. Многое стало понятно.
Делаю данную связку на gentoo (squid) и Windows 2008 (dhcp dns AD)
Создал тикет. С помощью kinit проверяю его, все ОК.
Но, при попытке выйти на какой либо сайт – в cache.log сыпется
Error validating user via Negotiate. Error returned ‘BH received type 1 NTLM token’ если на виндовой машине, на линуксовой вообще тишина. (сеть гетерогенная)
В параметрах, прокси для браузера указан именем (CNAME) proxy.urban.ru порт 3128. Если указываем FQDN та же петрушка.
В АД, в ДНС службе прописана прямая и обратная зона для прокси сервера и CNAME.
С любого компа в домене при команде host или nslookup получаем ip адресс или FQDN имя.
Решил отказаться от NTLM авторизации из-за 407 ошибок в логах и долгово открытия страниц(контент грузится быстро, но сами страницы открываются долго).

Вывод kinit -V -k -t ./proxy.keytab HTTP/proxy.urban.ru :
Using default cache: /tmp/krb5cc_0
Using principal: HTTP/[email protected]
Using keytab: ./proxy.keytab
Authenticated to Kerberos v5

Конфиг krb5.conf
[logging]
default = FILE:/var/log/krb5.log

[libdefaults]
default_keytab_name = /etc/squid/proxy.keytab
ticket_lifetime = 24000
clock_skew = 300
default_realm = URBAN.RU
dns_lookup_realm = no
dns_lookup_kdc = no

[realms]
URBAN.RU = {
kdc = dc1.urban.ru
admin_server = dc1.urban.ru
default_domain = URBAN.RU
}

[domain_realm]
.urban.ru = URBAN.RU
urban.ru = URBAN.RU

При использовании утилиты /usr/libexec/squid_kerb_auth_test dc1
Выдает зашифрованную тарабарщину токена.

У вас не встречалось такой проблемы ?

Reply
- Mc.Sim
  
  14 июля, 2012 at 14:46
  
  15
  
  Приветствую, Константин. Данная ошибка у меня появлялась, когда я на клиенте указывал прокси в виде IP.
  На самом деле использовать CNAME при Kerberos аутентификации – неправильно. Я тоже сталкивался с данной проблемой, когда самбу вводил в домен. Если пользователь обращался к файловому серверу по CNAME, то АД его не пускал.
  В Вашем случае я могу посоветовать удалить в DNS и AD все А и CNAME записи, по новой ввести squid в домен, создать тикет и не использовать cname. ))
  
  Reply
Константин

14 июля, 2012 at 15:27

16

Здравствуйте. Как я уже писал. я пробовал и по CNAME и по FQDN. С FQDN начал в первую очередь, удалял все записи в ДНС, прямые и обратные, а также выводил комп из домена с помощью самбы. Все равно выдавал такую же ошибку. ((

Reply
- Mc.Sim
  
  29 июля, 2012 at 12:38
  
  17
  
  Константин, если еще актуально. То давайте конфиг сети машины, на которой крутится линух, конфиг самого линуха и сетевые параметры домена. Попробуем завести.
  
  Reply
  - Константин
    
    14 августа, 2012 at 09:32
    
    18
    
    Я сейчас вернул NTLM аутентификацию, так как начальство требует результатов. По ней корректно пока бродит.
    Но, конечно, хотелось бы отказаться от костыля в виде winbind.
    Есть подозрение, что под виндой у меня не заработало, так как в качестве клиента юзал вин 2003 (то, что под рукой было, хотя стоило взять семерку). А вот под клиентом линуха, введенного в домен like-wise или самбой в логах вообще тишина была. Или для линуха нужно было еще корректно керберос на клиентской машине настроить ?
    
    Настройки сети машины со SQUID
    
    vlan505 = внешний ip
    vlan1905 = 192.168.5.5
    
    Сетевые параметры домена:
    eth0 = 192.168.5.1
    
    Конфиг самого линуха – какие параметры требуются ?
    
    Reply
    - Mc.Sim
      
      24 августа, 2012 at 18:32
      
      19
      
      Доброго времени, Константин.
      Совсем последнее время нет времени на блог. Сори за поздний ответ, надеюсь, что еще актуально )
      Да, вин 2003 я не могу с какой-то уверенностью сказать, что заработает… Хотя это тот же WinXP, но кто его знает… На время тестов советую использовать десктопные дистрибутивы в качестве клиентов. Как заработает, потом уже тестить остальные. С Linux клиентом, боюсь, что пользователю придется вручную вводить доменный пароль… Что-то я мало представляю, как линуксовый браузер прикрутить к доменной аутентификации…
      В общем, для начала советую поднять linux на виртуалке, например на бесплатном VirtualBOX, а когда заработает – повторить опыт на продакшен железяке.
      Я всегда так делал. Только между этими 2мя опытами был третий – статья на блоге )
      Но в целом, чтобы сделать какую-то диагностику, необходимы конфиги:
      hosts
      hostname
      resolv.conf
      nsswitch.conf
      конфиги сетевых интерфейсов
      конфиги службы или скрипта, который синхронизирует время с контроллером домена
      squid.conf
      krb5.conf
      
      А так же, параметры домена:
      имя домена
      IP
      
      Reply
Владимир

21 августа, 2012 at 08:46

20

Добрый день.
Делаю по инструкции с небольшими изменениями (в сети домен на Windows 2003), давал команду
ktpass /princ HTTP/[email protected] /mapuser [email protected] /crypto RC4-HMAC-NT /ptype KRB5_NT_PRINCIPAL /pass +rndpass /out C:\squid.keytab

До этого момента ошибок небыло, сейчас застрял на проверке
kinit -V -k -t /etc/squid3/squid.keytab HTTP/squid-01.OBR.DOMAIN.RU , выдает
Using default cache: /tmp/krb5cc_0
Using principal: HTTP/[email protected]
Using keytab: /etc/squid3/squid.keytab
kinit: Client not found in Kerberos database while getting initial credentials
Можете что-нибудь посоветовать?

Reply
- Mc.Sim
  
  24 августа, 2012 at 18:55
  
  21
  
  Доброго времени, Владимир.
  Я бы посоветовал:
  1. изменить ключ -crypto на значение ALL
  2. дайте вывод данной команды (ktpass) сюда
  3. дайте скриншот учетки squid-01.OBR.DOMAIN.RU в домене
  4. … хм.. пока все )
  
  Reply
Владимир

5 сентября, 2012 at 16:03

22

Mc.Sim
Еще раз здравствуйте и спасибо за ответ. Со своей проблемой разобрался: создал keytab с помощью утилиты mkstutil, а в squid3.conf команда
auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -s HTTP/[email protected] с добавленным ключем -d не давала авторизовыватся пользователям (просила логин и пароль для пользователя в домене), как только ключ убрал, так получилось выйти в интернет.

Reply
- Mc.Sim
  
  6 сентября, 2012 at 20:49
  
  23
  
  Рад, что все получилось.
  
  Reply
Роман

14 сентября, 2012 at 11:10

24

Здравствуйте!! Огромное спасибо за эту отличную статью!! Все получилось! Вы молодец!

Reply
- Mc.Sim
  
  17 сентября, 2012 at 14:34
  
  25
  
  Доброго времени. Рад, что получилось. Приходите еще )
  
  Reply
Александр

3 октября, 2012 at 15:58

26

Спасибо огромное, все получилось, единственная проблема была с авторизацией в домене, тут лиюо у вас ошибка, либо я, что то не так сделал.
У вас следующий вариант:
auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -s HTTP/[email protected]
На который была ошибка – authenticateNegotiateHandleReply: Error validating user via Negotiate. Error returned ‘BH received type 1 NTLM token’

А заработало следующим образом-
auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -s HTTP/squid.domain.local
т.е. отделил @DOMAIN.LOCAL

Но в итоге спасибо огромное, все очень четко и доходчиво извложено!

Reply
- Mc.Sim
  
  3 октября, 2012 at 16:00
  
  27
  
  Пожалуйста, Аленксандр.
  Вы не первый с данной ошибкой обращаетесь. Я пока зависимости не нашел, от чего данная ошибка возникает… У меня работало как HTTP/[email protected].
  Приходите еще!
  
  Reply
Александр

3 октября, 2012 at 16:03

28

А вас нет статьи, желательно вашей, про интеграцию squid3 с доменными группами?

Reply
- Mc.Sim
  
  3 октября, 2012 at 16:48
  
  29
  
  https://www.k-max.name/linux/squid-auth-kerberos-ldap-grupp-active-directory/
  
  Reply
Дмитрий

1 ноября, 2012 at 14:57

30

Mc.Sim
Вы не могли бы дать свои контакты? настраиваю похожую схему и у меня есть проблемы, хотел посоветоваться, а то переписка в комментариях долгое дело.

Reply
korven

12 декабря, 2012 at 08:29

31

Здравствуйте, отличная статья, думаю нужно знать некоторые полезные команды при настройке squid:
после редактирования конфига обязательно используйте вот эту команду: squid -k parse, она проверит файл на наличие синтаксических ошибок. Для того, чтобы squid применил внесенные в конфиг изменения без перезапуска самого “себя”)), т.е просто перечитал свой конфиг и применил изменения, делаем так:

squid -k reconfigure.

Я кстати написал о том, как я настраивал squid на работы с AD вот ссылка _ttp://www.artcom-ufa.ru/posts/2012/07/28/nastroika-squid

Reply
- Mc.Sim
  
  19 декабря, 2012 at 17:38
  
  32
  
  korven, приветствую.
  Данные команды описаны в статье вводный пост squid.
  Спасибо за коммент.
  
  Reply
Сергей

23 января, 2013 at 16:45

33

Спасибо, всё по полочкам расписано

Reply
Dre

6 февраля, 2013 at 16:53

34

Привет, все отлично расписано! респект! только вот есть вопрос, можешь подсказать анализатор логов squid’a с авторизацией AD, желательно в реальном времени(можно и без этого), с графиками(начальство требует) и поддержкой имен пользователей на кириллице?

Reply
- Mc.Sim
  
  17 февраля, 2013 at 22:22
  
  35
  
  Привет. Мне приходилось настраивать lightsquid, т.к. в Debian он ставится максимально просто. Графики он строит на основании расписания, заданного в cron. доменных пользователей отображает в том виде, в каком они попадают в логи (у меня пользователи все были заведены на английском, поэтому если нужен русский, то нужно будет поприседать с настройкой кодировок). Авторизацию можно настроить силами веб-сервера.
  
  Reply
Павел

20 марта, 2013 at 11:44

36

Добрый день. настроил все согласно статье, но в инет не пускает – показывает окошко ввода логина и пароля. В браузере в настройках прокси – fqdn имя (squid.domain.local.)
В логах cash’a – authenticateNegotiateHandleReply: Error validating user via Negotiate. Error returned ‘BH gss_acquire_cred() failed: Unspecified GSS failure. Minor code may provide more information. ‘ (c ключом -d так же)

Команда kinit -V -k -t /etc/squid3/squid.keytab HTTP/squid.domain.local возвращает
Authenticated to Kerberos v5

Не пойму в чем проблема..

Reply
- Mc.Sim
  
  20 марта, 2013 at 22:51
  
  37
  
  Приветствую, Павел.
  Можно увидеть права доступа на файл
  /etc/squid3/squid.keytab
  ?
  
  Reply
Павел

21 марта, 2013 at 13:35

38

У меня ubuntu 12.04 права Proxy:proxy rw — –. Кажется я что то не учел. Схема домена и леса 2003, хотя контроллеры домена WS2008R2.
То что у меня проходит тест kinit означает что krb5.conf настроен верно?
Подскажите, какие минусы у NTLM авторизации и почему Samba\WinBIND это плохо? Можно ли реализовать NTLM авторизацию без Samba?

Reply
- Mc.Sim
  
  21 марта, 2013 at 20:18
  
  39
  
  У меня ubuntu 12.04 права Proxy:proxy rw — —. Кажется я что то не учел. Схема домена и леса 2003, хотя контроллеры домена WS2008R2.
  
  Думаю, что это не есть причина ошибки…
  
  То что у меня проходит тест kinit означает что krb5.conf настроен верно?
  
  Скорей всего да )
  
  Подскажите, какие минусы у NTLM авторизации и почему Samba\WinBIND это плохо? Можно ли реализовать NTLM авторизацию без Samba?
  
  о минусах NTLM я писал в статье о самба. В двух словах – хеши паролей, которые передаются по сети – легко подбираемы бутофорсом. Это не безопасно, особенно учитывая что есть Kerberos. Кроме того, для настройки через samba – необходимо еще и samba ставить, что может потребовать открытия ненужных портов на сервере.
  
  можно увидеть вывод команд
  # cat /etc/default/squid3
  # ps aux | grep squid
  # ls -la /etc/squid3
  ?
  
  Reply
Павел

21 марта, 2013 at 20:34

40

Mc.Sim, не знаю что за чудо произошло, но с 4 попытки все заработало.
Спасибо за оперативные ответы и помощь.

Reply
- Mc.Sim
  
  21 марта, 2013 at 21:05
  
  41
  
  ну отлично.
  Приходите еще )
  
  Reply
Павел

2 апреля, 2013 at 18:18

42

Mc.Sim, будь добр, объясни:
Есть контроллер домена, есть сквид с авторизацией, клиент и интернет.
Клиент хочет получить доступ в интернет, попадает на сквид, где есть правило, что в интернет он пустит только тех, кто принадлежит группе inet. Squid получает необходимые учетные данные пользователя, обращается к контроллеру домена, который подтверждает, что пользователь является членном домена и группы inet.Squid пропускает трафик пользователя в интернет и обратно. Все ли верно?

Если так то не могу понять, каким образом авторизация на моем сквиде (который в моем представлении просто ворота “представся перед тем как пройти”) связана с ресурсами в интернете? например синхронизация evernote не поддерживает авторизацию сквида

Reply
- Mc.Sim
  
  3 апреля, 2013 at 21:26
  
  43
  
  Сумбурно….
  Если я правильно понял, вопрос в следующем: как будут работать такие приложения, как evernote со сквидом?
  Большая часть приложений, которая работает по http или другому web-протоколу, если не имеет настроек прокси, то использует настройки IE.
  Но не исключен вариант, что некоторые приложения откажутся работать с kerberos.
  У меня такое было со старым сбербанковским клиентом.
  В данном случае необходимо выяснить на какие адреса пытается подключиться клиентское ПО и создать соответствующий acl и разрешающий http_access без аутентификации.
  
  Reply
Павел

3 апреля, 2013 at 09:33

44

Проблема в том что некоторые сервисы возвращают 407 ошибку. Рекомендуют делать так: http://www.buseng.ru/blog/2010/07/webrequest-cherez-proksi/ но что конкретно менять я не понимаю

Reply
- Mc.Sim
  
  3 апреля, 2013 at 21:28
  
  45
  
  это код для тех, кто пишет программы )
  решение я предложил в комменте выше )
  
  Reply
Андрей

8 мая, 2013 at 16:43

46

Здравствуйте. От решения с авторизацией в группах AD вернулся сюда. Итак, ошибка как и у всех вручную авторизация KERBEROS проходит а пользователи не могут авторизоваться. Методом проб и ошибок вот что получилось: (может кого натолкнет на мысль почему это так и как с этим бороться). Подключил второй IP адрес к карте и обращаюсь по нему. Все работает. Но меня это не устраивает тк не понимаю почему и не могу двигаться дальше к отказоустойчивому решению.
140 адрес основной:
/etc/hosts

191.168.3.138 sag011-nk sag011-nk.domain.com
191.168.3.139 sag012-nk sag012-nk.domain.com
191.168.3.140 sag01-nk sag01-nk.domain.com
127.0.0.1 localhost
127.0.1.1 sag01-nk

auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address +.211.+.125
netmask 255.255.248.0
gateway +.211.+.121
auto eth1
iface eth1 inet static
address 191.168.3.140
netmask 255.255.240.0
network 191.168.0.0
dns-nameservers 191.168.3.100 191.168.3.101 127.0.0.1 8.8.8.8
dns-domain domain.com
dns-search domain.com
auto eth1:1
iface eth1:1 inet static
address 191.168.3.138
netmask 255.255.240.0

ktpass /princ HTTP/[email protected] /mapuser [email protected] /crypto ALL /pass squidpass /ptype KRB5_NT_PRINCIPAL /out c:\KRB5.keytab_01
/etc/squid3/squid.conf
visible_hostname sag01-nk
http_port 191.168.3.138:8080
http_port 191.168.3.139:8080
http_port 191.168.3.140:8080

auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -s HTTP/sag01-nk.domain.com
auth_param negotiate children 15
auth_param negotiate keep_alive on
acl auth proxy_auth REQUIRED
http_access allow auth

Так вот, если в настройках браузера пишу sag01-nk.domain.com – то возникает ошибка авторизации как у всех. Если пишу sag011-nk.domain.com – все работает.
Кто нибудь может сказать почему так происходит?

root@sag01-nk:/temp/FilesG1# kinit -V -k -t /etc/krb5.keytab_01 HTTP/[email protected]
Using default cache: /tmp/krb5cc_0
Using principal: HTTP/[email protected]
Using keytab: /etc/krb5.keytab_01
Authenticated to Kerberos v5
root@sag01-nk:/temp/FilesG1# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: HTTP/[email protected]

Valid starting Expires Service principal
08.05.2013 15:40:39 09.05.2013 01:40:39 krbtgt/[email protected]
renew until 09.05.2013 15:40:39

Reply
- Mc.Sim
  
  8 мая, 2013 at 21:49
  
  47
  
  Так, давайте по порядку….
  Зачем Вы используете 2 хостнейма? Зачем 2 IP?
  Настройте все снова (обязательно почистите все DNS записи для squid в AD) с одним IP 191.168.3.140 и хостнеймом sag01-nk sag01-nk.domain.com.
  
  И так, до кучи вопрос: почему вы используете не локальные адреса (191.х.х.х) в локальной сети?
  
  Reply
Андрей

10 мая, 2013 at 11:13

48

Изначально план был следующий: сделать 2 независимых сервера со своими IP полностью работающими это 138 и 139 адрес. Поэтому делал каждаму независимую авторизацию свой Keytab. Добился что оба сервера работали независимо и клиентам можно было обращаться к любому по fqdn имени. Потом поставил на них CARP и объединил их в 140 адрес. Те менял 138 или 139 на 140. Цель – чтоб клиенты обращались по одному имени. поэтому в DNS 3 записи. без групп AD все работало. По очереди вынимал сетевые кабели, сервера автоматом переключались. После ввода доступа по группам, 140 адрес перестал отвечать. По отдельности они работали и права по группам разграничивались. Во тут начались танцы с бубнами. А бубна хорошего нет (опыта). Потом я решил по вашему совету изменить идеологию и сделал 2 абсолютно одинаковых сервера с 1 keytab и оба настроил на 140 адрес как основной а 138 и 139 присвоил как вторичные на эту сетевую соответственно, для возможности удаленного управления (сервера стоят далеко и таскать их все время трудно). но теперь другая проблема. Не работает доступ по 140 (когда я пишу 140 – у клиентов конечно пишу полное fqdn имя соответствующее этому адресу). но что интересно по 138 все работает. Я подумал, что что то со 140-м адресом и сделал основным 139. Теперь по 140 стало пускать а по 138 нет авторизации KERBEROS. Хотя ручные тесты проходят. Клиенты в группах опрелеляются и KERBEROS авторизует. Вот тут я больше не знаю что делать. Да, пользователей у меня тоже 3. Такое ощущение, что когда я авторизуюсь пользователем на которого сделан Keytab авторизация именно squid не работает. а когда я обращаюсь к серверу по другому ip и соответственно имени (например все настройки сделаны на 140 и sag01-nk…. ) а обращаюсь к нему 138 – те sag011-nk -висил как второй ip на этой же карте) то работает. Но при таком варианте не знаю как это все carp ом объеденить. Наверное вы правы. Нужно все сделать с начала. Сервера у меня настраиваются с помощью скриптов путем копирования файлов конфигураций. DNS не чистил. Думал что с теми записями сделается. По локально сети – В сети порядка 600 компов. Сити разбиты по диапазонам 191.168.1.0/20 коммутаторы 191.168.3.0/20 сервера 191.168.6.0/20 пользователи vip и т.д. 192.168…. у нас адреса на филиалах. Сеть одна. Так придумали чтоб получить больше пользователей и не путаться. Делал не я. Идеологию построения сети придумал конструктор.

Reply
Андрей

11 мая, 2013 at 07:41

49

попрбую еще покопать в сторону DNS. У меня в AD 3 записи, прямые и обратные и локально поднят bind9 на нем тоже прописаны прямые и обратные зоны (так было в примере на курсах когда создавали отказоустойчивый гейт). Может быть локально DNS сервер вооще не нужен. Может он что чудит?

Reply
- Mc.Sim
  
  17 мая, 2013 at 14:08
  
  50
  
  Опишу более подробно свой план, чтобы было понятно…
  AD очень капризна к наличию корректной и единственной для одного хоста PTR и A записям. Если создать к одному хостнейму несколько А-записей или к одному IP несколько PTR записей, то Kerberos корректно и стабильно работать не будет. Это 99% гарантированно!
  При этом, я сомневаюсь, что заработает Kerberos, если из одного сервера переткнуть провод в другой с аналогичными настройками. Т.к. во время обращения пользователей к squid, часть системы Linux, которая отвечает за взаимодействие с Kerberos обменивается с AD некоторыми ключами шифрования. Среди этих ключей имеется и сессионные.
  Соответственно, рассматривая ситуацию, когда пользователь установил соединение с squid и обменивается данными, при этом канал переключается на другой сервер. Я на 99% уверен, что эта сессия окажется неработоспособной.
  Поэтому, я предложил сделать 2 сервера с одинаковыми IP адресами и настройками по очереди и вручную переключить провод из одного уже работающего в другой работающий (это как бы ручная эмуляция CARP, то есть переключаясь вручную, мы избавляем себя от гипотетически возможных проблем с технологией CARP). Тем самым я хотел чтобы вы проверили насколько критичен будет перерыв в работе пользователя уже установившего сеанс.
  Не углубляясь в Kerberos, тут трудно спрогнозировать поведение клиентского компьютера, squid и AD.
  При этом, пользователи обратившиеся к новому (переключенному) squid скорее всего корректно заработают.
  Когда Вы сделали 2 IP на один хостнейм ( 139 и 140), еще и настроили на каждый IP Kerberos, вы тем самым создали себе лишние “точки отказа” и трраблшуттинга, чтоли…
  Нужно по максимуму сузить круг диагностики до минимального количества взаимодействующих технологий. Тогда будет проще выявить проблему.
  Как-то так. Надеюсь. что понятно передал мысль.
  
  Reply
Андрей

20 мая, 2013 at 14:42

51

Еще один вопрос. Для настройки авторизации по KERBEROS нужно ли компьютер вводить в домен? Или достаточно в AD прописать его имя? И еще при регистрации (ручной) в AD компьютера (linux) у меня остается пустое не заполненное поле: DNS имя компьютера. Может ли это повлиять на успех авторизации?

Reply
- Mc.Sim
  
  20 мая, 2013 at 16:20
  
  52
  
  На шаге “2.4. Создание keytab-файла на контроллере домена Windows 2008 R2 ” мы делаем это “Перед созданием ключевого файла необходимо создать учетные записи для хостов (сервера и клиента) NFS, соответствующие именами хостов:”. Это и есть т.н. “вводить в домен”.
  Вот этой фразы я не понял: “при регистрации (ручной) в AD компьютера (linux) у меня остается пустое не заполненное поле: DNS имя компьютера.”. Что в данной фразе понимается под “регистрации (ручной) в AD компьютера (linux)”?
  
  Reply
Андрей

20 мая, 2013 at 19:32

53

По поводу ввода компьютера в домен. Когда я в AD создаю учетную запись для хоста, поле DNS имя компьютера остается незаполненным. Заполнить его вручную не могу. Но вот сегодня ввел сервер в домен при помощи Samba + winbind то поле заполнилось FQDN записью. Правда это мне не помогло.

Сейчас иду сначала. Все вроде настроил. 1 хост машина. Одна запись в DNS ptr и A. Авторизация KeyTabom проходит.
kinit -V -k -t /etc/krb5.keytab HTTP/[email protected] пишет об удачной аутентификации. А squid не хочет авторизоваться в домене.
Using default cache: /tmp/krb5cc_0
Using principal: HTTP/[email protected]
Using keytab: /etc/krb5.keytab
Authenticated to Kerberos v5

SQUID:
/etc/init.d/squid3
KRB5_KTNAME=/etc/squid3/HTTP.keytab
export KRB5_KTNAME
auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -s -d HTTP/[email protected]
auth_param negotiate children 15
auth_param negotiate keep_alive on

acl auth proxy_auth REQUIRED
http_access allow auth

Подскажите где искать, как промониторить ошибку. Из лог файла видно что не проходит авторизация:
1369061937.316 0 191.168.6.90 TCP_DENIED/407 3723 CONNECT http://www.google.com:443 – NONE/- text/html
1369061938.128 22 191.168.6.90 TCP_DENIED/407 4770 POST http://mc.yandex.ru/webvisor/1103813? – NONE/- text/html

Reply
Андрей

20 мая, 2013 at 19:34

54

я там кое где пропустил и не заменил свой домен на domain. Это не ошибка. В исходниках везде стоит вместо domain – centravis. те это не ошибка. вернее ошибка не в этом

Reply
Андрей

22 мая, 2013 at 10:07

55

И еще скажите пожалуйста, может ли влиять на авторизацию то, что я создаю принципала примапленного к учаетной записи пользователя а не компьютера. Я читал гдето что даже рекомендуют мапится именно к уч записи пользователя.

Reply
- Mc.Sim
  
  22 мая, 2013 at 22:54
  
  56
  
  Андрей, если бы Вы почитали по моему совету статью о Kerberos + NFS, то нашли бы там ответ на свой вопрос )
  Цитирую:
  
  Хочется отметить еще вот такой нюанс: на контроллере домена возможно привязать несколько SPN к однойучетной записи, но это может привести к некоторым проблемам, поэтому я бы не советовал этого делать. Пример такой проблемы хорошо раборали товарсчи с форума ixbt. Кроме того, в сети идет много дебатов о том, привязывать SPN к учетной записи компьютера или к учетной записи пользователя, некоторую полезную информацию об этом можно найти тут.
  
  Еще, некий alex в своей статье немного дополнил данную дискуссию своими аргументами.
  
  Reply
Андрей

22 мая, 2013 at 15:21

57

Коллеги моей радости как и тупости нет предела. Какие дурацкие ошибки иногда бывают. Хочу поделиться, может кто будет идти по стопам и не ошибется. Началось все с того что настроил 2 сервера со Squid и пытался на их базе построить отказоустойчивое решение. Все уже почти заработало но вот с какого то момента перестала работать доменная авторизация по KERBEROS. Что я только не делал. С DNS c keytabom и пр… потерял 2 недели. Вручную авторизация как часы а squid не хочет. Оказалось при очередной итерации в конфиг squida добавил опцию -d в параметры авторизации которая говорит ему быть разговорчевее.
auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -d -s HTTP/sag01-nk…
Но нигде не было написано что ставить эту опцию нужно до параметра -s который как оказалось (посмотрел в /usr/lib/squid3/squid_kerb_auth -h) указывает на SPN запись. Вот как все просто. А в логах ничего не было. Все копаю дальше. Готов поделиться готовым решением, в случае если все получится. Отказоучтойчивый squid это круто…. я думаю.

Reply
Андрей

22 мая, 2013 at 20:13

58

Отчитываюсь о проделанной работе. Сделал 2 сервера с одинаковыми IP адресами и настройками и по очереди вручную переключа провод из одного уже работающего в другой работающий (это как бы ручная эмуляция CARP). Перерыв в работе пользователя около 5 сек и связан со временем инициализации порта на коммутаторе Cisco. Как только порт поднялся интернет сразу есть и авторизация работает. Что мне делать дальше? Думаю попробовать одному интерфейсу подкинуть второй IP адрес для удаленного управления серверами, хотя может не получиться. Вы писали что при удалении основного, вторичный тоже удаляется. А мне нужно будет их по очереди гасить чтоб не было конфликтов IP адресов. Вставить 3-ю сетевую карту? Прошу совет.

Reply
- Mc.Sim
  
  22 мая, 2013 at 23:08
  
  59
  
  Далее, настроить попробовать настроить CARP.
  Его необходимо настроить так, чтобы Ваш “одинаковый IP” был “публичным IP” для CARP, и на каждой сетевушке был по одному служебному.
  Но служебные IP не должны быть задействованы в Kerberos’e. Как-то так…
  Наверно, стоит предоставить конфиг сюда, чтобы можно было убедится, что описанная схема правильно понятна )))
  
  Reply
- Mc.Sim
  
  22 мая, 2013 at 23:09
  
  60
  
  АХ да, и спасибо за описание. Будет интересно потом самому такую схему опробовать, если все у Вас получится )
  
  Reply
Андрей

29 мая, 2013 at 10:30

61

Добрый день. Итак описываю текущую ситуацию. Работают 2 абсолютно одинаковых сервера с адресом 191.168.3.140. Работает аторизация KERBEROS и разграничение доступа в соответствии с расположением клиентов в разных доменных группах. Задача – объеденит 2 сервера и сделать отказоустойчивое решение. Попробовал серверам назначить адреса 138 и 139 соответственно а 140 будет виртуальным подставляемым. Попробовал не работает авторизация на виртуальном интерфейсе. Остановился на следующем. Основной адрес у обоих 140 и дополнительные 138 и 139 соответственно для управления этими серверами. Объединил CARP. Все работает за исключением: 1. при переключении если обновлялась страница то соединение теряется и нужно обновить страницу. Это не страшно. Пользователи даже не заметят. 2. SQUID перестал сам запускаться. Вручную service squid3 restart и дальше все работает до перезагрузки. В чем дело не могу понять. Такое ощущение что интерфейс не успевает поднятся и Squid не может к 140 подвязаться http_port 191.168.1.140:8080. Добавляю запуск Squid при каждом поднятии интерфейсов с помощью скрипта. Решение мне не очень нравится. Может подскажите где еще поискать. Скрипты ниже:
/etc/network/interfaces
auto lo
iface lo inet loopback
# eth0 будет смотреть наружу и получать интернет
auto eth0
iface eth0 inet static
address 195.211.212.125
netmask 255.255.248.0
gateway 195.211.212.121
# eth1 будет смотреть в локальную сеть
auto eth1
iface eth1 inet static
address 191.168.3.140
netmask 255.255.240.0
# pre-up iptables-restore -c < /etc/iptables.rules
up route add -net 192.168.99.0 netmask 255.255.255.0 gw 191.168.1.1
# второй IP для управления
auto eth1:1
iface eth1:1 inet static
address 191.168.3.138
netmask 255.255.240.0
# для Gate2
# iface eth1:1 inet static
# address 191.168.3.139
# netmask 255.255.240.0
/etc/squid3/squid.conf
visible_hostname sag01-nk
http_port 191.168.3.140:8080

include /etc/squid3/auth.conf
/etc/rc.local
ucarp -i eth1 -s 191.168.3.138 -v 1 -p secret -a 191.168.3.140 -u /etc/vip-up.sh -d /etc/vip-down.sh -z -B -P
# for Gate2
# ucarp -i eth1 -s 191.168.3.139 -v 1 -p secret -a 191.168.3.140 -u /etc/vip-up.sh -d /etc/vip-down.sh -z -B
/etc/vip-up.sh
#!/bin/sh
# интернет
ip addr flush dev eth0
ip addr add 195.211.212.125/21 dev eth0
# пользователи
ip addr flush dev eth1
ip addr add 191.168.3.140/20 dev eth1
# for Gate1
ip addr add 191.168.3.138/20 dev eth1
# for Gate2
# ip addr add 191.168.3.139/20 dev eth1
send_arp 195.211.212.125 `cat /sys/class/net/eth0/address` 195.211.212.125 ff:ff:ff:ff:ff:ff eth0
# маршрутизация
route delete default
route add default gw 195.211.212.121
service squid3 restart

/etc/vip-down.sh
#!/bin/sh
# интернет
ip addr flush dev eth0
# пользователи
ip addr flush dev eth1
# for Gate1
ip addr add 191.168.3.138/20 dev eth1
# for Gate2
# ip addr add 191.168.3.139/20 dev eth1
# маршрутизация
# не активный сервер ходит в интернет через активный
route delete default
route add default gw 191.168.3.140

Reply
- Mc.Sim
  
  30 мая, 2013 at 09:44
  
  62
  
  Добавляю запуск Squid при каждом поднятии интерфейсов с помощью скрипта. Решение мне не очень нравится.
  
  Чем не устраивает данное решение?
  
  Reply
Андрей

29 мая, 2013 at 15:31

63

удалось добиться работоспособности и при такой конфигурации: (убрал 2 одинаковых ip чтоб избежать конфликтов) но проблема с первоначальным запуском squid осталась:
/etc/network/interfaces
auto lo
iface lo inet loopback
# eth0 будет смотреть наружу и получать интернет
auto eth0
iface eth0 inet static
address 195.211.212.125
# for Gate 2
# address 195.211.212.126
netmask 255.255.248.0
gateway 195.211.212.121

# eth1 будет смотреть в локальную сеть
auto eth1
iface eth1 inet static
address 191.168.3.138
# for Gate 2
# address 191.168.3.139
netmask 255.255.240.0
pre-up iptables-restore -c < /etc/iptables.rules

Reply
- Mc.Sim
  
  30 мая, 2013 at 10:25
  
  64
  
  Все верно, в /etc/network/interfaces не должно быть адреса 191.168.3.140 его назначает CARP.
  Все же не пойму, почему не устраивает задержка запуска squid?
  
  Reply
Андрей

3 июня, 2013 at 12:22

65

Добрый день. В принципе такой вариант устраивает. Просто не люблю когда не понимаю как процессы работают.
Спасибо большое за помощь. Пока занимаюсь настройкой фаервола и отчетов для squid.

Reply
- Mc.Sim
  
  3 июня, 2013 at 13:00
  
  66
  
  Пожалуйста. Приходите еще.
  Спасибо Вам за предоставленное решение.
  
  Reply
apruver

15 июля, 2013 at 18:44

67

Доброго дня,сделал (базисно) все по статье.Клиент авторизуются,группы в адэ читаются,интернет раздается,есть пользователи с неограниченными правами,есть с огранниченными,все хорошо.Но,если ограниченный пользователь заходит на сайт с линками на запрещенные сайты (например VK.com) с клиентом отличным от mozilla firefox (opera,ie) у него вываливается окно авторизации,если его несколько раз закрыть,окно пропадает.Но поскольку сайтов таких много,работать невозможно только и делаешь что окна закрываешь.
можно конечно просто пересадить всех на firefox,но кмк не самое правильное решение
squid.conf icp_port 0 #cache_mem 1000 mb auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -s HTTP/[email protected] auth_param negotiate children 100 auth_param negotiate keep_alive on external_acl_type ldap_check ttl=3600 %LOGIN /usr/lib/squid3/squid_ldap_group -R -b "dc=domain,dc=local" -f "(&(objectclass=user)(sAMAccountName=%v)(memberof=cn=%a,OU=InternetGP,OU=Groups,DC=domain,DC=local))" -D "[email protected]" -W /etc/squid3/authpw -K -d -h server_name.domain.local acl inet_access external ldap_check IUsers acl inet_mail external ldap_check Musers acl all_access external ldap_check SUsers acl icq_access external ldap_check IcqUsers #acl lan proxy_auth REQUIRED 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 icq_ports port 443 563 5190 acl CONNECT method CONNECT acl auth proxy_auth REQUIRED
acl block_this url_regex -i "/etc/squid3/blocked" acl mail_list url_regex -i "/etc/squid3/maillist" acl allow_this url_regex -i "/etc/squid3/allowed" http_access allow allow_this all http_access allow SSL_ports icq_access !inet_access http_access allow mail_list inet_mail http_access allow icq_ports icq_access http_access deny block_this inet_access http_access deny block_this inet_mail http_access deny mail_list inet_access http_access allow inet_access http_access allow inet_mail http_access allow all_access
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 cache_dir ufs /var/spool/squid3 800 8 64 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 . 0 20% 4320 visible_hostname $corp Squid access$

Reply
- Mc.Sim
  
  15 июля, 2013 at 23:39
  
  68
  
  У меня была похожая ошибка.
  Я ее разбирал в статье.
  Попробуйте вместо
  http_access deny all
  указать
  http_access deny !auth all http_access deny all
  
  Reply
apruver

16 июля, 2013 at 13:47

69

Да,пробовал,тоже самое.

Reply
- Mc.Sim
  
  24 июля, 2013 at 09:56
  
  70
  
  В данном случае думаю, что поможет дебаг ACL директив.
  
  Reply
apruver

24 июля, 2013 at 13:32

71

Ок,спасибо,думаю то что нужно )

Reply
gason

6 сентября, 2013 at 14:25

72

Добрый день!

Прошу прощения, может не совсем в тему, но не подскажите ли по вопросу: в разделе “Конфигурация пользователя – Политики – Конфигурация Windows” пропал подраздел “Настройка Internet Explorer”.
Причем ранее он был, так как настроен соответсвующий объект политики.

Reply
- Mc.Sim
  
  7 сентября, 2013 at 19:53
  
  73
  
  А можно скриншот?
  
  Reply
  - gason
    
    9 сентября, 2013 at 07:17
    
    74
    
    Что то не понял как вставить скриншот.
    Если не затруднит, посмотрите, плиз, по ссылочке http://yadi.sk/d/OmeEutnE8vxMv
    
    Reply
    - Mc.Sim
      
      21 сентября, 2013 at 20:42
      
      75
      
      В данном случае рекомендуют переустановить IE на сервере.
      
      Reply
selivan

29 сентября, 2013 at 02:34

76

В качестве SPN можно указать специальное значение GSS_C_NO_NAME – тогда будет работать любой SPN из keytab, получится меньше жёстких привязок в конфигах. Это /usr/lib/squid3/squid_kerb_auth -h пишет.

З.Ы. Хорошо пишешь, приятно читать. Почему-то по никсам редко пишут статьи, где кроме конкретной последовательности шагов присутствует их объяснение, а это ведь самое важное.

Reply
- Mc.Sim
  
  26 октября, 2013 at 11:43
  
  77
  
  Спасибо за отзыв и за дельный коммент. Не знал про GSS_C_NO_NAME.
  
  Reply
Денис

16 октября, 2013 at 10:40

78

Привет.
Сделал все точно по статье. kinit отрабатывает. squid пишет:

authenticateNegotiateHandleReply: Error validating user via Negotiate. Error returned ‘BH received type 1 NTLM token’

куда копать, где смотреть?

Reply
- Денис
  
  16 октября, 2013 at 15:03
  
  79
  
  вопрос снимается.
  Была ошибка на DC
  
  KDC обнаружил повторяющиеся имена при обработке запроса проверки подлинности Kerberos. Повторяющееся имя: HTTP/v-squid-00.ksk.local (тип DS_SERVICE_PRINCIPAL_NAME). Это может привести к сбоям проверки подлинности или понижению до NTLM. Чтобы предотвратить появление подобной ситуации, удалите в Active Directory повторяющиеся записи для HTTP/v-squid-00.ksk.local.
  
  Повторяющегося имени при помощи ldp не нашел, поэтому изменил имя хоста и все заработало.
  
  Reply
  - Mc.Sim
    
    26 октября, 2013 at 12:10
    
    80
    
    Отлично, когда сам находишь причину )
    
    Reply
Анатолий

24 декабря, 2013 at 12:02

81

Добрый день!
Не могу никак реализовать схему авторизации: Kerberos + ldap.
Идея: все пользователи имеют доменные учетные записи, но не все компьютеры введены в домен (по разным причинам). Надо чтобы пользователи, которые работают на компьютерах, которые введены в домен авторизовывались прозрачно (это работает), а вот если компьютер не в домене, то нужно ввести в окошке атрибуты доступа для доменной учетной записи и получить интернет.
Буду признателен за любую помощь.
На моем сквиде с такой конфигурацией (см. ниже) работает аутентификация в домене через Керберос, кэширование ssl с динамической генерацией сертификатов.
Спасибо.
Вот мой конфиг:
proxyserver:/etc/squid3# grep -v «^#\|^$» squid.conf
auth_param negotiate program /usr/lib/squid3/negotiate_kerberos_auth -s HTTP/[email protected]
auth_param negotiate children 64
auth_param negotiate keep_alive on
auth_param basic program /usr/lib/squid3/basic_ldap_auth -D «[email protected]» -w «adminPass″ -b OU=Resources,DC=domain,DC=local -f «(&(sAMAccountName=%s)(objectClass=user))» -h 10.33.64.20 -d
auth_param basic children 10
auth_param basic realm You must use domanin account.
auth_param basic credentialsttl 1 minute
external_acl_type extldap %LOGIN /usr/lib/squid3/ext_ldap_group_acl -K -P -R -P -b «dc=domain,dc=local» -B «ou=Resources,dc=domain,dc=local» -D «[email protected]» -f «(&(cn=%a)(member=%v)(objectClass=group))» -F «samAccountName=%s» -w «proxyUserPass» -h 10.33.64.20 -v3 -S -d
acl rkdomain proxy_auth REQUIRED
acl yakimov proxy_auth [email protected]
acl SecretNet external extldap SecretNetAdmins
acl cbi_ip src 192.168.44.85/32
acl govru dstdomain .gov.ru
acl pgurkomiru dstdomain .pgu.rkomi.ru
acl vk dstdomain .vk.com
acl sberbankru dstdomain .sberbank.ru
acl mailru dstdomain .mail.ru
acl porno dstdom_regex ^.*porn.*$
acl timelist time 19:05-23:00
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 ftp_p proto FTP
http_access deny !Safe_ports
http_access allow ftp_p
http_access deny rkdomain porno
http_access deny CONNECT !SSL_ports
http_access allow rkdomain
http_access deny all
http_port 10.33.64.174:3128 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid3/Squid_proxy_server.crt key=/etc/squid3/Squid_proxy_server.key
ssl_bump none govru
ssl_bump none sberbankru
ssl_bump none mailru
ssl_bump client-first all
ssl_bump server-first all
ssl_bump none all
sslproxy_cert_error allow pgurkomiru
sslcrtd_program /usr/lib/squid3/ssl_crtd -s /etc/squid3/certs_db -M 16MB
maximum_object_size 10 MB
cache_dir ufs /var/spool/squid3 10240 16 256
access_log daemon:/var/log/squid3/access.log squid rkdomain
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 . 0 20% 4320
cache_mgr [email protected]
error_directory /usr/share/squid3/errors/Russian-1251
always_direct allow all
dns_v4_first on

Reply
- Mc.Sim
  
  27 декабря, 2013 at 09:16
  
  82
  
  Да, Анатолий, сурово вы…я бы даже сказал беспощадно…разместили прошлую версию конфига )))
  Осторожней будьте )
  По сабжу… На одной из прошлых работ я пытался реализовать примерно такую схему. Но для недоменных машин я использовал отдельную подсеть и авторизовал пользователей по acl из подсети.
  В Вашем случае, можно пойти по следующему пути: повесить squid на дополнительный порт, например 3129 и на клиентах указать прокси с этим портом. При этом, acl указать acl aclname localport 3129. И пришедших с этого порта пускать без аутентификации. Если такой вариант приемлем…
  
  Reply
  - Анатолий
    
    27 декабря, 2013 at 09:48
    
    83
    
    Спасибо за ответ. Я этот вариант уже реализовал (2 процесса squid`а слушают разные порты 3128 – Kerberos, 3129 – basic LDAP), но решил что это не путь настоящего джедая и поэтому все-таки оставил вопрос.
    
    Reply
    - Mc.Sim
      
      27 декабря, 2013 at 09:52
      
      84
      
      на самом деле, в сквиде можно найти кучу путей решения задачи. Возможности ограничены лишь фантазией )
      
      Reply
- Mc.Sim
  
  27 декабря, 2013 at 09:18
  
  85
  
  В целом, конфиг – достойный )))
  
  Reply
Mvairs

29 января, 2014 at 13:11

86

А никак использовать 1 процесс нельзя ? Кстати авторизоваться можно если подождать ~5 минут, тогда нормально аутентифицируется через керберос , просто почему то изначально он пытается аутентифицироваться через NTLM 1 token… как это обойти вопрос конечно. Причем я только браузер открываю он уже наспамит 10 ошибок до появления окна…

Reply
- Mc.Sim
  
  12 февраля, 2014 at 15:38
  
  87
  
  Можно использовать и один процесс, но такие хелперы как squid_kerb_auth могут не справиться с потоком запросов при большом количестве пользователей перестать осуществлять аутентификацию.
  
  Reply
Анатолий

30 января, 2014 at 10:15

88

Ворос решил при помощи толковой статьи на официальном сайте продукта:
http://wiki.squid-cache.org/ConfigExamples/Authenticate/WindowsActiveDirectory
Реализовал на одном порту 3 метода аутендификации (Kerberos, NTLM, Basic).

Reply
- Mc.Sim
  
  12 февраля, 2014 at 15:52
  
  89
  
  Отлично. Буду благодарен за образец конфига )
  
  Reply
Анатолий

12 февраля, 2014 at 16:17

90

Вначале рекомендую ознакомиться со статьей (http://wiki.squid-cache.org/ConfigExamples/Authenticate/WindowsActiveDirectory), т.к. помимо конфигурации squid необходимо еще совершить манипуляции с контроллером домена.

здесь мой конфиг в более понятной форме (выделен цветом и т.д.) https://github.com/diffiehellman64/configs/blob/master/squid-3128.conf
но если вдруг я когда-нибудь удалю его , читайте это:

### negotiate kerberos and ntlm authentication
auth_param negotiate program /usr/local/bin/negotiate_wrapper –ntlm /usr/bin/ntlm_auth –diagnostics –helper-protocol=squid-2.5-ntlmssp –domain=RK –kerberos /usr/lib/squid3/negotiate_kerberos_auth -s GSS_C_NO_NAME
auth_param negotiate children 32
auth_param negotiate keep_alive on

### pure ntlm authentication
auth_param ntlm program /usr/bin/ntlm_auth –helper-protocol=squid-2.5-ntlmssp –domain=RK
auth_param ntlm children 32
auth_param ntlm keep_alive on

### provide basic authentication via ldap for clients not authenticated via kerberos/ntlm
auth_param basic program /usr/lib/squid3/basic_ldap_auth -D “[email protected]” -W “/etc/squid3/squid_pass” -b OU=Resources,DC=rk,DC=local -f “(&(sAMAccountName=%s)(objectClass=user))” -h 10.33.64.20
auth_param basic children 32
auth_param basic realm Internet Proxy
auth_param basic credentialsttl 1 minute

#====================== EXTERNAL ACL =======================

external_acl_type ldap_ou %LOGIN /usr/lib/squid3/ext_ldap_group_acl_ou -K -R -P -b “ou=%g,ou=Resources,dc=rk,dc=local” -D “[email protected]” -f “sAMAccountName=%v” -W “/etc/squid3/squid_pass” -h 10.33.64.20 -v3 -S

external_acl_type ldap_group %LOGIN /usr/lib/squid3/ext_ldap_group_acl -K -P -R -P -b “dc=rk,dc=local” -B “ou=Resources,dc=rk,dc=local” -D “[email protected]” -f “(&(cn=%a)(member=%v)(objectClass=group))” -F “samAccountName=%s” -W “/etc/squid3/squid_pass” -h 10.33.64.20 -v3 -S

acl rkdomain proxy_auth REQUIRED

#======================== DOMAIN USERS =======================

#здесь я описываю acl для пользователей и групп своего домена, ну и все остальные acl

#========================= PORTS ==============================

acl SSL_ports port 443 # https
acl Safe_ports port 80 # http
acl Safe_ports port 81 # http
acl Safe_ports port 82 # 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

#====================== PROTOCOLS =============================

acl ftp_proto proto FTP

#======================= ACCESS ===============================

http_access allow ftp_proto
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow rkdomain
http_access deny all

#======================== SSL BUMP ===========================

ssl_bump server-first acl_sites_for_sslbump

#====================== LOGFORMAT ===========================
# использую изощренный формат
logformat custom %ts.%03tu | %6tr | %>a | %Ss/%03>Hs | %<st | %rm | %ru | %[un | %Sh/%h” | %{Referer}>h

#====================== LOG ==================================

access_log daemon:/var/log/squid3/access.log custom all

#===================== ICAP ==================================
#icap_enable on
#icap_preview_enable on
#icap_preview_size 128
#icap_send_client_ip on
#icap_service service_avi_req reqmod_precache 0 icap://localhost:1344/srv_clamav
#icap_service service_avi respmod_precache 1 icap://localhost:1344/srv_clamav
#icap_class class_antivirus service_avi service_avi_req
#icap_access class_antivirus allow all

http_port 10.33.64.174:3128 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid3/squid.crt key=/etc/squid3/squid.key
sslcrtd_program /usr/lib/squid3/ssl_crtd -s /etc/squid3/certs_db -M 16MB

maximum_object_size 10 MB
cache_dir ufs /var/spool/squid3 10240 16 256
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 . 0 20% 4320

cache_mgr [email protected]
error_directory /usr/share/squid3/errors/Russian-1251
#always_direct allow all
dns_v4_first on

Reply
- Mc.Sim
  
  13 февраля, 2014 at 10:08
  
  91
  
  отлично. Спасибо за конфиг.
  Указанную wiki статью я читал при написании своей статьи, но не стал ей следовать потому что:
  1. на момент написания статьи, версия msktutil, которая шла с Debian не захотела работать с 2008 R2 доменом.
  2. Я не сторонник использования NTLM, когда можно обойтись более безопасным
  3. Я не хотел использовать доменные учетки для Basic аутентификации.
  4. Я так же, не сторонник установки какого-либо софта из исходников, если можно обойтись инструментами пакетного менеджера. Ибо это в разы усложняет процесс патчинга. (я про negotiate_wrapper)
  5. Я не совсем понял, для чего туда ставится samba (видимо для работы negotiate_wrapper). Но это тоже мне очень не понравилось, ибо запускать целый сервис, когда можно обойтись без него – имхо, не совсем правильно.
  Это все, что вспомнил.
  Но учитывая, что вам нужна универсальность – решение вполне применимо.
  Дополнительно, могу порекомендовать прочитать статью: http://alex-tesla.livejournal.com/22428.html
  Тоже имеются важные нюансы.
  
  Reply
Sergey Alekseev

9 апреля, 2014 at 13:34

92

Спасибо тебе, добрый человек, за эту статью. Я как раз столкнулся с тем, что SQUID с kerberos авторизацией не обслуживает устройства вне домена и думал, что с этим делать.

Reply
Ustas

8 мая, 2014 at 13:16

93

Привет всем!
Ну хоть убей ,подскажите нубу как это победить?
authenticateNegotiateHandleReply: Error validating user via Negotiate. Error returned 'BH received type 1 NTLM token'
по
kinit -V -k -t /etc/squid3/squid.keytab HTTP/[email protected]
все проходит нормально, билет получается…
но в браузере постоянно высвечивается авторизация что не вводи – вводи все одно и тоже в лог сыпется …

Reply
- Mc.Sim
  
  24 июня, 2014 at 20:31
  
  94
  
  Какой дистибутив используете?
  Какая версия squid?
  покажите скриншот, как прописан прокси в браузере и какой браузер?
  
  Reply
harry

15 мая, 2014 at 15:55

95

Добрый день
Для начала слова благодарности Отличная статья – спасибо, все работает!
Но, интересует такой вопрос: до этого интернет раздавал через впн сервер и при поднятии интерфейса динамически задавал правила для различных tcp/udp портов (torrent’ы резал и т.п.) и резал скорость на интерфейсе ppp. Сейчас же все работает как часы, но только в браузере с настроенным прокси. Нельзя даже банально пингануть какой-либо ресурс… Плюс имеется специфический софт (клиент-банки и т.д.), у которых нет возможности задать прокси. Подскажите есть ли вариант настроить чтобы весь трафик шел через шлюз (не только http/squid) используя прозрачную авторизацию в AD…. В сторону чего смотреть?

Reply
- Mc.Sim
  
  24 июня, 2014 at 20:53
  
  96
  
  Сейчас уже очень трудно встретить софт, который не умеет пользоваться прокси сервером. Года 3 назад, когда я еще имел дело с банк-клиентами, уже тогда даже сбербанк умел обращаться к прокси, правда без аутентификации. Если ну уж очень нужно, то выход (наиболее простой) я здесь вижу только один – NAT. Но NAT – это практически неконтролируемая дыра в интернет и он не имеет никакой аутентификации. Старайтесь пускать трафик через прокси.
  
  Reply
Ажур

7 июля, 2014 at 09:49

97

Добрый день! Подскажите пожалуйста, указывал настройки прокси в уже существующей политике. Потом понял, что группы применения не подходят. Отключил в этой политике настройки прокси, создал новую. Но проблема в том, клиенты цепляют настройки старой политики, в которой явно указано что прокси отключен. Т.е. (если вы поняли мой бред))) -не могу понять как сделать настройки прокси “не задана”

Reply
- Mc.Sim
  
  10 июля, 2014 at 21:05
  
  98
  
  Что показывает на контроллере домена результирующая политика?
  
  Reply

Страницы комментариев

1 2 Далее →

Написать комментарий

Имя (обязательно)

Почта (скрыто) (обязательно)

Сайт

Редактор комментариев Wordpress любит заменять спецсимволы в тексте. Пожалуйста, для размещения блоков текста (конфигов, логов, консольных команд) используйте сервисы pastebin. Например, pastebin.com.