SQUID аутентификация (Kerberos и LDAP) на основе доменных групп Active Directory
Приветствую, гости и читатели моего блога о Linux. Продолжаем расширять возможности squid. Сегодня попытаемся реализовать авторизацию доменных учеток Active Directory на основе их членства в группах. В статье будет задействовано новая для меня технология, в которой я пока не очень соображаю – LDAP. Поэтому о ней пока будет рассказано “вскользь”. Для того, чтобы у вас заработала данная схема, необходимо ознакомиться со статьями:
- Прокси-сервер SQUID, вводный пост
- Аутентификация и авторизация пользователей squid
- squid, настройка ограничений скорости (delay pools)
Без данных статей и понимания принципов работы squid – никак 
Что такое LDAP в Active Directory (Введение)
Т.к. LDAP пока для меня – это маленькая тайна. Расскажу, что знаю… Итак, LDAP – это некий каталог (дословно – lightweight directory access protocol, в переводе – облегчённый протокол доступа к каталогам), который хранит в себе различную информацию в древовидной форме и имеет структуру, на нашем примере (на примере домена AD.LOCAL): 
Давайте разберем что к чему… В голове структуры – имя домена (AD.LOCAL), “в подчинении” у домена – отделы (т.н. организационные единицы), у каждого отдела могут быть в подчинении другие отделы. Кроме того, в любой отдел (в том числе и в корневой контейнер – домен) могут входить некие элементы – группы, пользователи, принтеры и др., которые “в себе” могут хранить некоторые настройки – атрибуты объекта (например, у пользователя – пароль, имя, адрес почты и др.).
У каждой записи в LDAP, будь то объект или контейнер с объектами внутри имеется уникальное для всего каталога LDAP имя (т.н. англ. Distinguished Name (DN) – Отличительное имя). Это даже не имя, а путь, характеризующий полный путь к этом этой записи во всей иерархии. Уникальный путь может выглядеть (на примере группы squid), следующим образом: «cn=squid, ou=groups, ou=UNIXs, dc=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 [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 для использования групп
По умолчанию, в 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 новых 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
При реализации данной схемы я столкнулся с некоторыми нюансами, которые не стоит оставлять без внимания:
- если пользователь входит в несколько групп, которым предоставлен доступ в интернет в конфигурационном файле squid, то он (пользователь) будет иметь то разрешение, которое первым совпадет с правилом http_access. То есть если некоторый авторизованный пользователь pupkin входит и в группу squid и в группу squid-list, то при том конфиге, что показан выше, он получит доступ согласно группе squid, потому что правило http_access allow users расположено первым.
В каждом из OU (Склады, Кадры, Юристы и другие подразделения того же уровня) имеют в подчинении свои группы, включающие в себя подчиненные им же (подразделениям) пользователей. То есть подразделение Закупки имеет подчиненный объект Закупки, который является группой включающей в себя всех пользователей подразделения, и если эту группу включить в группу с именем squid (то есть группу Закупки сделать членом группы squid), то пользователи из группы Закупки не получат доступ к интернету, пока этих пользователей индивидуально не включишь в группу squid.- После добавления пользователя в группу работа пользователя начинается через некоторое время, а точнее через время, которое равно значению по-умолчанию в параметре 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!
Другие материалы в категории Настройка сервера Linux
- SQUID настройка ACL и http_access
- squid, использование опции debug_options или диагностика компонентов squid
- Использование ramdisk в Linux (ramdisk, ramfs, tmpfs) или препарирование рамдисков
- Rsyslog на Debian, настройка сервера сбора логов
- HOWTO SAMBA на 2 интерфейса и 2 сети с разными smb.conf
- SQUID аутентификация (Kerberos и LDAP) на основе доменных групп Active Directory
- squid, настройка delay pools
- Аутентификация и авторизация squid (basic, Digest, NTLM, negotiate)
- Прокси-сервер SQUID, вводный пост
- SSH сервер на Debian
Огромное спасибо за ваши статьи! С помощью них настроил прокси с 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 хелпера. Похоже группы гости домена ему достаточно, я именно так и сделал и пока что проблем не было.
Еще раз спасибо за материал – все очень хорошо и понятно расписано!
Отличное дополнение, спасибо.
опишу сразу версии ПО
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== [email protected]
Connected OK
group filter ‘(&(objectClass=user)([email protected])(memberOf=cn=level1,ou=proxy,dc=rm,dc=local))’, searchbase ‘dc=rm,dc=local’
то есть на вход %LOGIN приходит [email protected]
какие могут быть советы кроме как всю обработку делать в отдельном скрипте
Почему Вы поставили версию 2.6?
Большое спасибо за статью!
Долго я бился с параметрами хелпера squid_ldap_group, вроде сам разобрался и нарвался на эту статью, где все разжевано и разложено по полочкам. Уверенности в правильности своих действий добавилось. Как говорится: опыт – это такая штука, которая появляется сразу после того, как была нужна.
Одно замечание: В каждом из OU (Склады, Кадры, Юристы и другие подразделения того же уровня) имеют в подчинении свои группы, включающие в себя подчиненные им же (подразделениям) пользователей. То есть подразделение Закупки имеет подчиненный объект Закуп2, который является группой включающей в себя всех пользователей подразделения, и если эту группу включить в группу с именем squid (то есть группу Закуп2 сделать членом группы squid), то пользователи из группы Закуп2 не получат доступ к интернету, пока этих пользователей индивидуально не включишь в группу squid. В группу squid надо включить группу Закупки для получения доступа к интернету. (Правильно я понял?).
Вот это замечание прошу прокомментировать, просто из-за совпадения имен групп трудно понять о какой группе идет речь.
Спасибо за комментарий )
Улыбнуло )))
По сабжу… На сколько мне понятно, глубину и параметры поиска задает фильтр,который указан после ключа -f. Тут необходимо более глубокое понимание работы LDAP, погрузиться в который мне пока не довелось. Поэтому какой-либо компетентный ответ на данный вопрос я скорей всего не дам (
Здравствуйте, спасибо за блог, в последнее время очень часто сюда наведываюсь.
Настроил все по статье, все работает замечательно.
Но появилась потребность получать интернет для компьютеров которые не входят в домен. Единственное что у меня получается, так это использовать squid_kerb_auth вместе с ncsa_auth, но тогда не работает ldap, и для недоменных писи просит ввода логин/пароль по 3-4 раза к ряду.
Возможно ли к реализации описанной в вашей статье прикрутить еще авторизацию вне домена через AD? (т.е. на недоменном писи надо будет ввести логин-пароль пользователя из группы squid-list например )
Вариант с двумя сквид процессами откладываю на саамый черный день )
и вот конфиг
http://pastebin.com/5kzCzCX8
Попробуйте разместить правила вот в таком порядке:
http_access deny !Safe_portshttp_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
Спасибо, действительно так авторизация работает и для доменных машин и для тех кто не в домене.
Как ни странно, таким методом аутентифицироваться не захотели скайп и торренты.. хотя на форумах у кого-то получалось используя squid + samba+winbind. Если кто будет искать решение, то я обошел эту проблему создав второй процесс squida слушающего другой порт и без аутентификации вообще, при этом открыл ему только самые нужные порты – хватает чтобы работали скайп и торренты, но не хватает чтобы посерфить по сайтам)
Спасибо за информацию. Рад, что все получилось…
А есть ли для данного случая какое-нибудь решение для подсчета и ограничения трафика юзеров, и записи логов кто куда лазил. Как я вижу на большинство вариантов – тот же SAMS например, опять-таки требуется samba..
lightsquid умеет считать трафик, а по поводу ограничения скорости, почитайте статью о delay pools.
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
Зарнее спасибо.
Доброго времени.
Не понял вашего вопроса.
Статья ведь итак описывает эту конфигурацию.
Зачем вы применяете хелпер /usr/lib/squid/ldap_auth, если в статье используется
auth_param negotiate program /usr/lib/squid3/squid_kerb_auth
Прошу прощения если достаю, вопрос по поводу керберос и таких программ как ICQ SKYPE и прочее. Они же работают на стандартном 443 порту, но при этом в логе пишется что к примеру ICQ логин не передает. Как Вы настраивали ?
Все эти программы в большинстве случаев имеют настройку “автоматически настраивать прокси”, либо “брать настройки из браузера”, либо “использовать учетные данные windows”. Я пока не испытывал проблем с этим. Пишите, если не получится.
Добрый день! Долгое время squid был настроен на ntlm+basic аутентификации. Настроил kerberos. И как раз возникла проблема со skype. В браузере все отлично, в icqшном клиенте раньше прописывали все данные для аутентфикации теперь, ставим – автоматом. А вот скайп ни в какую не хочет через прокси идти. Смотрел tcp view – ломится напрямую на десяток неведомых ip, половина из которых не резолвится даже. Что можно предпринять, есть какие-то решения?
Это очень странная проблема. Обычно, у администраторов противоположные сложности – как запретить доступ скайпу )
То, что он подключается (пытается) на внешние IP – это нормально. Ищет доступ к своим серверам.
А вот то, что он не подключается, когда в браузере есть интернет – это очень странно.
Здравствуйте! У меня ситуация немного схожая с 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 просто переходил к обработке следующих правил?
Судя по Вашему конфигу, вы не последовали моей рекомендации, которую я дал Kaign. Попробуйте привести http_access к предложенному виду.
Что конкретно не соответствует вашим рекомендациям?
В статье об acl я постарался описать ключевые принципы размещения последовательности http_access.
Кроме того, могу сказать, что многом помогает вот такая компбинация, размещенная в конце правил:
http_access deny !auth allhttp_access deny all
Так же, рекомендую разместить “быстрые” разрешающие правила http_access, выше медленных, особенно которые используют аутентификацию.
Подскажите пожалуйста в чем может быть проблема консоль – _ttp://clip2net.com/s/3hStwn4 Пользователи и компьютеры в AD – _ttp://clip2net.com/s/3hSu9tT
Пользователь auser1 пренадлежит группе access
Ссылки не работают.
Есть вопрос ко всем знатокам..Как объединить AD и Skype для дальнейшей прикрутки к outlook?
Я думаю, что Skype for Business Server вам поможет.
Добрый день. Пытался настроить 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/[email protected]
# сколько параллельных потоков запускать для обслуживания аутентификации клиентов
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
Еще актуален вопрос?
Есть пару рекомендаций и вопросов, прежде чем можно будет дато окончательный ответ.
Рекомендую разместить ACL и директорию http_access в отдельных блоках, чтобы был порядок и читабельность. (статья по теме https://www.k-max.name/linux/squid-acl-and-http_access/)
Из Вашего конфига я вижу, что используется хелпер negotiate_wrapper_auth. Чем вызвано использование данного хелпера?
Спасибо за статью.
Всё получилось, работает.
Одного никак не пойму: каким образом можно обновлять правила групп и блеклистов для них? К примеру, пользователь был в админах с доступом везде, но провинился и попал в обычные пользователи. Или наоборот. Как в таких случаях обновлять правила доступа для него? При текущей настройке правила не обновляются – ему либо так же всё разрешено, либо после смены группы обычных пользователей на админскую, действуют всё те же запрещающие правила.
Перелогиниться пробовал, разумеется, сквид перезапускал.
Спасибо.
Я думаю, что за это ответственный файл krb5.conf, в котором можно задать соответствующие параметры таймаутов. Можно еще посмотреть в ключи для squid_kerb_auth, но я не смог найти мана (
Спасибо за мануал. Сделал всё тоже самое, но с хелпером 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 указан только потому, что у нас в сети несколько доменов.
Спасибо за пример.
Интересный хелпер )
Приветствую. Надеюсь автор еще читает комментарии в своих старых статьях.
У меня вопрос следующего характера.
Есть группа в АД, есть групповой ACL в SquidGuard с нарезанными разрешениями.
И тут оказывается есть один пользователь в этой группе АД, которому необходим доступ к одному сайту, который в групповом ACL заблокирован. Можно ли как то нарезать ему прав одному, не создавая отдельно группы в АД и отдельно ACL?
Есть ли какое то более изящное решение ?
Добрый день.
Этого юзера нужно поместить в отдельный разрешающий ACL выше того, который запрещает доступ для группы.
Добрый день.
Есть настроенный squid на centos
auth_param negotiate program /usr/lib64/squid/negotiate_kerberos_auth -i -d -k /etc/squid/krb5.keytab -s HTTP/proxy.***.*****.ru@***.*****.RU
auth_param negotiate children 10
auth_param negotiate keep_alive on
auth_param basic program /usr/lib64/squid/basic_ldap_auth -d -b “cn=users,cn=accounts,dc=***,dc=*****,dc=ru” -D “uid=admin,cn=users,cn=accounts,dc=***,dc=*****,dc=ru” -W /etc/squid/ldap_password -f “(&(objectClass=person)(uid=%s))” -H ldap://ipa.***.*****.ru:389
acl auth proxy_auth REQUIRED
acl ldap-auth proxy_auth REQUIRED
#http_access allow localnet
#http_access allow localhost
http_access allow ldap-auth
http_access allow auth
http_access deny all
Остальное по умолчанию.
Также 4 машины две на linux (одна в домене, другая нет) и две на windows (также одна в домене, другая нет). Для linux машины, которая не в домене проходит basic аутентификация. Для машин linux windows, которые в домене проходит kerberos аутентификация. Для windows машины не домене не проходит basic аутентификация. Есть ли возможность заставить windows машину, находящуюся не в домене, пройти basic аутентификацию. Если закомментировать строки с kerberos аутентификацией, windows машина не домене успешно проходит basic аутентификацию.
Заранее спасибо.