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

29 апреля, 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, где CNCommon 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
[email protected]
[email protected]
...

…но это приемлемо, когда в сети 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 – Пользователи домена) (??? может будет достаточно группы Гости домена…). Имя учетной записи в моем примере будет [email protected], важно задать настройку запрета смены пароля и отменить ограничение времени действия пароля при создании учетной записи.

Для удобства, все группы и учетные записи пользователей и компьютеров использующиеся для интеграции сервисов на 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 [email protected] -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
[email protected] squid-list
Connected OK
group filter '(&(objectclass=user)([email protected])(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 [email protected] -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 новых  aclusers, 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!




Теги: , , , , , ,

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

  1. Александр
    4 октября, 2012 at 10:31
    1

    Приветствую, по предыдущей Вашей статье настроил авторизацию через Kerberos, все отлично работает и бегает.
    Теперь решил добавить в данную конфигурацию LDAP авторизацию
    Создал пользователя в АД, все как положено, дошел до пункта “Связь хелпера squid_ldap_group с Active Directory”
    Создал пользователя в %users% – htpasswd /etc/squid3/passwd %users%

    Далее как описано:
    /usr/lib/squid3/squid_ldap_group -R -d -b “dc=DOMAIN,dc=local” \
    -f “(&(objectclass=user)(sAMAccountName=%v)(memberOf=CN=%a,OU=groups,OU=UNIXs,OU=Group,OU=Samara,DC=DOMAIN,DC=local))”\ — путь точно верный, брал из ADSI
    -D [email protected] -W /etc/squid3/passwd dc
    test squid
    На что получаю ошибку
    Connected OK
    group filter ‘(&(objectclass=user)(sAMAccountName=test)(memberOf=CN=squid,OU=groups,OU=UNIXs,OU=Group,OU=Samara,DC=DOMAIN,DC=local))-D’, searchbase ‘DC=DOMAIN,DC=LOCAL’
    squid_ldap_group WARNING, LDAP search error ‘Bad search filter’
    ERR

    • 4 октября, 2012 at 14:28
      2

      Александр, обратите внимание на
      memberOf=CN=%a,OU=groups,OU=UNIXs,OU=Group,OU=Samara,DC=DOMAIN,DC=local
      У Вас имеются OU=groups,OU=UNIXs,OU=Group,OU=Samara
      В доказательство хотелось бы скриншот.

    • 4 октября, 2012 at 14:33
      3

      А еще я заметил, что тут
      group filter ‘(&(objectclass=user)(sAMAccountName=test)(memberOf=CN=squid,OU=groups,OU=UNIXs,OU=Group,OU=Samara,DC=DOMAIN,DC=local))-D <- "-D" прилипла к фильтру поиска

  2. Александр
    4 октября, 2012 at 12:23
    4

    На сколько я понимаю, мой пользователь adsquid не может авторизоваться, кстати вопрос, логин под которым авторизовываеться Сквид в домене и логин для LDAP должны совпадать?

  3. Александр
    4 октября, 2012 at 15:02
    5

    По поводу двух групп, тут все верно, разные контейнеры
    Буква Д не могла прилипнуть, вводил в три строки
    /usr/lib/squid3/squid_ldap_group -R -d -b «dc=DOMAIN,dc=local» \
    -f «(&(objectclass=user)(sAMAccountName=%v) memberOf=CN=%a,OU=groups,OU=UNIXs,OU=Group,OU=Samara,DC=DOMAIN,DC=local))»\
    -D [email protected] -W /etc/squid3/passwd dc

    т.е. каждая строка начиналась с нового ключа

    • 4 октября, 2012 at 15:11
      6

      А если между
      <...>p,OU=Samara,DC=DOMAIN,DC=local))»
      и
      \
      поставить пробел?

  4. Александр
    4 октября, 2012 at 15:15
    7

    То же самое :(
    Кстати, в каком ввиде заводить пользователя?
    [email protected]
    user
    ?

    • 4 октября, 2012 at 15:22
      8

      С пользователем все нормально.
      Фраза
      Connected OK
      говорит, что аутентификация прошла удачно.
      А вот поиск пользователя в группе – не происходит.
      Покажите скриншоты с OU и размещением всех задействованных групп в OU.

  5. Александр
    4 октября, 2012 at 17:01
    9

    Сейчас вот что
    /usr/lib/squid3/squid_ldap_group -R -d -b “DC=DOMAIN,DC=LOCAL” -f “(&(objectclass=user)(sAMAccountName=%v)(memberOf=CN=%a,OU=groups,OU=UNIXs,OU=Group,OU=Samara,DC=DOMAIN,DC=local))” -D [email protected] -W /etc/squid3/passwd dc
    test squid
    squid_ldap_group WARNING, could not bind to binddn ‘Invalid credentials’
    ERR

    • 4 октября, 2012 at 19:39
      10

      а сейчас он говорит, что неверный пароль или имя пользователя.

  6. 4 октября, 2012 at 19:37
    11

    на скриншоте не видно название групп. Так же хотелось бы увидеть скриншот пользователя test на вкладке с членством в группах.

  7. Александр
    4 октября, 2012 at 19:58
    12

    Я это понимаю.
    неправильный логин/пароль в моем случае [email protected]?
    пользователя стандартно же в squid заводим? – htpasswd -c /etc/squid3/passwd ubuntu (для первого захода)
    Какого вида учетку следует завести?

    • 5 октября, 2012 at 08:54
      13

      Под рукой squid не имею, но что-то мне говорит, что /etc/squid3/passwd должен содержать пароль в виде обычного текста. И htpasswd тут нет необходимости использовать…

    • 5 октября, 2012 at 08:55
      14

      для теста можно заменить параметр
      -W /etc/squid3/passwd
      на
      -w “пароль_пользоватьеля”
      и проверить работоспособность.

  8. Александр
    5 октября, 2012 at 09:24
    15

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

    • 5 октября, 2012 at 09:49
      16

      если пароль указывается в командной строке, то -W меняется на -w (в нижнем регистре). Пароль при этом – в кавычках

  9. Александр
    5 октября, 2012 at 10:06
    17

    squid_ldap_group WARNING, could not bind to binddn ‘Invalid credentials’
    ERR

    Эффект тот же, в какую сторону копать, уже и не знаю ((

    • 5 октября, 2012 at 10:59
      18

      полностью команду можно увидеть?

  10. Александр
    5 октября, 2012 at 11:01
    19

    /usr/lib/squid3/squid_ldap_group -R -d -b “DC=bla,DC=LOCAL” -f “((objectclass=user)(sAMAccountName=%v)(memberOf=CN=%a,OU=groups,OU=UNIXs,OU=Group,OU=Samara,DC=bla,DC=local))” -D [email protected] -w “pass” DC

    • 5 октября, 2012 at 11:28
      20

      Явно тут какая-то проблема с именем и паролем.
      Попробуйте создать нового доменного пользователя, задать ему необходимые настройки и пароль попроще без спецсимволов.
      И попробовать использовать его имя и пароль вместо
      -D [email protected] -w «pass»

  11. Александр
    5 октября, 2012 at 11:34
    21

    Ошибку с пользователем поправил, стояла галка в свойствах users AD – Без предварительной проверки Kerberos.

    Но ошибка фильтра так и осталась…
    /etc/squid3# /usr/lib/squid3/squid_ldap_group -R -d -b “DC=GRADIENT-SAMARA,DC=LOCAL” -f “((objectclass=user)(sAMAccountName=%v)(memberOf=CN=%a,OU=groups,OU=UNIXs,OU=Group,OU=Samara,DC=GRADIENT-SAMARA,DC=local))” -D [email protected] -W /etc/squid3/passwd saddc1
    test squid
    Connected OK
    group filter ‘((objectclass=user)(sAMAccountName=test)(memberOf=CN=squid,OU=groups,OU=UNIXs,OU=Group,OU=Samara,DC=GRADIENT-SAMARA,DC=local))’, searchbase ‘DC=GRADIENT-SAMARA,DC=LOCAL’
    squid_ldap_group WARNING, LDAP search error ‘Bad search filter’
    ERR

    • 5 октября, 2012 at 11:56
      22

      вижу небольшую разницу
      group filter ‘((objectclass=user)…..
      group filter ‘(&(objectclass=user)….

  12. Александр
    5 октября, 2012 at 11:58
    23

    Да, все отлично, спасибо огромное, с меня чутка позже благодарность придет :)

  13. Сергей
    22 октября, 2012 at 16:05
    24

    Максим, подскажите пожалуйста, каким образом можно использовать следующую вложенную структуру в AD:
    DOMAIN.RU/Первая группа/Вторая группа

    OU состоят из нескольких русских слов с пробелами, привести здесь их не могу
    Как заставить хелпер принять?

    • 23 октября, 2012 at 22:28
      25

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

  14. tankredo
    30 января, 2013 at 18:22
    26

    /usr/lib/squid3/squid_ldap_group -R -d -b “DC=domain,DC=local” -f “(&(objectclass=user)(sAMAccountName=%v)(memberOf=CN=%a,OU=group,DC=domain,DC=local))” -D [email protected] -w 7777777 -h 10.10.10.10
    test asu
    Connected OK
    group filter ‘(&(objectclass=user)(sAMAccountName=test)(memberOf=CN=asu,OU=group,DC=ck,DC=domain,DC=local))’, searchbase ‘dc=domain,dc=local’
    ERR

    Пользователь test входит в группу asu и все, подскажите как правильно фильтр писать

    • 4 февраля, 2013 at 20:37
      27

      Нужно увидеть скрин структуры дерева OU домена ck.domain.local от корня до OU где размещены test и asu.

  15. Сергей
    1 февраля, 2013 at 15:27
    28

    При отключении поддержки ip v6 squid не может запустить /usr/lib/squid_ldap_group

    • 4 февраля, 2013 at 20:38
      29

      Сергей, это вопрос или констатация факта? )

  16. nokogerra
    3 апреля, 2013 at 14:50
    30

    А как писать фильтр к squid_ldap_group -f если пользователь и группа в которую он входит лежат в разных контейнерах? к контейнеру где находится группа?

    • 3 апреля, 2013 at 21:30
      31

      Я так понял, что вопрос уже не актуален? )

  17. nokogerra
    3 апреля, 2013 at 15:41
    32

    все, оттестировал, да так работает прекрасно.

  18. nokogerra
    4 апреля, 2013 at 12:35
    33

    Такой вопрос:
    Присутствие только одного метода аутентификации не кажется надежным, как совместить например метод negotiate c squid_ldap_group хелпером (как в данной статье) с basic методом с тем же хелпером (например если не отработала прозрачная авторизация чтобы пользователи домена могли вручную ввести учетный данные) + basic на основе файла с логинами/паролями (для тех, кто не имеет доменных учетных данных но интернет ему нужен).
    По поводу последнего – вводную статью читал, вот так выглядит этот кусок у Вас для всех прошедших авторизацию:

    auth_param basic program /usr/lib/squid3/ncsa_auth /etc/squid3/squidusers
    acl lan proxy_auth REQUIRED
    http_access allow lan

    но если смешанная авторизация и “все прошедшие авторизацию” не вариант пробую так:
    auth_param basic program /usr/lib/squid3/ncsa_auth /etc/squid3/squidusers
    acl lan src "/etc/squid3/squidusers"
    http_access allow lan

    и получаю:
    Restarting Squid HTTP Proxy 3.x: squid32013/04/04 15:25:17| aclIpParseIpData: Bad host/IP: 'squiduser1:z2brw4Kjh3aww' in 'squiduser1:z2brw4Kjh3aww', flags=0 : (-2) Name or service not known
    FATAL: Bungled squid.conf line 19: acl basic_users src "/etc/squid3/squidusers"

    то есть src в виде этого файла ему не нравится.
    а как будет выглядеть basic с squid_ldap_group вообще слабо представляю, нужно ли указывать spn? вообще можете привести пример кода?

    • 6 апреля, 2013 at 01:18
      34

      Давайте по-порядку…
      1. basic методом с тем же хелпером
      боюсь, что это не будет работать. Я нигде не видел документального опровержения, но и практического подтверждения также не видел…
      2. basic на основе файла с логинами/паролями
      этим можно дополнить Kerberos аутентификацию. Но на практике я столкнулся с тем, что браузеры (по крайней мере Firefox) начинаю надоедать пользователю окном с вводом логина и пароля, даже когда этого не должно быть… Обходное решение я нашел, оно заключается в том, чтобы в правильном порядке расставить http_access. То есть, сначала необходимо расположить правила, разрешающие что-либо без использования аутентификации, затем запрещающие, затем правила с аутентификацией, затем, внимание!!!
      http_access deny !allusers all
      http_access deny all

      ,где allusers – это acl вида acl allusers proxy_auth REQUIRED.
      Ну и соответственно, должно быть указано 2 вида аутентификации (negotiate а после него basic).
      3. то есть src в виде этого файла ему не нравится.
      это логично. Давайте посмотрим man.
      Там сказано, что тип отбора src позволяет указывать только IP-адреса или диапазона, а вы туда пытаетесь пользователей засунуть. Вот он и ругается “Bad host/IP”.
      Чтобы squid из файла ожидал именно пользователей, ему необходимо указать тип отбора proxy_auth, на вашем примере, не:
      acl basic_users src "/etc/squid3/squidusers"
      а
      acl basic_users proxy_auth "/etc/squid3/squidusers"
      Надеюсь, что понятно объяснил )

      • nokogerra
        8 апреля, 2013 at 08:37
        35

        1. Видел кучу примеров, но все использовали 1 метод basic (не в комплекте с negotiate), перепробовал много вариантов (таких примерно auth_param basic program /usr/lib/squid/squid_ldap_auth -b ou=People,dc=asosh,dc=ru -f (uid=%s) -h 192.168.0.4) – в таких случаях сквид вообще переставал работать, при указании spn: auth_param basic program /usr/lib/squid3/squid_kerb_auth -s HTTP/[email protected] запрашивает учетные данные (если зашел не под доменным юзером), но не авторизует при вводе правильных данных ([email protected], domain\user,[email protected] – не работает).
        3. Просто видел множество примеров где acl имели такой вид acl lan src “путь к файлу”
        при acl basic_users proxy_auth “путь к файлу” запрашивает учетный данные и не принимает их, правда сообщений никаких нет (пользователь в файле например squiduser1, соответственно в поле логина ввожу просто squiduser1)
        Кстати когда читал вводную статью пробовал basic без всяких ad и керберосов, для теста – также не работало

        • 8 апреля, 2013 at 21:46
          36

          1. Недостаток basic метода в том, что все учетные данные по сети передаются открытым текстом. Это очень опасно, если при этом пытаться передать доменные учетные данные. Любой человек воткнувшийся в Вашу сеть поимеет ее буквально в течении нескольких минут… Почему это у вас не заработало, даже не знаю в какую сторону направить, т.к. сам такое не реализовывал..
          2. вид acl lan src «путь к файлу» возможен, но в файле нужно указать не имена пользователей, а IP адреса, подсети и т.п. А вот по поводу acl basic_users proxy_auth «путь к файлу»…каким образом Вы создавали файл и как добавляли туда пользователей?

          • nokogerra
            9 апреля, 2013 at 06:04
            37

            Вобщем наверное Вы правы насчет ненадежности basic, но сделать basic авторизацию для недоменных пользователей имхо все же стоит, делал файл с паролями как описано в https://www.k-max.name/linux/avtorizaciya-autentifikaciya-squid/ с помощью htpasswd, единственное – не заморачивался с ограничением прав на этот файл, но врядли дело в этом.

            • 9 апреля, 2013 at 15:23
              38

              Полностью согласен.
              Но перед тем как настраивать обе аутентификации, стоит заставить работать их поотдельности.
              Попробуйте снова создать файл паролей, корректно задать права доступа и при подключении пользователей – смотреть логи.

  19. nokogerra
    8 апреля, 2013 at 12:17
    39

    Пока на забыл еще вопрос:
    допустим есть желание поднять 2 прокси (для балансировки нагрузки и отказоустойчивости), я представляю себе это так: 2 машины, 1 запись в dns (на 2 адреса), 2 ptr записи (2 адреса с указанием на 1 доменное имя) – то есть при указании в политике доменного имени будет работать обычный раунд-робин механизм и клиенты будут попадать на разные прокси сервера, но вот достаточно ли 2м машинам 1й spn, или для каждой нужен свой spn? если 1 spn – для обоих машин будет 1 кейтаб, приемлемо ли это?
    2й вопрос: в режиме авторизации сквид может проксировать не только http, задавали политиками прокси для еще каких-то клиентов, например почтовых, и т.д.? если да – поделитесь набором шаблонов (при наличии). Просто есть желание после внедрения прокси отключить доступ до шлюза всем клиентам кроме избранных и прокси серверов, соответственно если не будет указан прокси для например thunderbird`а, клиенты останутся без почты.

    • 8 апреля, 2013 at 22:18
      40

      Kerberos не будет корректно работать с одной записью DNS на 2 хоста. Kerberos вообще капризный в части экспериментов с DNS. Хотя… ничто не стоит попытаться реализовать такое.
      Заморачиваться с такой конфигурацией, имхо, того не стоит. Если на сервере стоит 1 сквид,то при падении сервера и наличии под рукой пары конфигурационных файлов и дистрибутива развернуть новую машину займет ну 30-50 минут.
      Сквид может проксировать только HTTP, FTP, gopher, SSL, DNS (только для резолвинга проходящих запросов).
      По поводу SMTP, POP3 – это трудно проксируемые протоколы. Для этого нужно свой почтовик поднять, который будет посредником между внешней почтой и локальным клиентом.
      Я могу предположить, к чему вы интересуетесь такими вопросами, видимо, чтобы не пускать пользователей через NAT и контролировать каждый байтик. )
      Это правильный путь с точки зрения безопасности, но для маленьких организаций иногда все же приходится делать исключения для “избранных”…
      Тут стоит задача – ограничить круг этих избранных до минимума )

      • nokogerra
        9 апреля, 2013 at 06:10
        41

        Хочу 2 сквида также для балансировки нагрузки, клиентов просто ~100 а будет еще больше, поэтому все же буду смотреть в эту сторону, видимо придется просто делать 2 прокси :(

        • 9 апреля, 2013 at 15:21
          42

          Думаю, что если клиентов менее Х-тысяч, то задумываться о балансировке вряд ли придется. Я могу понять Ваше желание, после того, как удалось понять принцип работы, хочется построить мега-систему. )))
          Сам так же рвался. Но для экспериментов лучше использовать всякие разные виртуальные машины.
          squid довольно стабильный и производительный сервис, если стоит на стабильном/LTS дистрибутиве.

          • nokogerra
            9 апреля, 2013 at 16:28
            43

            Хм, Вы и тут правы, сегодня пообщался с человеком который уже давно не админит (нанче интегратор sun), но говорит что когдато через 2.6 сквид выпускал 2.5 к пользователей безо всяких балансировок 2 процессора с 2мя нитками было, 4гб рамы и 15к диск под кэш – все летало.
            P.S. насчет вм – у меня и так все на вм, vsphere 5.0u1, реальных машин в организации по пальцам посчитать.
            P.S.S. по поводу basic`а – уже переделывал файл паролей, сегодня не было возможности заняться этим, но завтра буду курить, если будет результат – отпишу.
            Ах да, и спасибо Вам за блог – самый доступно подаваемый материал по nix который я видел.

            • 9 апреля, 2013 at 16:30
              44

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

    • 8 апреля, 2013 at 22:22
      45

      ну и еще, любое офисное приложение (ICQ, jabber … ) может проксироваться, т.к. использует для коннекта http\https, но нестандартный порт. Соответственно, разрешив работу на заданном порту в параметрах squid – разрешается работа приложения.
      Если приложение имеет в своих настройках галку прокси-сервер, значит оно с 90% вероятностью поддерживает аутентификацию. Разработчики в этом заинтересованы, т.к. знают, что бизнес использует их приложения )

  20. nokogerra
    8 апреля, 2013 at 12:37
    46

    к последнему посту: к почте однако socks пркоси нужен :(

  21. Андрей
    9 апреля, 2013 at 14:46
    47

    Добрый день. Спасибо Вам за ваш труд. Ваши статьи очень помогли. Вопрос: если имена групп c именами пользователей с пробелами то как можно хелпер заставить проверять их существование?

    • FeanaR
      3 декабря, 2013 at 10:55
      48

      Андрей, если имя группы с пробелом, то можете попробовать поставить вместо пробела %20 в squid.conf. Если группу переименовать нет варианта, конечно.

      А вот если пробел в имени пользователя (как мне досталось по наследству от предыдущего сисадмина), то тут возникает проблема, решения которой я пока не вижу абсолютно… Переименовывать пользователей уж очень не хочется.

      • 3 декабря, 2013 at 11:28
        49

        Чтобы решить данную проблему, необходимо понимать, какую кодировку использует каждый модуль (которых при построении доменной аутентификации уж очень много) squid и каждый модуль отображения статистики (которых в случае разбора логов squid так же много). И уже исходя из этого, путаться производить какие-то манипуляции с текстовыми файлами…

  22. Андрей
    9 апреля, 2013 at 15:25
    50

    И еще вопрос, если в AD группы пользователей интернета в разных OU то мне использовать несколько хелперов или можно как то обойтись одним?

    • 9 апреля, 2013 at 15:32
      51

      можно один squid_ldap_group, но фильтр необходимо составить правильно.

  23. Андрей
    29 апреля, 2013 at 18:09
    52

    Добрый день. Помогите разобраться со следующей ситуацией. Или подскажите куда копать. Необходимо сделать отказоустойчивое решение SQUID c с доменной авторизацией и разграничением доступа исходя из членства в группах. Выбрал протокол UCARP. По отдельности сервера настроил. По отдельности на серверах доступ предоставляется и все ОК, но когда CARP подменяет статический IP на виртуальный то доступ к серверу есть а авторизация не проходит (использую полное имя сервера). Причем если разрешаю всей подсети все, то отказоустойчивость работает. Сначала делал KeyTab отдельно для каждого сервера, потом сделал максимально одинаковую конфигурацию. Не авторизует и все.
    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

    В настройках браузера пишу sag01-nk – не работает
    sag011-nk – работает

    При поднятии сетевого интерфейса на мастере выполняется:
    /etc/vip-up.sh
    #!/bin/sh
    ip addr add 191.168.3.140/20 dev eth1 # назнач 140 на eth0
    соответственно на упавшем но живом:
    /etc/vip-down.sh
    #!/bin/sh
    ip addr del 191.168.3.140/20 dev eth1
    Спасибо.

    И всех с праздником великой победы.

    Спасибо.

    • 30 апреля, 2013 at 11:04
      53

      Доброго времени, Андрей.
      Мне неясенвопрос: оба squid настроены на какое доменное имя/IP?
      Так же есть совет: приветные подсети (как я понял, вы для этого выдали 191.168.3.138 и 191.168.3.139) я бы вообще сделал из другой подсети (например 10.0.0.х).
      Необходимо заставить работать оба squid поочереди на 191.168.3.140 sag01-nk sag01-nk.domain.com, а когда оба будут корректно отрабатывать – обединить их в CARP.

      Но что-то мне подсказывает, что доменная аутентификация не будет так работать, но попробовать стоит…

  24. Андрей
    7 мая, 2013 at 11:15
    54

    Добрый день. Сегодня буду экспериментировать. За рекомендации спасибо, сегодня попробую. На текущий момент у одного squid доменное имя sag011-nk IP 191.168.3.138 другой sag012-nk IP 191.168.3.139 подразумевалось что общее имя (по которому будут обращаться все пользователи) будет sag01-nk 191.168.3.140. Этот IP подставляется CARP. По отдельности – если обращаться к каждому, доменная авторизация работает и все ок Если не включать доменную авторизацию то CARP тоже работает при обращении r sag01-nk. Но как только подменяются IP и включена доменная авторизация – интернет не раздается – нет авторизации. очу сейчас попробовать сделать индентичные сервера и основной IP прописать сразу 191.168.3.140 а 191.168.3.138 прописать как дополнительные на сетевые карты чтоб можно было управлять сервером. Конфликт IP думаю CARP не допустит. Единственный конфликт это с именем сервера может быть если прописаны в HOSTNAME одинаковые имена. Влияют ли они на авторизацию не знаю и будут ли конфликтовать 2 одинаковых имени в сети тоже не знаю. Вот еще вопрос: как лучше менять IP на сетевой c помощью ip addr add 191.168.3.140/20 dev eth1 или использовать ifconfig add ???

  25. Андрей
    7 мая, 2013 at 11:17
    55

    по поводу подсети – изменить ничего не получится. Сеть большая и 3-й поддиапазон выдан под сервера. те используем то что дают :)

  26. Андрей
    7 мая, 2013 at 11:41
    56

    не получится такое решение. Если одоим серверам дать одинаковые IP то в нормальном режиме, когда они оба в сети будет конфликт. Не подскажите, может есть другой механизм реализации отказоустойчивости для squid? идея простая, при отключении одного из серверов другой автоматом начинает работать без перенастройки пользователей + все возможности авторизации и использования для прав доступа доменных групп.

    • 8 мая, 2013 at 10:38
      57

      я немного другой алгоритм имел ввиду:
      1. оба сервера выключены.
      1.а. У клиентов прописан сервер sag01-nk
      2. Включаем первый (приватный IP 191.168.3.138)
      3. Задаем этому серверу IP 191.168.3.140 вместо 191.168.3.138 (классически, без CARP), настраиваем доменную аутентификацию с именем sag01-nk
      4. выключаем сервер
      5. Включаем второй сервер (приватный IP 191.168.3.139)
      6. Задаем этому серверу IP 191.168.3.140 вместо 191.168.3.139 (классически, без CARP), настраиваем доменную аутентификацию с именем sag01-nk
      7. Запускаем первый сервер (но без подключения к сети)
      8. Перетыкаем провод из второго в первый.
      9. Траблшутим работоспособность аутентификации при ручном перетыкании. Если заработает (в чем я сомневаюсь ))) ), то настраиваем CARP, при этом, приватные адреса возвращаем на исходную, а общий (191.168.3.140) отдаем CARP.

  27. Андрей
    8 мая, 2013 at 10:20
    58

    Добрый день. Странная ситуация. Проинсталировал сервер с 0. Основным IP назначил 191.168.3.140 (sag01-nk) дополнительный IP на эту же карту 191.168.3.138 (sag011-nk). На 138 все работает а на 140 не проходит авторизация. Теория что если IP не основной то не работает себя не оправдала. Что то с этим IP – что понять не могу. Keytab один для всех. Авторизация KERBEROS проходит. Проверка на вхождение в группы AD (ручная) проходит. В чем дело никак не пойму. Где копать…..

    • 8 мая, 2013 at 10:40
      59

      Попробуйте по алгоритму, который я написал.

  28. Андрей
    8 мая, 2013 at 16:48
    60

    Спасибо. Алгоритм понятен. Так и сделал. Только изначально сетевой карте прописал 140 адрес sag01-nk. Что получилось??? не проходит доменная авторизация у пользователей. Даже без подменного адреса. Но ведь все работало… Подробно описал в посте где описывается авторизация KERBEROS. Спасибо вам за подсказки. Очень профессионально, надеюсь и дальше поможете.

  29. nokogerra
    20 мая, 2013 at 08:15
    61

    Максим, приветствую.
    Ввел в эксплуатацию прокси и получил проблему про которую Вы писали:
    периодически у пользователей рандомно запрашивается логин/пароль (а поскольку basic авторизации нет, то лечится это только логоф/логон), при этом в логах cache.log:
    2013/05/20 08:49:05| authenticateNegotiateHandleReply: Error validating user via Negotiate. Error returned 'BH gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide mor$
    2013/05/20 08:49:25| authenticateNegotiateHandleReply: Error validating user via Negotiate. Error returned 'BH gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide mor$
    2013/05/20 08:58:15| WARNING: All redirector processes are busy.
    2013/05/20 08:58:15| WARNING: 5 pending requests queued
    2013/05/20 08:58:15| Consider increasing the number of redirector processes in your config file.

    С редиректором отказ аутентификации не связан, хотя бы из-за разнесенности по времени. пользователей порядка 80, auth_param negotiate children 50, на количество negotiateauthenticator processes не жалуется, поставил -d ключ в squid_ldap_group, может будет подетальнее информация, можете подсказать что-нибудь?

    • nokogerra
      20 мая, 2013 at 08:30
      62

      хм, нет, теперь про успех пишет типо такого:
      Connected OK
      group filter ‘(&(objectclass=user)(sAMAccountName=nparshina)(memberOf=cn=inet_allow,ou=squidtest_u,ou=MFC,dc=mfk-22,dc=local))’, searchbase ‘dc=mfk-22,dc=local’
      а про фэйл также (authenticateNegotiateHandleReply: Error validating user via Negotiate. Error returned ‘BH gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information ‘)

    • 20 мая, 2013 at 09:10
      63

      Судя по логам, squid не хватает количества редиректоров. Покажите конфиг с настройками редиректоров.
      В логе, указано, что в очереди к редиректору стоит 5 запросов (WARNING: 5 pending requests queued), т.к. все доступные редиректоры заняты (WARNING: All redirector processes are busy.)

      • nokogerra
        20 мая, 2013 at 10:48
        64

        я это вижу, поэтому и спросил сначала на rejik.ru
        http://rejik.ru/bb_rus/viewtopic.php?f=1&t=1175&p=5595#p5595
        но разработчик логично заметил что связь между отваливанием прозрачной аутентификации и нехваткой нитей редиректора сомнительна, к тому же в логах эти события по времени разнесены, но я добавил url_rewrite_children 6, события о нехватке процессов редиректора больше не появлялись, а вот сбой аутентификации – регулярно.

        • 20 мая, 2013 at 11:24
          65

          Тут без дебага не обойтись.
          Могу порекомендовать поиграться с section 28 Access Control и section 29 Authenticator, section 29 NTLM Authenticator, section 29 Negotiate Authenticator

          • nokogerra
            20 мая, 2013 at 11:40
            66

            извиняюсь, ответил не в ветке обсуждения, удалите пожалуйста другой комментарий.
            Я правильно понимаю что уровни Authenticator, NTLM Authenticator и Negotiate Authenticator секции 29 придется тестировать по очереди ( Each pair is set left-to-right. If a section is mentioned twice the last mentioned level is used)?

            • 20 мая, 2013 at 11:52
              67

              section 29 включает в себя Authenticator, NTLM Authenticator и Negotiate Authenticator. Мы же debug_options указываем в виде debug_options номер_секции,уровень_журналирования. Тут нет возможности указать Authenticator, NTLM Authenticator или Negotiate Authenticator. Только цифру 29

              • nokogerra
                20 мая, 2013 at 13:23
                68

                хм, подскажете где мне помогут это расшифровать? на 6м уровне вроде в этому проблема:

                2013/05/20 15:22:43.791| negotiate/auth_negotiate.cc(602) releaseAuthServer: releasing Negotiate auth server '0xa34a648'
                2013/05/20 15:22:43.791| authenticateNegotiateHandleReply: Successfully validated user via Negotiate. Username 'oYGyMIGvoAMKAQChCwYJKoZIgvcSAQICooGaBIGXYIGUBgkqhkiG9xIBAgICAG+BhDCBgaADAgEFoQMCAQ+idTBzoAMCAReibARqTKosS9XkzxwUHOCXVm5+uRoGRzHciRdrIfNU9Ii5i3INgUtaPzUi4mmEJpsi3nyN8BCo2pYYBsrDTCbTlzUanZifbAHo/Usl6nD7F7vGqMJO9620colW7vrbQEOlIc2pktECTl5Ugb5fZQ=='
                2013/05/20 15:22:43.791| AuthNegotiateUserRequest::authenticate: authenticated user [email protected]
                2013/05/20 15:22:43.791| authenticateAuthUserMerge auth_user '0x1a74d648' into auth_user '0x125019e0'.
                2013/05/20 15:22:43.791| NegotiateUser::~NegotiateUser: doing nothing to clearNegotiate scheme data for '0x1a74d648'
                2013/05/20 15:22:43.791| AuthUser::~AuthUser: Freeing auth_user '0x1a74d648' with refcount '0'.
                2013/05/20 15:22:43.791| negotiate/auth_negotiate.cc(606) releaseAuthServer: No Negotiate auth server to release.
                2013/05/20 15:22:43.791| authenticateValidateUser: Validated Auth_user request '0x202cf878'.
                2013/05/20 15:22:43.791| authenticateValidateUser: Validated Auth_user request '0x202cf878'.
                2013/05/20 15:22:43.791| authenticateValidateUser: Validated Auth_user request '0x202cf878'.
                2013/05/20 15:22:43.799| negotiate/auth_negotiate.cc(606) releaseAuthServer: No Negotiate auth server to release.
                2013/05/20 15:22:43.799| AuthUserRequest::~AuthUserRequest: freeing request 0xa4eafc0
                2013/05/20 15:22:44.132| negotiate/auth_negotiate.cc(606) releaseAuthServer: No Negotiate auth server to release.
                2013/05/20 15:22:44.132| AuthUserRequest::~AuthUserRequest: freeing request 0x202cf878
                2013/05/20 15:22:44.206| negotiate/auth_negotiate.cc(606) releaseAuthServer: No Negotiate auth server to release.
                2013/05/20 15:22:44.206| AuthUserRequest::~AuthUserRequest: freeing request 0xa3167c8

                попробовал поставить 9й уровень – за секунду несколько страниц лога, не представляю как это мониторить.
                Вопрос такой: нет смысла увеличивать количество процессов squid_ldap_group?

              • 20 мая, 2013 at 13:44
                69

                1. При этом, в логах AD нет ли каких-то ошибок?
                2. Думаю, что стоит написать на unixforum об этом.
                3. стоит попробовать увеличить количество предложенных хелперов

              • 20 мая, 2013 at 16:16
                70

                Как вариант, можно еще добавить параметр external_acl_type ldap_verify ttl=1200(протестировать) %LOGIN -//-

              • 20 мая, 2013 at 16:23
                71

                Кстати, вот тут нашел аналогичную беседу. Может быть будет полезным…

  30. nokogerra
    20 мая, 2013 at 16:49
    72

    почему-то не могу ответить на последние Ваши комментарии.
    1. по поводу AD – только 1 варнинг (не ошибка):

    В течение предыдущего 24-часового периода некоторые клиенты пытались выполнить привязки LDAP, а именно:
    (1) Привязку SASL (согласование, Kerberos, NTLM или выборка) LDAP без требования подписи (проверки целостности), или
    (2) Простую привязку LDAP, которая была выполнена для подключения с открытым (не зашифрованным SSL/TLS) текстом

    Данный сервер каталога в настоящий момент не настроен на отклонение привязок такого типа. Безопасность сервера можно существенно повысить, если настроить его на отклонение таких привязок. Дополнительные сведения о том, как сделать соответствующие изменения в конфигурации сервера, см. в статье по адресу: http://go.microsoft.com/fwlink/?LinkID=87923.

    Общие сведения о числе этих привязок, полученных за последние 24 часа, приведены ниже.

    Можно включить дополнительную регистрацию для фиксации события каждый раз, когда клиент выполняет такую привязку, включая сведения о том, на каком клиенте она сделана. Для этого следует поднять параметр для категории регистрации событий "События интерфейса LDAP" до уровня 2 или выше.

    Число простых привязок, выполненных без SSL/TLS: 68
    Число привязок согласование/Kerberos/NTLM/выборка, выполненных без подписи: 62

    Но это скорее говорит о том, что DC не будет отклонять ldap запросы и krb аутентификацию пока это не настроено.
    2. Как увеличить количество процессов хелпера не ясно, все что выдает поиск по поводу squid_ldap_group children и похожим – это информация по negotiate children.
    3. В чем смысл external_acl_type ldap_verify ttl=1200? Имеются в виду credentials ttl? Если да, то получается пользователям придется проходить прозрачную аутентификацию даже чаще, что ухудшит ситуацию, или я не о том думаю? Если не о том, то как должна выглядеть это опция, просто отдельной строкой external_acl_type ldap_verify ttl=1200?
    4. По Вашей ссылке на беседа, а 1 пост и дальше cache.log со сбоем аутентификации, при чем у него squid введен в домен с помощью mskutil, у меня – нет.

    • 20 мая, 2013 at 17:00
      73

      > 1. по поводу AD — только 1 варнинг (не ошибка):
      Такие ошибки тоже имелись в моей системе.
      > 2. Как увеличить количество процессов хелпера не ясно, все что выдает поиск по поводу squid_ldap_group children и похожим — это информация по negotiate children.
      Мне тоже было интересно, как вы реализуете предложенное решение )))
      > 3. В чем смысл external_acl_type ldap_verify ttl=1200? Имеются в виду credentials ttl? Если да, то получается пользователям придется проходить прозрачную аутентификацию даже чаще, что ухудшит ситуацию, или я не о том думаю? Если не о том, то как должна выглядеть это опция, просто отдельной строкой external_acl_type ldap_verify ttl=1200?
      Да, это именно credentials ttl. То есть время “кэширования” что ли удачных запросов аутентификации. Можно значение поставить более, но нужно тестировать. В теории это должно снизить количество запросов к AD и нагрузку на модули аутентификации.

      • nokogerra
        20 мая, 2013 at 17:08
        74

        1. Как решили? Так как описано в варнинге?

        • 22 мая, 2013 at 22:43
          75

          нет, игнорил )
          Руки не доходили…

  31. Sergey
    28 мая, 2013 at 17:07
    76

    Здравствуйте!

    Попытался настроить аутентификацию сквида через LDAP на FreeBSD.
    Домен на Windows 2003. Создал в домене пользователя для прокси Proxys и группу для инета InetUsers.
    При выполнении команды в консоле /usr/local/libexec/squid/squid_ldap_group -R -d -b «dc=DOMAIN,dc=local» -f «(&(objectclass=user)(sAMAccountName=%v)(memberOf=CN=%a,OU=Users,DC=DOMAIN,DC=local))»
    -D [email protected] -w 123456 192.168.1.1
    Proxys InetUsers

    получаю ошибку
    Connected OK
    group filter ‘(&(objectclass=user)(sAMAccountName=Proxys)(memberOf=CN=InetUsers,OU=Users,DC=DOMAIN,DC=local))’, searchbase ‘DC=DOMAIN,DC=local’
    ERR

    Как мне найти из-за чего фильтр группы не работает?
    2 день бьюсь. По разному пробовал.
    Команда ldapsearch и хелпер squid_ldap_user работают нормально.
    Какую диагностику еще можно сделать или где посмотреть причину?

    • 30 мая, 2013 at 09:27
      77

      Здравствуйте, покажите скриншот дерева объектов Active Directory, где у вас размещена группа InetUsers?

  32. Sergey
    3 июня, 2013 at 07:48
    78

    Спасибо.
    Разобрался сам. =)
    Оказалось, что контейнер Users имеет адрес CN=Users,DC=domen,DC=local , а я думал OU=Users,DC=domen,DC=local. Контейнер Users встроен в АД изначально. Помогло то, что я заглянул в домен с помощью ADSI editor-a.
    Остался пока только один вопрос: При наборе адреса в броузере появляется стандартное окно ввода логина и пароля. После набора правильных реквизитов все работает, а я думал, что логин и пароль броузер должен передавать автоматом. Это так правильно или у меня опять чего-то неправильно настроено?

  33. Sergey
    3 июня, 2013 at 09:09
    80

    Настраивал IE и firefox вручную.
    Результат одинаков.
    Керберос не настраивал.

    • 3 июня, 2013 at 10:29
      81

      Что у Вас указано в auth_param?

  34. Sergey
    3 июня, 2013 at 10:43
    82

    Почему-то не могу вставить сообщение

  35. Sergey
    3 июня, 2013 at 10:44
    83

    Вот кусок squid.conf:
    auth_param basic program /usr/local/libexec/squid/squid_ldap_auth -R -v 3 -b DC=domen,DC=local -D [email protected] -w 123456 -f “sAMAccountName=%s” -u CN -P 192.168.1.1:389
    Подскажите, как надо модифицировать auth_param basic program… ?

    • 3 июня, 2013 at 10:47
      84

      Вы используете basic аутентификацию, согласно которой вполне естественно, что браузер запрашивает логин/пароль. Если необходима прозрачная аутентификация, то нужно настроить NTLM или Kerberos.

  36. Sergey
    3 июня, 2013 at 10:50
    85

    Пишут, что NTLM не безопасен. А кербероса на PFSENSE нет. Надо ставить вручную с большим геморроем.

    • 3 июня, 2013 at 10:52
      86

      Все верно пишут )))

    • 3 июня, 2013 at 10:52
      87

      Если хочется более-менее готовое решение, попробуйте zentyal. Но это Linux.

    • 3 июня, 2013 at 11:43
      88

      Мало того, если считать NTLM небезопасным, то при basic у вас вообще пароли открытым текстом гуляют по сети. Это еще веселей )

  37. Андрей
    4 июня, 2013 at 15:09
    89

    Не работает… Правда я с самбой 4 вожусь.

    Ось: Ubuntu Server 13.04
    Samba: 4.0.0
    provision: samba-tool domain provision \—realm=ODM.LAN \—domain=ODM \—adminpass=’Pa$$w0rd’ \—dns-backend=BIND9_DLZ \—server-role=dc \—use-xattr=yes \—use-rfc2307 \—host-ip=10.1.1.1

    samba-tool domain level show
    Domain and forest function level for domain 'DC=odm,DC=lan'

    Forest function level: (Windows) 2003
    Domain function level: (Windows) 2003
    Lowest function level of a DC: (Windows) 2008 R2

    Squid: 3.1.20
    Webmin: 1.630
    DHCP: 4.2.4
    BIND: 9.9.2-P1

    /usr/lib/squid3/squid_ldap_auth -u cn -b "cn=Users,dc=odm,dc=lan" 10.1.1.1
    Administrator Pa$$w0rd
    OK

    /usr/lib/squid3/squid_ldap_group -d -R -b "DC=odm,DC=lan" -f "(&(objectClass=user)(CN=%v)(memberOf=CN=%a,CN=Users,DC=odm,DC=lan))" odm-gw-srv01.odm.lan -D "[email protected]" -w "Pa$$w0rd" -K
    ldapuser Internet
    Connected OK
    group filter '(&(objectClass=user)(CN=ldapuser)(memberOf=CN=Internet,CN=Users,DC=odm,DC=lan))', searchbase 'DC=odm,DC=lan'
    squid_ldap_group WARNING, LDAP search error 'Operations error'
    ERR

    ldapsearch -h 10.1.1.1 -x -D [email protected] -W -b dc=odm,dc=lan "(&(CN=*)(memberOf=CN=Internet,CN=Users,DC=odm,DC=lan))" -LLL

    HELP!!! :( я уже второй месяц бьюсь над лдап. хорошо хоть бэйсик работает.

    • 6 июня, 2013 at 13:33
      90

      Доброго времени, Андрей.
      1. А если подправить фильтр до того вида, как у меня в статье?
      2. Вы уверены, что группа Internet размещена в контейнере Users?
      3. В каком виде (покажите пример строки лога) пользователи у вас попадают в логи squid?

      • Андрей
        6 июня, 2013 at 19:30
        91

        Здравствуйте, Mc.Sim.

        Доплнение. вернулся на U12.04.2 так как под него написаны многие туториалы, особенно меня интересует FreeRadius, OpenChange, Nginix, l2tp/ipsec VPN, OpenERP, WordPress, Squid. Все это под управлением Самбы.

        На Windows 2008 R2 с помощью NPS, Exchange, IIS, Forefront TMG/UAG, Sharepoint, OpenERP. Под управлением АD DS это все ставится от 1-2х дней до 2х недель(если опыт подрастерялся).

        Хотелось бы все это получить, но уже на линуксе. Тем более софт есть, только вот инфы настоящей под него кот наплакал.

        У вас на блоге очень много разъясняющей информации. Отличный источник.
        Все тестируется на VirtualBox 4.2 и GNS3 (0.8.3.1)
        Самбу ставил как тут:

        echo -e "deb http://inverse.ca/ubuntu precise precise\n\deb-src http://inverse.ca/ubuntu precise precise" > /etc/apt/sources.list.d/SOGo.list

        http://iabsis.com/EN/article/35-2/Samba4-installation

        Ставил через билд и просто из репозитория. Сейчас из репозитория – это openchange репозиторий.
        На официальной 4.0.0alpha18 от каноникал особо много не тестировал. Там много паники :)

        Да еще у меня два сетевых адаптера:

        # The loopback network interface
        auto lo
        iface lo inet loopback

        # The primary network interface
        auto WAN
        iface WAN inet static
        address 192.168.1.132
        netmask 255.255.255.0
        network 192.168.1.0
        broadcast 192.168.1.255
        gateway 192.168.1.1
        dns-nameservers 192.168.1.1 8.8.8.8
        # IPTable rules
        #post-up iptables-restore < /etc/iptables.up.rules

        # The secondary network interface internal
        auto LAN
        iface LAN inet static
        address 10.1.1.1
        netmask 255.255.255.0
        network 10.1.1.0
        broadcast 10.1.1.255
        dns-nameservers 10.1.1.1 #192.168.1.1
        dns-search odm.lan

        Так по среде вроде все описал.

        1. Если использую ваш вариант (группа теперь InternetAccess):

        root@odm-gw-srv01:~# /usr/lib/squid3/squid_ldap_group -R -d -b “dc=odm,dc=lan” \> -f “(&(objectclass=user)(sAMAccountName=%v)(memberOf=cn=%a,cn=Users,dc=odm,dc=lan))” \
        > -D [email protected] -w “Pa$$w0rd” odm-gw-srv01.odm.lan
        ldapuser InternetAccess
        squid_ldap_group WARNING, could not bind to binddn ‘Invalid credentials’
        ERR

        Кстати если обратили внимание то:

        /usr/lib/squid3/squid_ldap_auth -u cn -b "cn=Users,dc=odm,dc=lan" 10.1.1.1
        Administrator Pa$$w0rd
        OK

        Не использует информацию о пользователь/пароль (-D -w параметры). Такое ощущения что проблемма в самбе4, где то с керберосом или simple bind. Хотя если я пользуюсь:
        ldapsearch -h localhost -W -x -D "cn=ldapuser,cn=Users,dc=odm,dc=lan" -b "cn=Users,dc=odm,dc=lan" sAMAccountName=ldapuser
        Enter LDAP Password:

        То после ввода пароля вижу все данные из ldap каталога.

        2. Ответ тут:
        https://dl.dropboxusercontent.com/u/14719391/InternetAccess.jpg
        https://dl.dropboxusercontent.com/u/14719391/ldapuser.jpg
        В дополнении, с данным пользователем я спокойно залогиниваюсь на W8 машину.

        3.Прошу прощения, а какой лог вы имеете ввиду?
        access.log – содержит только пути от клиентов к ресурсам.
        cache.log – информацию о кэше днс и тд…

        Благодарю.

        • 12 июня, 2013 at 19:35
          92

          Хотелось бы все это получить, но уже на линуксе.

          Отличные планы *THUMBS UP*
          С samba4 будет весело )
          Я несколько недель назад поставил себе samba4 вместо старой samba3 на домашний сервер. Сходу победить не получилось даже в конфигурации рабочей группы %)
          Пока отложил и вернулся на 3…
          Попробуйте вместо
          (memberOf=cn=%a,cn=Users,dc=odm,dc=lan)
          указать
          (memberOf=cn=%a,ou=Users,dc=odm,dc=lan)

          3.Прошу прощения, а какой лог вы имеете ввиду?
          access.log — содержит только пути от клиентов к ресурсам.

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

  38. Герман
    12 июня, 2013 at 15:13
    93

    Здравствуйте.
    Прошу помощи в следующей проблеме…
    Использую basic авторизацию с определением принадлежности пользователя к группе.
    Обращаюсь к LDAP AD (MS Windows 2008 R2)

    Суть проблемы: при первом обращении пользователя к SQUID – авторизация запрашивается ДВАЖДЫ! После этого хелпер squid_ldap_group кэширует данные на время из параметра ttl. И, если повторно обратиться к SQUID (закрыть-открыть браузер) – авторизация запрашивается один раз. Но, после прохождения времени ttl (ну или если перезапустить SQUID) авторизация запрашивается опять дважды.
    Что значит дважды: вводишь в окно авторизации логин/пароль, отправляешь данные, снова появляется окно авторизации – вводишь логин/пароль – все работает нормально.

    Данная проблема только на SQUID v3.1.19
    На других версиях SQUID – ветки v2.х – данной проблемы нет

    Если я убираю проверку на принадлежность пользователя к группе – все встает на свои места и авторизация запрашивается один раз.

    auth_param basic program /usr/lib/squid3/squid_ldap_auth -R -D пользователь_в_AD@мой.домен -W /etc/squid3/password -b "dc=мой,dc=домен" -f "sAMAccountName=%s" 192.168.x.x
    auth_param basic children 10
    auth_param basic realm SQUID proxy-caching web server
    auth_param basic credentialsttl 8 hours
    auth_param basic casesensitive off

    external_acl_type ldap_users ipv4 ttl=900 children=10 %LOGIN /usr/lib/squid3/squid_ldap_group -R -b "DC=мой,DC=домен" -f "(&(objectClass=user)(sAMAccountName=%v)(memberOf=CN=%a,CN=Users,DC=мой,DC=домен))" -D пользователь_в_AD@мой.домен -W /etc/squid3/password 192.168.x.x

    acl internetaccess external ldap_users группа_в_которую_должен_входить_пользователь

    http_access allow internetaccess

    Все проверки, с использованием хелперов из консоли (командной строки) – проходят успешно. Ни каких ошибок в логах НИ ГДЕ НЕТ!

    Что это? Я что то где то упустил в версии SQUID-а 3-ей ветки?
    Баг хелпера или SQUID-а?

    Помогите, направьте на путь истинный. Все уже перерыл… %)

    • 12 июня, 2013 at 20:25
      94

      Здравствуйте.
      Покажите полностью последовательность http_access и acl.

      • Герман
        13 июня, 2013 at 10:22
        95

        Т.к. сервер только готовиться, много и не надо.

        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 internetaccess external ldap_users группа_в_которую_должен_входить_пользователь

        acl SSL_ports port 443
        acl SSL_ports port 22
        acl SSL_ports port 563
        acl SSL_ports port 873

        acl Safe_ports port 80
        acl Safe_ports port 21
        acl Safe_ports port 443
        acl Safe_ports port 70
        acl Safe_ports port 210
        acl Safe_ports port 1025-65535
        acl Safe_ports port 280
        acl Safe_ports port 488
        acl Safe_ports port 591
        acl Safe_ports port 777

        http_access allow localhost

        http_access allow internetaccess
        http_access allow internetaccess CONNECT
        http_access allow internetaccess SSH_Ports CONNECT

        http_access allow manager localhost
        http_access deny manager

        http_access deny !Safe_ports
        http_access deny CONNECT !SSL_ports

        http_access deny all

        • 18 июня, 2013 at 22:39
          96

          Попробуй так…
          http_access deny manager
          http_access deny !Safe_ports
          http_access deny CONNECT !SSL_ports
          http_access allow localhost
          http_access allow internetaccess
          # не вижу смысла в этих, после предыдущего:
          #http_access allow internetaccess CONNECT
          #http_access allow internetaccess SSH_Ports CONNECT
          http_access allow manager localhost
          http_access deny all

  39. Герман
    26 июня, 2013 at 11:09
    97

    Mc.Sim

    Попробуй так…

    Да хоть так, хоть эдак. Результат один и тот же.
    После истечения времени кэширования результатов принадлежности к группе – пароль запрашивается дважды.
    Ошибка ЯВНО при работе SQUID при обращении к модулю squid_ldap_group. Т.к. этот модуль старый, и давно не обновлялся.

  40. Евгений
    22 июля, 2013 at 12:45
    99

    Здравствуйте. В версии сквида 3.2 хэлперы squid_ldap_auth и squid_ldap_group, как я понял, заменили на basic_ldap_auth, не могу правильно написать строку обращения к хэлперу, ну и вообще понять как пишется запрос без хэлпера squid_ldap_group, в том же запросе, где и имя пользователя запрашивается или надо два запроса делать? или еще как-то. Помогите разобраться с basic_ldap_auth пожалуйста

    • 24 июля, 2013 at 10:18
      100

      Доброго времени. А что за дистрибутив? Можно увидеть список всех доступных хелперов?

      • Евгений
        24 июля, 2013 at 10:23
        101

        basic_db_auth
        basic_ncsa_auth
        basic_sasl_auth
        digest_file_auth
        helper-mux.pl
        ntlm_smb_lm_auth
        url_fake_rewrite.sh
        basic_getpwnam_auth
        basic_nis_auth
        basic_smb_auth
        digest_ldap_auth
        log_file_daemon
        basic_ldap_auth
        basic_pam_auth
        basic_smb_auth.sh
        diskd
        negotiate_kerberos_auth
        ssl_crtd
        basic_msnt_auth
        basic_pop3_auth
        cachemgr.cgi
        ext_unix_group_acl
        negotiate_kerberos_auth_test
        unlinkd
        basic_msnt_multi_domain_auth
        basic_radius_auth
        digest_edirectory_auth
        ext_wbinfo_group_acl
        ntlm_fake_auth
        url_fake_rewrite

        squid 3.2.9, Fedora linux 18

        • 24 июля, 2013 at 10:59
          102

          Вообще, я бы не советовал использовать basic метод. Ибо – небезопасно. Рекомендую воспользоваться negotiate_kerberos_auth. В целом, посмотреть ключи, используемые с хелперами можно, например указав negotiate_kerberos_auth -h или -?.

          • Евгений
            24 июля, 2013 at 12:23
            103

            а в чем опасность? для кербероса есть целый ман. А если я просто бинарник хэлпера подсуну в директорию с остальными, будет работать?

            • 24 июля, 2013 at 13:59
              104

              Опасность в том, что учетные данные (в том числе пароли передаются в открытом виде). Если бинарник подсунуть, то работать должен, хотя необходимо проверять.

  41. gsi0
    26 августа, 2013 at 15:58
    105

    А можно авторизовывать не по группам по OU?(organization unit) ?

    • 5 сентября, 2013 at 22:05
      106

      можно попробовать изменить фильтр в хелпере… но тут я не помощник )))

  42. Chubaka
    26 сентября, 2013 at 15:31
    107

    Как разрешить пасивный ftp для пользователей открывают в браузере ftp://ftp.domain.ru/ ?

  43. Chubaka
    26 сентября, 2013 at 16:10
    108


    1380195759.649 0 10.8.254.46 TCP_DENIED/407 2610 GET ftp://ftp.acnielsen.ru/ - NONE/- text/html
    1380195759.803 113 10.8.254.46 TCP_MISS/000 0 GET ftp://ftp.acnielsen.ru/ [email protected] DIRECT/194.84.162.131 -


    acl FTP proto FTP
    always_direct allow FTP

    Что не так ?

    • 26 октября, 2013 at 11:30
      109

      Зачем используете директиву always_direct? без нее пробовали? 21 порт разрешен?
      Покажите весь конфиг?

  44. Andrey
    12 ноября, 2013 at 05:50
    110

    Здравствуйте,

    Получаю в (/var/log/squid3/cache.log) вот такое предупреждение:

    WARNING: external ACL 'memberof' queue overload. Request rejected 'administrator InternetAccess'.

    основные параметры в конфиге (/etc/squid3/squid.conf):

    auth_param basic program /usr/lib/squid3/basic_ldap_auth -P -R -u cn -b "cn=Users,dc=dot,dc=lan" ubuntu.dot.lan
    auth_param basic realm ubuntu.dot.lan

    ...

    external_acl_type memberof %LOGIN /usr/lib/squid3/ext_ldap_group_acl -P -R -K -b "dc=dot,dc=lan" -f "(&(cn=%v)(memberOf=cn=%a,cn=Users,dc=dot,dc=lan))" -D [email protected] -w "Pa77w0rd" -h ubuntu.dot.lan

    ...

    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 LDAP_Auth proxy_auth REQUIRED
    acl ClientNet src 192.168.1.135
    acl Block_site url_regex -i fb vk youtube
    acl InetAccess external memberof InternetAccess

    ...

    http_access allow localhost manager
    http_access deny manager
    http_access deny !Safe_ports
    http_access deny CONNECT !SSL_ports
    http_access allow localhost
    http_access deny Block_site
    http_access allow InetAccess
    http_access deny !LDAP_Auth
    http_access allow ClientNet
    http_access deny all

    Все приведенные выше программы аутентикации и определения групп работают в тестовом режиме (консоле) без проблем. Всегда получаю ОК.

    auth_param basic program /usr/lib/squid3/basic_ldap_auth -P -R -u cn -b "cn=Users,dc=dot,dc=lan" ubuntu.dot.lan
    Administrator Pa77w0rd
    OK

    external_acl_type memberof %LOGIN /usr/lib/squid3/ext_ldap_group_acl -P -R -K -b "dc=dot,dc=lan" -f "(&(cn=%v)(memberOf=cn=%a,cn=Users,dc=dot,dc=lan))" -D [email protected] -w "Pa77w0rd" -h ubuntu.dot.lan

    Administrator InternetAccess
    ОК

    Сервер: Ubuntu Server 13.10
    Squid3: 3.3.8
    Samba4: 4.0.3

    Клиент: Windows 8 Pro

    Базисная аутентикация работает на ура, блокировка сайтов тоже.
    Проблема начинается как только добавляется правило о группе. Постоянно вупадет на клиенте окошко с логином и паролем. При вводе появляется в cache.log выше описанная строчка, и опять появляется окошко ввода данных.

    В чем проблема? И как решить?

    Благодарю.

    П.С.: Кстати, насчет безопасности если LDAPS с сертификатом то пароли будут зашифрованны, в теории. По крайней мере так делает винда. Wireshark показывает белиберду.

    • 28 ноября, 2013 at 13:17
      111

      Судя по сообщению, squid не успевает взаимодействовать с хелпером по причине переполнения очереди запросов.
      Попробуйте использовать в external acl параметр ttl=… Это заставит хранить некоторый кэш удачных запросов.

  45. Scripa4
    28 ноября, 2013 at 14:09
    112

    Доброго времени суток ). Спасибо за статью все круто, все понятно. Но я тут дошел до проверки ldap_group и появилась проблема с ошибкой: squid_ldap_group WARNING, could not bind to binddn ‘Invalid credentials’.
    Моя строка составлена следующим образом:
    /usr/lib64/squid/squid_ldap_group -R -d -b “dc=op,dc=od,dc=ua” -f “(&(objectclass=user)(sAMAccountName=%v)(memberOf=cn=%a,ou=groups,ou=linux,dc=op,dc=od,dc=ua))” -D [email protected] -w “passwd” -K 192.168.*.*
    Буду очень благодарен за помощь ).

    • 2 декабря, 2013 at 15:24
      113

      Доброго времени.
      У Вас где-то ошибка в составлении команды. Имя пользователя или пароль не принимает LDAP сервер .

  46. Andrey
    2 декабря, 2013 at 15:27
    114

    squid_ldap_group

    не любит специальные знаки в пароле… Используйте пароль такого типа:
    PaSSw0rd

    Далее, это «» точно ошибка, эти кавычки “” правильные.

    • 2 декабря, 2013 at 15:36
      115

      Andrey, спасибо за дополнение. Важная информация.
      У Scripa4 пароль самый простой passwd (если это действительно он)) )
      А ковычки вордпресс правит, так что на них не стоит ориентироваться.

  47. andrew_s
    6 декабря, 2013 at 05:37
    116

    Доброго времени суток! Спасибо за статью.
    Я сделал разделение по группам Active Directory в точности так как описано в Вашей статье. Группы для доступа squid sqiuid-list и squid точно такие же как в Вашей статье
    DC Name = ubuntserver.kmk.lan
    DC IP =192.168.0.12
    Проверка squid_ldap_group проходит успешно строка для squid_ldap_group выглядит так;
    root@ubuntuserver:~# /usr/lib/squid3/squid_ldap_group -R -d -b “dc=kmk,dc=lan” -f “(&(objectclass=user)(sAMAccountName=%v)(memberOf=cn=%a,ou=groups,ou=UNIXs,ou=groups,dc=kmk,dc=lan))” -D [email protected] -w “1” 192.168.0.12
    Вот результат ее действия:
    student squid-list
    Connected OK
    group filter ‘(&(objectclass=user)(sAMAccountName=student)(memberOf=cn=squid-list,ou=groups,ou=UNIXs,ou=groups,dc=kmk,dc=lan))’, searchbase ‘dc=kmk,dc=lan’
    OK
    Однако если применить squid.conf , указанный в Вашей статье (ниже фразы «Если данную схему наложить на наш домен и нашу задачу, то получится следующий конфиг:»)
    то получаем сообщение об ошибке доступа в access.log
    0 192.168.0.142 TCP_DENIED/407 4055 GET http://go.microsoft.com/fwlink/? – NONE/- text/html
    1386292596.105 0 192.168.0.142 TCP_DENIED/407 4158 GET http://go.microsoft.com/fwlink/? – NONE/- text/html
    1386292612.093 0 192.168.0.142 TCP_DENIED/407 4158 GET http://go.microsoft.com/fwlink/? – NONE/- text/html
    1386292613.668 0 192.168.0.142 TCP_DENIED/407 4158 GET http://go.microsoft.com/fwlink/? – NONE/- text/html
    1386292616.069 0 192.168.0.142 TCP_DENIED/407 4158 GET http://go.microsoft.com/fwlink/? – NONE/- text/htm
    А в /var/log/squid3/cache.log видим
    squid_kerb_auth: DEBUG: AF oYGfMIGcoAMKAQChCwYJKoZIhvcSAQICooGHBIGEYIGBBgkqhkiG9xIBAgICAG9yMHCgAwIBBaEDAgEPomQwYqADAgEXolsEWcdnz2her+NZMNLRnQtZJ+rXDBlv1KO5kgqL/9xKk4E6uuXUqRqOQjeWMmAmqvjmUNvZ/nv61G2E9hpolA73KA9Yev2LAeLDacVPlcVEZ+sDksyUtxjaXA6I [email protected]
    Connected OK
    group filter ‘(&(objectclass=user)(sAMAccountName=Administrator)(memberOf=cn=squid,ou=groups,ou=UNIXs,ou=groups,dc=kmk,dc=lan))’, searchbase ‘dc=kmk,dc=lan’
    Connected OK
    group filter ‘(&(objectclass=user)(sAMAccountName=Administrator)(memberOf=cn=squid-list,ou=groups,ou=UNIXs,ou=groups,dc=kmk,dc=lan))’, searchbase ‘dc=kmk,dc=lan’
    Если в squid.conf добавить строки
    acl localnet src 192.168.0.0/24
    acl to_localnet dst 192.168.0.0/24
    http_access allow localnet
    То доступ через squid идет для всей локальной сети однако разделения по группам доступа не происходит т.е. пользователям группы squid-list доступны ВСЕ сайты а не только указанные в /etc/squid3/acls/whitelist.acl
    Собственно вопрос: Как сделать разделение по группам доступа?Что для этого нужно поправть в squid.conf ,подскажите пожалуйста ?
    Ниже привожу свой squid.conf ,который в аналогичен вашему за исключением доменных имен и т.п.
    root@ubuntuserver:~# cat /etc/squid3/squid.conf
    auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -d -s HTTP/[email protected]
    auth_param negotiate children 15
    auth_param negotiate keep_alive on
    external_acl_type ldap_verify %LOGIN /usr/lib/squid3/squid_ldap_group -R \
    -d -b “dc=kmk,dc=lan” -f”(&(objectclass=user)(sAMAccountName=%v)(memberOf=cn=%a,ou=groups,ou=UNIXs,ou=groups,dc=kmk,dc=lan))” -D [email protected] -K -W /etc/squid3/aduser ubuntuserver.kmk.lan.
    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 192.168.0.0/24
    acl to_localnet dst 192.168.0.0/24
    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 localnet
    ttp_access allow manager localhost
    http_access allow localhost
    http_access allow users
    http_access allow users-list whitelist
    http_access deny manager
    http_access deny !Safe_ports
    http_access deny CONNECT !SSL_ports
    http_access deny !allusers all
    http_access deny all
    http_port 192.168.0.12:3128
    http_port 127.0.0.1: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

    • 6 декабря, 2013 at 14:12
      117

      Доброго времени, andrew_s.
      Не стоит бездумно копировать конфиг. Необходимо понимать технологию работы.
      В начале данной статьи я дал рекомендации о предварительном прочтении статей “Для того, чтобы у вас заработала данная схема, необходимо ознакомиться со статьями <...> Без данных статей и понимания принципов работы squid – никак”.
      В данных статьях описано, как работает директива http_access и в общем как предоставляется доступ. После прочтения, вы сможете самостоятельно подправить свой конфиг.

  48. Aldemio
    13 января, 2014 at 08:07
    118

    Добрый день! У меня вопрос такой: возможно ли получая имя пользователя через Kerberos, использовать непосредственно для самой аутентификации собственный внешний скрипт-хелпер (а не squid_ldap_group)? У меня данный скрипт идентифицирует пользователей через таблички БД, поэтому переводить систему на аутентификацию LDAP не представляется возможным. Параметр %LOGIN нужен скрипту для получение данных из БД.

  49. aliennick
    6 мая, 2014 at 09:53
    120

    здравствуйте. помогите пожалуйста. не могу сделать запрос к АД для squid_ldap_group. прочитал тут все комменты… перепробовал уже все варианты… поднял на центосе 64-битном сквид и в ответ на squid_ldap_auth получаю ERR просто. а в ответ на squid_ldap_group – invalid request. ERR

    причем ldapsearch -D “[email protected]” -w “proxypassword” -x -b “dc=DOM,dc=local” -h 10.0.0.1 – успешно выводит всю инфу с АД, так же как и ldapsearch -u -D “cn=squid,cn=Users,dc=dom,dc=local” -w “proxypassword” -x -b “cn=Users,dc=DOM,dc=local” -h 10.0.0.1

    вот структура нашего АД
    http://hkar.ru/slt7

    очень прошу, несколько дней с этим бьюсь уже….

    • 24 июня, 2014 at 20:15
      121

      Покажите, как вы вводите команду squid_ldap_auth и squid_ldap_group? Желательно скопировать консольный вывод в какой-нибудь pastebin.com

  50. aliennick
    6 мая, 2014 at 10:02
    122

    еще забыл добавить что у нас используется Windows 2008 R2 в качестве контроллера домена. спасибо…

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

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