SQUID аутентификация (Kerberos и LDAP) на основе доменных групп Active Directory

Апрель 29th, 2012 Рубрики: Active Directory, HOWTO, Linux, SQUID, Настройка сервера Linux

kerberos авторизация в squid на основе групп ldapПриветствую, гости и читатели моего блога о Linux. Продолжаем расширять возможности squid. Сегодня попытаемся реализовать авторизацию доменных учеток Active Directory на основе их членства в группах. В статье будет задействовано новая для меня технология, в которой я пока не очень соображаю - LDAP. Поэтому о ней пока будет рассказано "вскользь". Для того, чтобы у вас заработала данная схема, необходимо ознакомиться со статьями:

Без данных статей и понимания принципов работы squid - никак :)

Что такое LDAP в Active Directory (Введение)

Т.к. LDAP пока для меня - это маленькая тайна. Расскажу, что знаю... Итак, LDAP - это некий каталог (дословно - lightweight directory access protocol, в переводе - облегчённый протокол доступа к каталогам), который хранит в себе различную информацию в древовидной форме и имеет структуру, на нашем примере (на примере домена AD.LOCAL):  sqiud авторизация пользователей по группам в active directory

Давайте разберем что к чему... В голове структуры - имя домена (AD.LOCAL), "в подчинении" у домена - отделы (т.н. организационные единицы), у каждого отдела могут быть в подчинении другие отделы. Кроме того, в любой отдел (в том числе и в корневой контейнер - домен) могут входить некие элементы - группы, пользователи, принтеры и др., которые "в себе" могут хранить некоторые настройки -  атрибуты объекта (например, у пользователя - пароль, имя, адрес почты и др.).

У каждой записи в LDAP, будь то объект или контейнер с объектами внутри имеется уникальное для всего каталога LDAP имя (т.н.  англ. Distinguished Name (DN) - Отличительное имя). Это даже не имя, а путь, характеризующий полный путь к этом этой записи во всей иерархии. Уникальный путь может выглядеть (на примере группы squid), следующим образом: «cn=squid, ou=groups, ou=UNIXsdc=ad, dc=local». Уникальное имя состоит из одного или нескольких относительных отличительных имен (RDN — англ. Relative Distinguished Name), разделённых запятой. Относительное уникальное имя имеет вид ИмяАтрибута=значение (например cn=squid ). На одном уровне каталога не может существовать двух записей с одинаковыми относительными уникальными именами (при этом, в Active Directory имеются некоторые дополнительные ограничения, например, не может быть пользователя с одинаковым именем во всем дереве).

Давайте разберем приведенный путь. Данный путь стОит читать с конца. Он начинается с описания домена, в котором расположен каталог и обозначается как dc=ad, dc=local, здесь - имя dc (оно же Domain Component компонент доменного имени) задает имя домена, то есть если бы у нас был домен, например subdomain.ad.local, то данный кусок отличительного имени выглядел бы как   dc=subdomain, dc=ad, dc=local. Далее описывается структура иерархия контейнеров отделов (они же OU, они же Organization Unit - организационная единица или подразделение), которые представляет собой  ou=groups, ou=UNIXs. Это стоит читать так же с конца, то есть в текущем домене есть некий контейнер UNIXs, в котором есть подконтейнер groups. Если бы необходимый нам объект находился в отделе, например, Склады, то текущий кусок DN (Distinguished Name) выглядел бы следующим образом:  ou=Склады, ou=groups. Далее мы видим в DN описание конкретной записи (в данном случае - запись - это группа squid). Кусок, DN пути, описывающий группу представляет собой строку cn=squid, где CN - Common Name - общее (относительное) имя (Пользователь, контакт, группа или другой объект, который как правило не имеет дочерних объектов).

Думаю, что общую структуру объяснил понятно. Этого понимания, думаю, будет достаточно для реализации Kerberos LDAP авторизации на основе группы Active Directory.

Настройка squid на Kerberos аутентификацию

Настройку squid на Kerberos аутентификацию необходимо сделать, согласно статьи Negotiate - метод аутентификации в squid. После настройки Kerberos аутентификации у нас начинает работать некий прокси-сервер squid, который аутентифицирует доменных пользователей. Предположим, что он имеет некий конфиг:

ldap ~ # grep -v ^# /etc/squid3/squid.conf | grep -v ^$
auth_param negotiate program /usr/lib/squid3/squid_kerb_auth
auth_param negotiate children 15
auth_param negotiate keep_alive on
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 CONNECT method CONNECT
acl localnet src 10.0.0.0/16
acl to_localnet dst 10.0.0.0/16
acl allusers proxy_auth REQUIRED
http_access allow manager localhost
http_access allow localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow allusers
http_access deny !allusers all
http_access deny all
http_port 10.0.0.10:3129
http_port 127.0.0.1:3129
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

Конечно же, кроме squid.conf у нас должен быть настроен /etc/krb5.conf  и другие необходимые конфиги и, конечно же, Active Directory согласно статье.

Исходные данные

Конфигурация сети следующая:

  • Локальная подсеть - 10.0.0.0/16
  • IP контроллера домена - 10.0.0.1
  • Имя домена - ad.local
  • Имя контроллера домена - dc.ad.local
  • IP хоста со squid - 10.0.0.10

Использование LDAP групп из Active Directory

Собственно, для чего нам использовать LDAP группы из Active Directory? Мы же можем просто составить необходимые списки acl с внесением туда пользователей, например

acl allusers proxy_auth "/etc/squid3/acls/vipusers.acl"
cat /etc/squid3/acls/vipusers.acl
user1@AD.LOCAL
user2@AD.LOCAL
...

...но это приемлемо, когда в сети 10-30 пользователей и не часто приходится их заводить... Если у вас больше пользователей еще и текучка кадров большая, то становится жутко неудобно вручную добавлять имена в acl и помнить, кого нужно удалить/изменить. После чего перезапускать/релоадить squid, что так же доставляет неудобство для работающих в данный момент пользователей. Гораздо проще добавить пользователя в AD и включить его в некую группу, в результате чего он автоматически получает доступ к глобальной сети с заданными для группы параметрами и не трогать squid совсем...

Для обращения к LDAP Active Directory, в squid используется хелпер squid_ldap_group, кроме того, squid должен быть собран с опцией --enable-external-acl-helpers="ldap_group". Как узнать с какими опциями собран squid я писал в первой статье о squid.

Настройка Active Directory для использования групп

настройка пользователя Active Directory для LDAP из squid По умолчанию, в AD запрещено анонимным пользователям получать какую-либо информацию из каталога. Для того, чтобы squid хелпер  squid_ldap_group  имел право обращаться к каталогу Active Directory и извлекать некую информацию из доменной структуры, необходимо хелперу предоставить некие учетные данные для доступа к LDAP. Для этого я в домене создал учетку с минимально необходимыми правами (членство в группе Domain Users - Пользователи домена) (??? может будет достаточно группы Гости домена...). Имя учетной записи в моем примере будет adsquid@AD.LOCAL, важно задать настройку запрета смены пароля и отменить ограничение времени действия пароля при создании учетной записи.

Для удобства, все группы и учетные записи пользователей и компьютеров использующиеся для интеграции сервисов на Linux в инфраструктуру Kerberos я создаю в контейнере UNIXs в подконтейнерах groups, users, hosts соответственно.

Конечно же, нам необходимо создать (для примера) 2 группы пользователей. 1 - это группа, имеющая доступ в интернет без ограничения доступа (называется squid), 2 - группа, имеющая доступ только к списку избранных сайтов (называется squid-list). Можно создать сколько угодно групп с заданием разных настроек, но для примера будет достаточно 2х.

Связь хелпера squid_ldap_group с Active Directory

Нижеприведенная команда была сгруппирована из различных источников в сети, поэтому некоторые параметры останутся без четкого описания (как это не печально...).

Рассмотрим пример установки тестовой связи хелпера squid_ldap_group с каталогом LDAP AD:

ldap ~ # /usr/lib/squid3/squid_ldap_group -R -d -b "dc=ad,dc=local" \
-f "(&(objectclass=user)(sAMAccountName=%v)(memberOf=cn=%a,ou=groups,ou=UNIXs,dc=ad,dc=local))" \
-D adsquid@ad.local -W /etc/squid3/aduser dc
test squid-list
Connected OK
group filter '(&(objectclass=user)(sAMAccountName=test)(memberOf=cn=squid-list,ou=groups,ou=UNIXs,dc=ad,dc=local))', searchbase 'dc=ad,dc=local'
OK
test@AD.LOCAL squid-list
Connected OK
group filter '(&(objectclass=user)(sAMAccountName=test@AD.LOCAL)(memberOf=cn=squid-list,ou=groups,ou=UNIXs,dc=ad,dc=local))', searchbase 'dc=ad,dc=local'
ERR
AD\test squid-list
Connected OK
group filter '(&(objectclass=user)(sAMAccountName=AD\5ctest)(memberOf=cn=squid-list,ou=groups,ou=UNIXs,dc=ad,dc=local))', searchbase 'dc=ad,dc=local'
ERR
ivanov squid-list
Connected OK
group filter '(&(objectclass=user)(sAMAccountName=ivanov)(memberOf=cn=squid-list,ou=groups,ou=UNIXs,dc=ad,dc=local))', searchbase 'dc=ad,dc=local'
ERR

Давайте рассмотрим, что мы накуралесили в данной команде (все параметры описаны из man  squid_ldap_group):

-R

дословно - do not follow referrals. Как переводится - не знаю :) Работает и без нее. Но, говорят снижает нагрузку на AD.

 -d

ключ указывается на время тестового подключения заставляет squid_ldap_group комментировать свои действия, что помогает в выявлении проблем.

-b

это базовое отличительное имя нашего дерева каталогов (т.н. BaseDN). Базовое, то есть от этой ветки будет производиться поиск пользователей в LDAP. Допустим, если бы все наши авторизуемые пользователи находились бы в контейнере OU Юристы, то можно было бы задать значение этого ключа  -b "ou=Юристы, ou=groups,dc=ad,dc=local", тем самым снизив нагрузку на LDAP. Т.к. авторизуемые пользователи у меня разбросаны по всей структуре дерева, то в примере я указываю производить поиск от корня дерева  -b "dc=ad,dc=local"

-f

задает некий фильтр поиска необходимой нам группы (memberOf=cn=%a), которая расположена по пути ou=groups,ou=UNIXs,dc=ad,dc=local. В данном фильтре переменная %v заменяется именем пользователя (без указания домена @AD.LOCAL или AD\), а переменная %a заменяется запрашиваемой группой. Т.к. в LDAP я почти ноль, поэтому толкового объяснения данному фильтру не даю... Соответственно, если у вас группа (принадлежность к которой необходимо проверять) расположена в каком-нибудь контейнере linux в домене primer.domen.local, то данный фильтр будет иметь вид:  -f  "(&(objectclass=user)(sAMAccountName=%v)(memberOf=cn=%a,ou=linux,dc=primer,dc=domen,dc=local))".

-D

задает имя пользователя, от которого происходит подключение к каталогу AD.

-W

указывает путь к файлу, который хранит пароль к учетной записи из параметра -D. На данный файл необходимо назначить владельца - пользователя под которым работает squid (обычно это proxy) и задать права доступа на чтение только для владельца.

dc

задает DNS имя сервера LDAP. Здесь можно указать вместо DNS имени - IP адрес.

Далее в листинге я пытаюсь проверить соответствие доменного пользователя test доменной группе squid-list, в которую он действительно входит. При этом, я пытаюсь указать имя пользователя в различных форматах. Как видно, хелпер  squid_ldap_group корректно принимает имя только без указания доменной части. О чем нам говорит строка:

test squid-list
Connected OK
group filter '(&(objectclass=user)(sAMAccountName=test)(memberOf=cn=squid-list,ou=groups,ou=UNIXs,dc=ad,dc=local))', searchbase 'dc=ad,dc=local'
OK

Последней попыткой я пытаюсь проверить принадлежность пользователя ivanov к указанной группе squid-list, при этом, реально ivanov в данную группу не входит. Соответственно, неудачные попытки нам возвращают значение ERR.

Если на данном шаге удалось связать хелпер с AD и при правильном вводе пользователя и группы, в которую он входит, происходит корректный ответ хелпера - ОК, значит дело движется в правильном направлении и можно приступить к настройке squid. В противном же случае - необходимо разобраться в причинах проблем.

Настройка squid для авторизации на основе членства в доменной группе LDAP

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

# задаем external_acl_type для взаимодействия с LDAP
external_acl_type произвольное_имя_ext_acl %LOGIN /путь/к/хелперу/squid_ldap_group -R \
-b "BaseDN" -f "фильтр с переменной %v и %a" -D пользователь_ad@домен -K -W /файл/с/паролем имя_dc
# где переменная %v подставляется за счет указания значения %LOGIN,
#  которое извлекает имя аутентифицированного пользователя
# далее необходимо задать acl, которое будет передавать в переменную %a имя групп
acl имя_acl external произволное_имя_ext_acl передаваемое_название_группы
# далее необходимо с образовавшимся acl работать как с обычным acl,
# то есть задавать какие-то разрешения с помощью соответствующих параметров

Если данную схему наложить на наш домен и нашу задачу, то получится примерно следующий конфиг:

ldap ~ # grep -v ^# /etc/squid3/squid.conf | grep -v ^$
auth_param negotiate program /usr/lib/squid3/squid_kerb_auth
auth_param negotiate children 15
auth_param negotiate keep_alive on
external_acl_type ldap_verify %LOGIN /usr/lib/squid3/squid_ldap_group -R \
-b "dc=ad,dc=local" -f  "(&(objectclass=user)(sAMAccountName=%v)(memberOf=cn=%a,ou=groups,ou=UNIXs,dc=ad,dc=local))"\
-D adsquid@ad.local -K -W /etc/squid3/aduser dc.ad.local.
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 CONNECT method CONNECT
acl localnet src 10.0.0.0/16
acl to_localnet dst 10.0.0.0/16
acl users external ldap_verify squid
acl users-list external ldap_verify squid-list
acl whitelist dstdomain "/etc/squid3/acls/whitelist.acl"
acl allusers proxy_auth REQUIRED
http_access allow manager localhost
http_access allow localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow users
http_access allow users-list whitelist
http_access deny !allusers all
http_access deny all
http_port 10.0.0.10:3129
http_port 127.0.0.1:3129
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

Давайте разберем получившийся конфиг. Как видно, добавился параметр external_acl_type, заставляющий sqiud обращаться к каталогу LDAP, расположенному на контроллере домена dc.ad.local, через хелпер squid_ldap_group. squid_ldap_group  ищет пользователей в каталоге, начиная с пути  dc=ad,dc=local, авторизованных пользователей, принадлежащих некоторым группам, имена которых (групп) передаются из acl в переменную %a. Как мы видим, у нас пропал параметр -d за ненадобностью и появился параметр -K. Давайте его разберем. Мы знаем, что при Negotiate Kerberos аутентификации имя пользователя у нас получается в виде пользователь@ДОМЕН, а хелпер  squid_ldap_group использует имена в формате пользователь (то есть без доменной части). Так вот, ключ -K заставляет  squid_ldap_group "обрезать" часть имени @ДОМЕН и корректно сравнивать имя пользователя и группу.

Далее мы видим, что появилось 3 новых  acl - users, users-list и whitelist, которые проверяют принадлежность пользователя к группе с именем squid, к группе с именем squid-list и задает белый список сайтов соответственно. При этом, про первые 2 acl было бы понятней сказать, что они передают в  external_acl_type с именем  ldap_verify  имя группы, которой должен принадлежать аутентифицированный пользователь.

Ну и последнее - это появление двух параметров http_access, которые разрешают доступ acl с именем users и acl с именем users-list при доступе этих пользователей к сайтам из acl whitelist. Кроме того, был убран параметр  http_access allow allusers, который разрешал доступ всем аутентифицированным пользователям.

На этом в настройке можно поставить точку. Перезапускаем сквид и наши пользователи, которые входят в доменные группы squid и squid-list могут работать в интернете.

Особенности работы squid при авторизации на основе доменных групп LDAP

При реализации данной схемы я столкнулся с некоторыми нюансами, которые не стоит оставлять без внимания:

  1. если пользователь входит в несколько групп, которым предоставлен доступ в интернет в конфигурационном файле squid, то он (пользователь) будет иметь то разрешение, которое первым совпадет с правилом http_access. То есть если некоторый авторизованный пользователь pupkin входит и в группу squid и в группу squid-list, то при том конфиге, что показан выше, он получит доступ согласно группе squid, потому что правило  http_access allow users расположено первым.
  2. группы Activ directory и squid В каждом из OU (Склады, Кадры, Юристы и другие подразделения того же уровня) имеют в подчинении свои группы, включающие в себя подчиненные им же (подразделениям) пользователей. То есть подразделение Закупки имеет подчиненный объект Закупки, который является группой включающей в себя всех пользователей подразделения, и если эту группу включить в группу с именем squid (то есть группу Закупки сделать членом группы squid), то пользователи из группы Закупки не получат доступ к интернету, пока этих пользователей индивидуально не включишь в группу squid.
  3. После добавления пользователя в группу работа пользователя начинается через некоторое время, а точнее через время, которое равно значению по-умолчанию в параметре ttl в external_acl_type и равно оно 3600 сек (1 час). Если есть желание ускорить процесс, то нужно уменьшить ttl, например так: external_acl_type ldap_check ttl=1200 %LOGIN /usr/...

Резюме

В данной статье нам, надеюсь и вам, удалось заставить squid с помощью хелпера  squid_ldap_group извлекать из Active Directory информацию о принадлежности пользователя к заданной группе и на основе данной информации предоставлять или не предоставлять доступ к интернету. При этом, есть возможность так же для групп задать настройки скорости через delay pools и многие другие настройки и ограничения для доступа в интернет, основываясь на управлении списками доступа acl. До новых статей!

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




Теги: , , , , , ,

155 комментариев к “SQUID аутентификация (Kerberos и LDAP) на основе доменных групп Active Directory”

  1. Rover
    Июнь 24th, 2014 at 23:49
    1

    Огромное спасибо за ваши статьи! С помощью них настроил прокси с negotiate авторизацией в Server 2003 SP2.
    Если не против — хочу поделиться своими подводными камнями )
    Мне так и не удалось заставить работать одновременно basic и negotiate. Как толко добавляю в конфиг auth_param negotiate … браузеры не предлагают basic авторизацию и просят учетные данные домена. Пробовал менять расстановки http_access — бесполезно. Подозреваю это все из-за того, что при создании keytab для Server 2003 SP2 в параметере /crypto нельзя выбрать ключ ALL, единственный подходящий ключ это RC4-HMAC-NT. (Кстати SupportTools в состав Server 2003 не входят — нужно доустанавливать с диска дистрибутива).
    Поэтому пришлось запускать второй экземпляр squid, который подключается к первому и настроен на basic аутентификацию.
    Да, и на счет пользователя для ldap хелпера. Похоже группы гости домена ему достаточно, я именно так и сделал и пока что проблем не было.
    Еще раз спасибо за материал — все очень хорошо и понятно расписано!

    • Июнь 28th, 2014 at 13:38
      2

      Отличное дополнение, спасибо.

  2. 4UGUN
    Июнь 30th, 2014 at 13:54
    3

    опишу сразу версии ПО
    cat /etc/redhat-release
    CentOS release 5.10 (Final)

    squid -v
    Squid Cache: Version 2.6.STABLE21
    /usr/lib64/squid/squid_ldap_group

    squid_ldap_group version 2.17
    проблема в том что нет опции -K у squid_ldap_group

    debug ACL в сквиде говорит
    2014/06/30 09:16:21| squid_kerb_auth: AF oYGd0jZbPeA== a.pupkin@RM.LOCAL
    Connected OK
    group filter ‘(&(objectClass=user)(sAMAccountName=a.pupkin@RM.LOCAL)(memberOf=cn=level1,ou=proxy,dc=rm,dc=local))’, searchbase ‘dc=rm,dc=local’

    то есть на вход %LOGIN приходит a.pupkin@RM.LOCAL

    какие могут быть советы кроме как всю обработку делать в отдельном скрипте

    • Июль 3rd, 2014 at 19:13
      4

      Почему Вы поставили версию 2.6?

  3. ZABor
    Июль 3rd, 2014 at 09:44
    5

    Большое спасибо за статью!
    Долго я бился с параметрами хелпера squid_ldap_group, вроде сам разобрался и нарвался на эту статью, где все разжевано и разложено по полочкам. Уверенности в правильности своих действий добавилось. Как говорится: опыт — это такая штука, которая появляется сразу после того, как была нужна.
    Одно замечание: В каждом из OU (Склады, Кадры, Юристы и другие подразделения того же уровня) имеют в подчинении свои группы, включающие в себя подчиненные им же (подразделениям) пользователей. То есть подразделение Закупки имеет подчиненный объект Закуп2, который является группой включающей в себя всех пользователей подразделения, и если эту группу включить в группу с именем squid (то есть группу Закуп2 сделать членом группы squid), то пользователи из группы Закуп2 не получат доступ к интернету, пока этих пользователей индивидуально не включишь в группу squid. В группу squid надо включить группу Закупки для получения доступа к интернету. (Правильно я понял?).
    Вот это замечание прошу прокомментировать, просто из-за совпадения имен групп трудно понять о какой группе идет речь.

    • Июль 3rd, 2014 at 20:01
      6

      Спасибо за комментарий )

      Как говорится: опыт — это такая штука, которая появляется сразу после того, как была нужна.

      Улыбнуло )))
      По сабжу… На сколько мне понятно, глубину и параметры поиска задает фильтр,который указан после ключа -f. Тут необходимо более глубокое понимание работы LDAP, погрузиться в который мне пока не довелось. Поэтому какой-либо компетентный ответ на данный вопрос я скорей всего не дам (

  4. Kaign
    Июль 7th, 2014 at 18:01
    7

    Здравствуйте, спасибо за блог, в последнее время очень часто сюда наведываюсь.
    Настроил все по статье, все работает замечательно.
    Но появилась потребность получать интернет для компьютеров которые не входят в домен. Единственное что у меня получается, так это использовать squid_kerb_auth вместе с ncsa_auth, но тогда не работает ldap, и для недоменных писи просит ввода логин/пароль по 3-4 раза к ряду.
    Возможно ли к реализации описанной в вашей статье прикрутить еще авторизацию вне домена через AD? (т.е. на недоменном писи надо будет ввести логин-пароль пользователя из группы squid-list например )
    Вариант с двумя сквид процессами откладываю на саамый черный день )

    • Kaign
      Июль 7th, 2014 at 18:36
      8

      и вот конфиг
      http://pastebin.com/5kzCzCX8

      • Июль 10th, 2014 at 21:19
        9

        Попробуйте разместить правила вот в таком порядке:
        http_access deny !Safe_ports
        http_access deny CONNECT !SSL_ports
        http_access allow manager localhost
        #http_access deny lan DeniedSites
        http_access allow localhost
        http_access deny inet1_users DeniedSites
        http_access allow inet1_users
        http_access allow inet2_users DeniedSites
        # попробуйте с закомментированным правилом и раскомментированным
        #http_access allow lan
        http_access deny !lan all
        http_access deny all

        А то получается вы сначала разрешаете ВСЕМ доменным пользователям (http_access allow lan), а те правила, что идут ниже с использованием доменных групп уже не имеют большого смысла, т.к. те, кто пришел из домена уже получат доступ.
        Рекомендую так же пролистать статью о списках доступа в squid

        • Kaign
          Август 6th, 2014 at 16:22
          10

          Спасибо, действительно так авторизация работает и для доменных машин и для тех кто не в домене.
          Как ни странно, таким методом аутентифицироваться не захотели скайп и торренты.. хотя на форумах у кого-то получалось используя squid + samba+winbind. Если кто будет искать решение, то я обошел эту проблему создав второй процесс squida слушающего другой порт и без аутентификации вообще, при этом открыл ему только самые нужные порты — хватает чтобы работали скайп и торренты, но не хватает чтобы посерфить по сайтам)

          • Август 7th, 2014 at 09:34
            11

            Спасибо за информацию. Рад, что все получилось…

            • Kaign
              Сентябрь 9th, 2014 at 10:01
              12

              А есть ли для данного случая какое-нибудь решение для подсчета и ограничения трафика юзеров, и записи логов кто куда лазил. Как я вижу на большинство вариантов — тот же SAMS например, опять-таки требуется samba..

              • Декабрь 17th, 2014 at 21:13
                13

                lightsquid умеет считать трафик, а по поводу ограничения скорости, почитайте статью о delay pools.

  5. n1kt0
    Октябрь 15th, 2014 at 16:25
    14

    Mc.Sim добрый день.
    Подскажите, можно ли прикрутить к kerberos одновременно ldap?
    Смысл в том что бы пользователи домена заходили в интернет с компьютеров которые не в домене, просто вводя логин и пароль.
    Пытался сделать через ldap_auth, но тут косяк в том что браузер передает данные как domain\login а ldap_auth хочет просто login.
    Проверяю: echo domain.ru\login 11111 | /usr/lib/squid/ldap_auth -d -R -b «dc=domain,dc=ru» -D «cn=admin,cn=Users,dc=domain,dc=ru» -w «123» -f «sAMAccountName=%s» -s sub -h IP_domain
    в ответ пишет
    domain.ru\login 11111
    user filter ‘sAMAccountName=domain.ru\5clogin’, searchbase ‘dc=domain,dc=ru’
    Ldap search returned nothing
    ERR Success

    Зарнее спасибо.

    • Декабрь 18th, 2014 at 12:56
      15

      Доброго времени.
      Не понял вашего вопроса.

      Подскажите, можно ли прикрутить к kerberos одновременно ldap?

      Статья ведь итак описывает эту конфигурацию.
      Зачем вы применяете хелпер /usr/lib/squid/ldap_auth, если в статье используется
      auth_param negotiate program /usr/lib/squid3/squid_kerb_auth

  6. n1kt0
    Октябрь 15th, 2014 at 17:01
    16

    Прошу прощения если достаю, вопрос по поводу керберос и таких программ как ICQ SKYPE и прочее. Они же работают на стандартном 443 порту, но при этом в логе пишется что к примеру ICQ логин не передает. Как Вы настраивали ?

    • Декабрь 18th, 2014 at 13:01
      17

      Все эти программы в большинстве случаев имеют настройку «автоматически настраивать прокси», либо «брать настройки из браузера», либо «использовать учетные данные windows». Я пока не испытывал проблем с этим. Пишите, если не получится.

      • Сергей Бабаков
        Апрель 22nd, 2016 at 23:05
        18

        Добрый день! Долгое время squid был настроен на ntlm+basic аутентификации. Настроил kerberos. И как раз возникла проблема со skype. В браузере все отлично, в icqшном клиенте раньше прописывали все данные для аутентфикации теперь, ставим — автоматом. А вот скайп ни в какую не хочет через прокси идти. Смотрел tcp view — ломится напрямую на десяток неведомых ip, половина из которых не резолвится даже. Что можно предпринять, есть какие-то решения?

        • Август 4th, 2016 at 21:23
          19

          Это очень странная проблема. Обычно, у администраторов противоположные сложности — как запретить доступ скайпу )
          То, что он подключается (пытается) на внешние IP — это нормально. Ищет доступ к своим серверам.
          А вот то, что он не подключается, когда в браузере есть интернет — это очень странно.

  7. Man!
    Октябрь 31st, 2014 at 10:38
    20

    Здравствуйте! У меня ситуация немного схожая с Kaign.
    Настроена и работает LDAP авторизация Squid 3.1.10 на основе групп в AD на Windows Server 2003 R2 SP2 посредством squid_kerb_auth + squid_ldap_auth + squid_ldap_group

    CentOS release 6.5 (Final)
    Squid 3.1.10
    http://pastebin.com/jFG9iGq4 squid -v
    http://pastebin.com/nbS1z97P squid.conf

    Но по разным причинам есть необходимость применять acl типа «src» (например
    acl Myorganization src «/usr/local/squid/acc-list-all») для не авторизованных в домене клиентов.
    Проблема в том, что если клиент не авторизован в домене, то браузер циклично запрашивает у него логин и пароль и squid, как будто не переходит к обработке следующего http_access. (Если ввести логин и пароль доменной учетки, то запрашиваемая страница в браузере отображается, но это не подходит)

    Кусок лога cache.log в отладочном режиме:
    http://pastebin.com/UJFuTxH7
    Здесь логирована попытка открыть страницу в браузере под локальным пользователем на доменной машинке, в результате чего запрошен логин и пароль.

    Можно ли сделать так, чтобы в описанной ситуации никакие пароли у клиентов не запрашивались, а чтобы squid просто переходил к обработке следующих правил?

    • Декабрь 18th, 2014 at 13:45
      21

      Судя по Вашему конфигу, вы не последовали моей рекомендации, которую я дал Kaign. Попробуйте привести http_access к предложенному виду.

      • Man!
        Январь 14th, 2015 at 09:45
        22

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

        • Апрель 9th, 2015 at 16:59
          23

          В статье об acl я постарался описать ключевые принципы размещения последовательности http_access.
          Кроме того, могу сказать, что многом помогает вот такая компбинация, размещенная в конце правил:
          http_access deny !auth all
          http_access deny all

          Так же, рекомендую разместить «быстрые» разрешающие правила http_access, выше медленных, особенно которые используют аутентификацию.

  8. Богдан
    Май 18th, 2015 at 18:19
    24

    Подскажите пожалуйста в чем может быть проблема консоль — _ttp://clip2net.com/s/3hStwn4 Пользователи и компьютеры в AD — _ttp://clip2net.com/s/3hSu9tT
    Пользователь auser1 пренадлежит группе access

    • Июнь 7th, 2015 at 22:47
      25

      Ссылки не работают.

  9. Арти
    Ноябрь 11th, 2015 at 11:27
    26

    Есть вопрос ко всем знатокам..Как объединить AD и Skype для дальнейшей прикрутки к outlook?

    • Июль 24th, 2016 at 15:31
      27

      Я думаю, что Skype for Business Server вам поможет.

  10. vadim
    Ноябрь 20th, 2015 at 13:58
    28

    Добрый день. Пытался настроить Squid с двойной авторизацией Kerberos и basic , как указано на сайте, авторизация по kerberos проходит, пытаюсь проверить под локальным пользователем — не входит, добавляется к логину название домена и не пускает, подскажите пожалуйста в чем может быть проблема. Заранее спасибо

    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 deny !Safe_ports
    http_access deny CONNECT !SSL_ports
    http_access allow localhost manager
    http_access deny manager
    http_access allow localhost

    #squid basic аутентификация (пользователи создаются чере htpasswd /etc/squid3/squidusers username)
    auth_param basic program /usr/lib/squid3/basic_ncsa_auth /etc/squid3/erkon_users
    auth_param basic children 5
    auth_param basic realm ERKON-NN
    auth_param basic credentialsttl 10 hours
    auth_param basic casesensitive off
    acl lan proxy_auth REQUIRED

    # указание, какой хелпер использовать с каким SPN
    auth_param negotiate program /usr/lib/squid3/negotiate_wrapper_auth —ntlm /usr/bin/ntlm_auth —diagnostics —helper-protocol=squid-2.5-ntlmssp —kerberos /usr/lib/squid3/negotiate_kerberos_auth -r -s HTTP/proxy.erkon-nn.com@ERKON-NN.COM
    # сколько параллельных потоков запускать для обслуживания аутентификации клиентов
    auth_param negotiate children 10
    # указывает поддерживать связь, а не обрывать, когда браузер опрашивает схемы аутентификации
    auth_param negotiate keep_alive on
    acl lan proxy_auth REQUIRED

    #блокировка запрещенных сайтов для всех
    #acl badsites dstdomain «/etc/squid3/badsites»
    #http_access deny badsites

    #блокировка сайтов для уникальных юзверей Group1
    #acl username proxy_auth «/etc/squid3/username_group1_deny»
    #acl badsites_group1_deny dstdomain «/etc/squid3/badsites_group1_deny»
    #http_access deny username badsites_group1_deny

    #разрешить доступ из lan
    http_access allow lan

    cache_mem 300 MB
    http_access deny all
    http_port 3128
    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
    visible_hostname = proxy

    • Июль 24th, 2016 at 16:24
      29

      Еще актуален вопрос?
      Есть пару рекомендаций и вопросов, прежде чем можно будет дато окончательный ответ.
      Рекомендую разместить ACL и директорию http_access в отдельных блоках, чтобы был порядок и читабельность. (статья по теме http://www.k-max.name/linux/squid-acl-and-http_access/)
      Из Вашего конфига я вижу, что используется хелпер negotiate_wrapper_auth. Чем вызвано использование данного хелпера?

  11. Sergey
    Декабрь 25th, 2015 at 11:42
    30

    Спасибо за статью.
    Всё получилось, работает.

    Одного никак не пойму: каким образом можно обновлять правила групп и блеклистов для них? К примеру, пользователь был в админах с доступом везде, но провинился и попал в обычные пользователи. Или наоборот. Как в таких случаях обновлять правила доступа для него? При текущей настройке правила не обновляются — ему либо так же всё разрешено, либо после смены группы обычных пользователей на админскую, действуют всё те же запрещающие правила.
    Перелогиниться пробовал, разумеется, сквид перезапускал.

    Спасибо.

    • Август 3rd, 2016 at 22:26
      31

      Я думаю, что за это ответственный файл krb5.conf, в котором можно задать соответствующие параметры таймаутов. Можно еще посмотреть в ключи для squid_kerb_auth, но я не смог найти мана (

  12. Андрей
    Февраль 5th, 2016 at 07:02
    32

    Спасибо за мануал. Сделал всё тоже самое, но с хелпером ext_kerberos_ldap_group_acl.
    Работает магическим способом, получая все необходимые данные о сервере ldap из DNS, и авторизуясь в нём для проверки по уже существующему ключику kerberos (используя учётную запись машины). Таким образом, не надо создавать учётку пользователя и хранить её пароль на сервере.

    Конфиг, который проверяет пользователей на вхождение в группы:
    external_acl_type adgroup ttl=1200 %LOGIN %ACL /usr/lib/squid3/ext_kerberos_ldap_group_acl -D AD.LOCAL
    acl internet external adgroup
    acl fastinternet external adgroup

    где internet и fastinternet — имена соответствующих груп в AD. Ну и да, realm AD.LOCAL указан только потому, что у нас в сети несколько доменов.

    • Август 3rd, 2016 at 23:06
      33

      Спасибо за пример.
      Интересный хелпер )

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

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