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

настройка аутентификации прокси-сервера SQUID Приветствую всех, гостей и постоянных читателей блога. Сегодня попробую изложить информацию о методах аутентификации в 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 - Подключение - Параметры прокси-сервера:Параметры прокси-сервера IE в объекте GPO Т.к. данная настройка расположена в конфигурации пользователя, то и применяться будет к пользователям, расположенным в текущем подразделении 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:

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

Т.к. данная настройка расположена в конфигурации компьютера, то и применяться будет к компьютеру всем пользователям, вошедшим в компьютер, расположенный в текущем подразделении 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.

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

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 - Прокси-сервер:

Настройка прокси сервера chrome через GPO

Т.к. данная настройка расположена в конфигурации пользователя, то и применяться будет к пользователям, расположенным в текущем подразделении 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/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-аутентификации:

  1. Клиент запрашивает страницу, которая требует проверки подлинности (в нашем случае - клиент обращается к серверу squid), но не указывает имя пользователя и пароль.
        GET /path/index.html HTTP/1.1
        Host: localhost
  2. Сервер отвечает клиенту с кодом 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>
  3. Клиент представит аутентификационную информацию (при этом браузер отобразит окно ввода логина/пароля и пользователь должен его ввести, либо отменить)
  4. После того, как пользователь ввел имя и пароль, браузер (или другая программа), склеит имя пользователя и пароль двоеточием, закодирует символы в base64, подставит это значение исходных запрос в поле Authorization и направит серверу.
        GET /path/index.html HTTP/1.1
        Host: localhost
        Authorization: Basic TWMuU2ltOjEyMzQ1
  5. Сервер проверяет подлинность пароля и логина и предоставляет доступ.
        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
  6. Либо не предоставляет доступ, если данные не верны.

За хранение паролей в 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

  1. Предварительная настройка DNS и контроллера домена.
  2. Настройка синхронизации времени (на основе демона ntpd)
  3. Настроить и проверить Kerberos на идентификацию пользователя без ключевого файла krb5.keytab.
  4. Создать ключевой файл krb5.keytab на KDC (контроллер домена Windows 2008 R2)
  5. Настроить и проверить работу 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/squid.domain.local@DOMAIN.LOCAL \
/mapuser squid$@DOMAIN.LOCAL /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/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! 




Теги: , , , ,

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

  1. Март 10th, 2012 at 23:31
    1

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

    • Март 11th, 2012 at 02:28
      2

      Спасибо. Приходите еще!!!

  2. zhum
    Март 12th, 2012 at 14:22
    3

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

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

    • Март 12th, 2012 at 16:35
      4

      пожалуйста!
      Приходите еще :)

  3. Павел
    Март 14th, 2012 at 09:22
    5

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

    • Март 14th, 2012 at 22:38
      6

      можно. я попробовал использовать negotiate и basic, но при использовании данной схемы — пользователям довольно часто вываливается окно с логином/паролем, которое можно игнорировать, нажав ок\отмена, но это сообщение несколько напрягает…
      поэтому пока только на negotiate использую.

  4. Павел
    Март 15th, 2012 at 07:11
    7

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

    • zhum
      Март 16th, 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 включается на стороне броузера.

  5. Апрель 8th, 2012 at 23:22
    9

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

  6. sinder
    Май 15th, 2012 at 12:13
    10

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

  7. pwthrash
    Июнь 18th, 2012 at 00:32
    11

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

    • Июнь 19th, 2012 at 20:34
      12

      ну показывайте команду:
      # kinit -V -k -t /путь/к/созданному/кейтаб HTTP/свой_SPN.имя.домена
      Естественно, HTTP/squid.domain.local — зменить на свое.
      После вышеуказанного kinit, выполните klist и тоже покажите вывод.

  8. ppp
    Июнь 25th, 2012 at 19:31
    13

    *THUMBS UP*
    mai e cool

  9. Константин
    Июль 11th, 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/proxy.urban.ru@URBAN.RU
    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
    Выдает зашифрованную тарабарщину токена.

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

    • Июль 14th, 2012 at 14:46
      15

      Приветствую, Константин. Данная ошибка у меня появлялась, когда я на клиенте указывал прокси в виде IP.
      На самом деле использовать CNAME при Kerberos аутентификации — неправильно. Я тоже сталкивался с данной проблемой, когда самбу вводил в домен. Если пользователь обращался к файловому серверу по CNAME, то АД его не пускал.
      В Вашем случае я могу посоветовать удалить в DNS и AD все А и CNAME записи, по новой ввести squid в домен, создать тикет и не использовать cname. ))

  10. Константин
    Июль 14th, 2012 at 15:27
    16

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

    • Июль 29th, 2012 at 12:38
      17

      Константин, если еще актуально. То давайте конфиг сети машины, на которой крутится линух, конфиг самого линуха и сетевые параметры домена. Попробуем завести.

      • Константин
        Август 14th, 2012 at 09:32
        18

        Я сейчас вернул NTLM аутентификацию, так как начальство требует результатов. По ней корректно пока бродит.
        Но, конечно, хотелось бы отказаться от костыля в виде winbind.
        Есть подозрение, что под виндой у меня не заработало, так как в качестве клиента юзал вин 2003 (то, что под рукой было, хотя стоило взять семерку). А вот под клиентом линуха, введенного в домен like-wise или самбой в логах вообще тишина была. Или для линуха нужно было еще корректно керберос на клиентской машине настроить ?

        Настройки сети машины со SQUID

        vlan505 = внешний ip
        vlan1905 = 192.168.5.5

        Сетевые параметры домена:
        eth0 = 192.168.5.1

        Конфиг самого линуха — какие параметры требуются ?

        • Август 24th, 2012 at 18:32
          19

          Доброго времени, Константин.
          Совсем последнее время нет времени на блог. Сори за поздний ответ, надеюсь, что еще актуально )
          Да, вин 2003 я не могу с какой-то уверенностью сказать, что заработает… Хотя это тот же WinXP, но кто его знает… На время тестов советую использовать десктопные дистрибутивы в качестве клиентов. Как заработает, потом уже тестить остальные. С Linux клиентом, боюсь, что пользователю придется вручную вводить доменный пароль… Что-то я мало представляю, как линуксовый браузер прикрутить к доменной аутентификации…
          В общем, для начала советую поднять linux на виртуалке, например на бесплатном VirtualBOX, а когда заработает — повторить опыт на продакшен железяке.
          Я всегда так делал. Только между этими 2мя опытами был третий — статья на блоге )
          Но в целом, чтобы сделать какую-то диагностику, необходимы конфиги:
          hosts
          hostname
          resolv.conf
          nsswitch.conf
          конфиги сетевых интерфейсов
          конфиги службы или скрипта, который синхронизирует время с контроллером домена
          squid.conf
          krb5.conf

          А так же, параметры домена:
          имя домена
          IP

  11. Владимир
    Август 21st, 2012 at 08:46
    20

    Добрый день.
    Делаю по инструкции с небольшими изменениями (в сети домен на Windows 2003), давал команду
    ktpass /princ HTTP/squid-01.OBR.DOMAIN.RU@OBR.DOMAIN.RU /mapuser squid-01$@OBR.DOMAIN.RU /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/SQUID-01@OBR.DOMAIN.RU
    Using keytab: /etc/squid3/squid.keytab
    kinit: Client not found in Kerberos database while getting initial credentials
    Можете что-нибудь посоветовать?

    • Август 24th, 2012 at 18:55
      21

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

  12. Владимир
    Сентябрь 5th, 2012 at 16:03
    22

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

    • Сентябрь 6th, 2012 at 20:49
      23

      Рад, что все получилось.

  13. Роман
    Сентябрь 14th, 2012 at 11:10
    24

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

    • Сентябрь 17th, 2012 at 14:34
      25

      Доброго времени. Рад, что получилось. Приходите еще )

  14. Александр
    Октябрь 3rd, 2012 at 15:58
    26

    Спасибо огромное, все получилось, единственная проблема была с авторизацией в домене, тут лиюо у вас ошибка, либо я, что то не так сделал.
    У вас следующий вариант:
    auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -s HTTP/squid.domain.local@DOMAIN.LOCAL
    На который была ошибка — 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

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

    • Октябрь 3rd, 2012 at 16:00
      27

      Пожалуйста, Аленксандр.
      Вы не первый с данной ошибкой обращаетесь. Я пока зависимости не нашел, от чего данная ошибка возникает… У меня работало как HTTP/squid.domain.local@DOMAIN.LOCAL.
      Приходите еще!

  15. Александр
    Октябрь 3rd, 2012 at 16:03
    28

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

  16. Дмитрий
    Ноябрь 1st, 2012 at 14:57
    30

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

  17. korven
    Декабрь 12th, 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

    • Декабрь 19th, 2012 at 17:38
      32

      korven, приветствую.
      Данные команды описаны в статье вводный пост squid.
      Спасибо за коммент.

  18. Сергей
    Январь 23rd, 2013 at 16:45
    33

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

  19. Dre
    Февраль 6th, 2013 at 16:53
    34

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

    • Февраль 17th, 2013 at 22:22
      35

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

  20. Павел
    Март 20th, 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

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

    • Март 20th, 2013 at 22:51
      37

      Приветствую, Павел.
      Можно увидеть права доступа на файл
      /etc/squid3/squid.keytab
      ?

  21. Павел
    Март 21st, 2013 at 13:35
    38

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

    • Март 21st, 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
      ?

  22. Павел
    Март 21st, 2013 at 20:34
    40

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

    • Март 21st, 2013 at 21:05
      41

      ну отлично.
      Приходите еще )

  23. Павел
    Апрель 2nd, 2013 at 18:18
    42

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

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

    • Апрель 3rd, 2013 at 21:26
      43

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

  24. Павел
    Апрель 3rd, 2013 at 09:33
    44

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

    • Апрель 3rd, 2013 at 21:28
      45

      это код для тех, кто пишет программы )
      решение я предложил в комменте выше )

  25. Андрей
    Май 8th, 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/sag01-nk.domain.com@CENTRAVIS.COM /mapuser squid01@DOMAIN.COM /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/sag01-nk.domain.com@DOMAIN.COM
    Using default cache: /tmp/krb5cc_0
    Using principal: HTTP/sag01-nk.domain.com@DOMAIN.COM
    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/sag01-nk.domain.com@DOMAIN.COM

    Valid starting Expires Service principal
    08.05.2013 15:40:39 09.05.2013 01:40:39 krbtgt/DOMAIN.COM@DOMAIN.COM
    renew until 09.05.2013 15:40:39

    • Май 8th, 2013 at 21:49
      47

      Так, давайте по порядку….
      Зачем Вы используете 2 хостнейма? Зачем 2 IP?
      Настройте все снова (обязательно почистите все DNS записи для squid в AD) с одним IP 191.168.3.140 и хостнеймом sag01-nk sag01-nk.domain.com.

      И так, до кучи вопрос: почему вы используете не локальные адреса (191.х.х.х) в локальной сети?

  26. Андрей
    Май 10th, 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…. у нас адреса на филиалах. Сеть одна. Так придумали чтоб получить больше пользователей и не путаться. Делал не я. Идеологию построения сети придумал конструктор.

  27. Андрей
    Май 11th, 2013 at 07:41
    49

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

    • Май 17th, 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, вы тем самым создали себе лишние «точки отказа» и трраблшуттинга, чтоли…
      Нужно по максимуму сузить круг диагностики до минимального количества взаимодействующих технологий. Тогда будет проще выявить проблему.
      Как-то так. Надеюсь. что понятно передал мысль.

  28. Андрей
    Май 20th, 2013 at 14:42
    51

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

    • Май 20th, 2013 at 16:20
      52

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

  29. Андрей
    Май 20th, 2013 at 19:32
    53

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

    Сейчас иду сначала. Все вроде настроил. 1 хост машина. Одна запись в DNS ptr и A. Авторизация KeyTabom проходит.
    kinit -V -k -t /etc/krb5.keytab HTTP/sag01-nk.domain.com@DOMAIN.COM пишет об удачной аутентификации. А squid не хочет авторизоваться в домене.
    Using default cache: /tmp/krb5cc_0
    Using principal: HTTP/sag01-nk.domain.com@DOMAIN.COM
    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/sag01-nk.centravis.com@CENTRAVIS.COM
    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

  30. Андрей
    Май 20th, 2013 at 19:34
    54

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

  31. Андрей
    Май 22nd, 2013 at 10:07
    55

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

    • Май 22nd, 2013 at 22:54
      56

      Андрей, если бы Вы почитали по моему совету статью о Kerberos + NFS, то нашли бы там ответ на свой вопрос )
      Цитирую:

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

      Еще, некий alex в своей статье немного дополнил данную дискуссию своими аргументами.

  32. Андрей
    Май 22nd, 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 это круто…. я думаю.

  33. Андрей
    Май 22nd, 2013 at 20:13
    58

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

    • Май 22nd, 2013 at 23:08
      59

      Далее, настроить попробовать настроить CARP.
      Его необходимо настроить так, чтобы Ваш «одинаковый IP» был «публичным IP» для CARP, и на каждой сетевушке был по одному служебному.
      Но служебные IP не должны быть задействованы в Kerberos’e. Как-то так…
      Наверно, стоит предоставить конфиг сюда, чтобы можно было убедится, что описанная схема правильно понятна )))

    • Май 22nd, 2013 at 23:09
      60

      АХ да, и спасибо за описание. Будет интересно потом самому такую схему опробовать, если все у Вас получится )

  34. Андрей
    Май 29th, 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

    • Май 30th, 2013 at 09:44
      62

      Добавляю запуск Squid при каждом поднятии интерфейсов с помощью скрипта. Решение мне не очень нравится.

      Чем не устраивает данное решение?

  35. Андрей
    Май 29th, 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

    • Май 30th, 2013 at 10:25
      64

      Все верно, в /etc/network/interfaces не должно быть адреса 191.168.3.140 его назначает CARP.
      Все же не пойму, почему не устраивает задержка запуска squid?

  36. Андрей
    Июнь 3rd, 2013 at 12:22
    65

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

    • Июнь 3rd, 2013 at 13:00
      66

      Пожалуйста. Приходите еще.
      Спасибо Вам за предоставленное решение.

  37. apruver
    Июль 15th, 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/squid.domain.local@domain.LOCAL
    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 "squid@domain.local" -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$

    • Июль 15th, 2013 at 23:39
      68

      У меня была похожая ошибка.
      Я ее разбирал в статье.
      Попробуйте вместо
      http_access deny all
      указать
      http_access deny !auth all
      http_access deny all

  38. apruver
    Июль 16th, 2013 at 13:47
    69

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

    • Июль 24th, 2013 at 09:56
      70

      В данном случае думаю, что поможет дебаг ACL директив.

  39. apruver
    Июль 24th, 2013 at 13:32
    71

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

  40. gason
    Сентябрь 6th, 2013 at 14:25
    72

    Добрый день!

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

    • Сентябрь 7th, 2013 at 19:53
      73

      А можно скриншот?

      • gason
        Сентябрь 9th, 2013 at 07:17
        74

        Что то не понял как вставить скриншот.
        Если не затруднит, посмотрите, плиз, по ссылочке http://yadi.sk/d/OmeEutnE8vxMv

        • Сентябрь 21st, 2013 at 20:42
          75

          В данном случае рекомендуют переустановить IE на сервере.

  41. selivan
    Сентябрь 29th, 2013 at 02:34
    76

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

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

    • Октябрь 26th, 2013 at 11:43
      77

      Спасибо за отзыв и за дельный коммент. Не знал про GSS_C_NO_NAME.

  42. Денис
    Октябрь 16th, 2013 at 10:40
    78

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

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

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

    • Денис
      Октябрь 16th, 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 не нашел, поэтому изменил имя хоста и все заработало.

      • Октябрь 26th, 2013 at 12:10
        80

        Отлично, когда сам находишь причину )

  43. Анатолий
    Декабрь 24th, 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/px.domain.local@RK.LOCAL
    auth_param negotiate children 64
    auth_param negotiate keep_alive on
    auth_param basic program /usr/lib/squid3/basic_ldap_auth -D «admin@domain.local» -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 «proxyUser@domain.local» -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 yakimov4@DOMAIN.LOCAL
    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 a.v.yakimov@cbi.rkomi.ru
    error_directory /usr/share/squid3/errors/Russian-1251
    always_direct allow all
    dns_v4_first on

    • Декабрь 27th, 2013 at 09:16
      82

      Да, Анатолий, сурово вы…я бы даже сказал беспощадно…разместили прошлую версию конфига )))
      Осторожней будьте )
      По сабжу… На одной из прошлых работ я пытался реализовать примерно такую схему. Но для недоменных машин я использовал отдельную подсеть и авторизовал пользователей по acl из подсети.
      В Вашем случае, можно пойти по следующему пути: повесить squid на дополнительный порт, например 3129 и на клиентах указать прокси с этим портом. При этом, acl указать acl aclname localport 3129. И пришедших с этого порта пускать без аутентификации. Если такой вариант приемлем…

      • Анатолий
        Декабрь 27th, 2013 at 09:48
        83

        Спасибо за ответ. Я этот вариант уже реализовал (2 процесса squid`а слушают разные порты 3128 — Kerberos, 3129 — basic LDAP), но решил что это не путь настоящего джедая и поэтому все-таки оставил вопрос.

        • Декабрь 27th, 2013 at 09:52
          84

          на самом деле, в сквиде можно найти кучу путей решения задачи. Возможности ограничены лишь фантазией )

    • Декабрь 27th, 2013 at 09:18
      85

      В целом, конфиг — достойный )))

  44. Mvairs
    Январь 29th, 2014 at 13:11
    86

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

    • Февраль 12th, 2014 at 15:38
      87

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

  45. Анатолий
    Январь 30th, 2014 at 10:15
    88

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

    • Февраль 12th, 2014 at 15:52
      89

      Отлично. Буду благодарен за образец конфига )

  46. Анатолий
    Февраль 12th, 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 «squid@rk.local» -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 «squid@rk.local» -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 «squid@rk.local» -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 a.v.yakimov@cbi.rkomi.ru
    error_directory /usr/share/squid3/errors/Russian-1251
    #always_direct allow all
    dns_v4_first on

    • Февраль 13th, 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
      Тоже имеются важные нюансы.

  47. Sergey Alekseev
    Апрель 9th, 2014 at 13:34
    92

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

  48. Ustas
    Май 8th, 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/squid1.office.local@OFFICE.LOCAL
    все проходит нормально, билет получается…
    но в браузере постоянно высвечивается авторизация что не вводи — вводи все одно и тоже в лог сыпется …

    • Июнь 24th, 2014 at 20:31
      94

      Какой дистибутив используете?
      Какая версия squid?
      покажите скриншот, как прописан прокси в браузере и какой браузер?

  49. harry
    Май 15th, 2014 at 15:55
    95

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

    • Июнь 24th, 2014 at 20:53
      96

      Сейчас уже очень трудно встретить софт, который не умеет пользоваться прокси сервером. Года 3 назад, когда я еще имел дело с банк-клиентами, уже тогда даже сбербанк умел обращаться к прокси, правда без аутентификации. Если ну уж очень нужно, то выход (наиболее простой) я здесь вижу только один — NAT. Но NAT — это практически неконтролируемая дыра в интернет и он не имеет никакой аутентификации. Старайтесь пускать трафик через прокси.

  50. Ажур
    Июль 7th, 2014 at 09:49
    97

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

    • Июль 10th, 2014 at 21:05
      98

      Что показывает на контроллере домена результирующая политика?

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

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