Какие схемы аутентификации используются в squid

Схемы авторизации в squid

Здравствуйте, имею следующий вопрос о том, как лучше организовать авторизацию пользователей в squid. Сейчас авторизация идет через basic хелпер ncsa. Возникла необходимость разбить пользователей на группы и раздавать инет согласно группам. Если сделать примерно так:

#Autentification
auth_param basic program /usr/squid/libexec/ncsa_auth /usr/squid/etc/passwd
auth_param basic children 15
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off

acl user_url dstdomain .domain1.com
acl sec_url dstdomain .domain2.com

acl group_admins proxy_auth user1 user4 REQUIRED
acl group_users proxy_auth user2 REQUIRED
acl group_sec proxy_auth user3 REQUIRED

#HTTP Access
http_access allow manager localhost
http_access deny manager

http_access allow group_admins
http_access allow group_users user_url
http_access allow group_sec sec_url

Имхо тут плохо то, что proxy_auth здесь больше одного раза и squid будет терзать хелпер до появления первого OK — хотелось бы узнать, а вообше можно ли так делать, когда proxy_auth упоминается больше 1-го раза — не повлияет ли это на стабильность и т.д. Еще при использовании такой схемы был замечен глюк в IE7 -при попытке зайти куда либо спрашивает пароль 3 раза, потом пускает, возможно тоже из-за 3 proxy_auth, хотя в FF такого не замечено.
Или же есть еще 1 схема:

acl mydomain_site dstdomain .mydomain.ru
external_acl_type unix_group %LOGIN /usr/squid/libexec/check_group
acl auth proxy_auth REQUIRED
acl inet_full external unix_group inet-full
acl inet external unix_group inet

http_access allow auth mydomain_site
http_access allow inet_full
http_access allow inet user_url

Тут уже proxy_auth один раз, но неудобство в том, что приходись заводить пользователей дважды — в /etc/passwd и в passwd squid’а. И с этой схемой глюков с IE не замечено. В общем, хотелось бы выяснить, какая схема лучше. Сам склоняюсь к первой, т.к. проще пользователей заводить.

Linux.yaroslavl.ru

Замечание: Представленая здесь информация верна для версии 2.4.

Пользователи будут аутентифицироваться, если squid настроен на использование ACL типа proxy_auth (см. след. вопрос).

Броузер посылает пользовательский запрос на аутентификацию в загловке Authorization .

Если Squid получает запрос и если список правил http_access содержит ACL типа proxy_auth , Squid ищет загловок Authorization . Если заголовок присутствует, Squid декодирует его и извлекает имя пользователя и пароль.

Если заголовок отсутствует, Squid возвращает HTTP-ответ со статусом 407 (Proxy Authentication Required). Пользовательский агент (броузер) получает ответ 407 и просит пользователя ввести имя и пароль. Имя и пароль кодируется и посылается в заголовке Authorization для последующих запросов к прокси.

ЗАМЕЧАНИЕ : Имя и пароль кодируются с использованием «base64» (см. раздел 11.1 RFC 2616). Однако base64 это только кодирование binary-to-text, при кодировании информация НЕ шифруется. Это означает, что имя пользователя и пароль фактически передаются «открытым текстом» между броузером и прокси. Поэтому вы не должны использовать тот же пароль и имя пользователя, который вы используете для вашего аккаунта.

Аутентификация фактически происходит вне основного процесса Squid. Когда Squid стартует, он запускаеть несколько процессов аутентификации. Эти процессы читают имена пользователей и пароли со стандартного ввода и выдают «OK» или «ERR» на стандартный вывод. Подобная техника позволяет вам использовать большое количество различных схем аутентификации, однако вы можете использовать только одну схему в данный момент времени.

• LDAP: использует Lightweight Directory Access Protocol
• NCSA: использует NCSA-стиль для файла имен пользователей и паролей.
• MSNT: использует Windows NT authentication domain.
• PAM: использует Linux Pluggable Authentication Modules scheme.
• SMB: использует SMB-север типа Windows NT или Samba.
• getpwam: использует старомодный файл паролей old-fashioned Unix.

Для аутентификации пользователей вам необходимо собрать и установить один из предлагаемых модулей аутентификации, установить другой, или свой собственный.

Вы указываете Squid, какую программу аутентификации использовать при помощи опции authenticate_program в squid.conf. Вы указываете имя программы плюс опции командной строки если необходимо.К примеру:

authenticate_program /usr/local/squid/bin/ncsa_auth /usr/local/squid/etc/passwd

Убедитесь что ваша программа аутентификации установлена и работает правильно. Вы можете протестировать ее вручную.

Добавьте несколько proxy_auth ACL в ваш конфигурационный файл. К примеру:

acl foo proxy_auth REQUIRED acl all src 0/0 http_access allow foo http_access deny all

Термин REQURIED означает, что любой аутенентифицированый пользователь попадет в ACL по имени foo .

Squid предоставляет вам хорошо структурированый контроль, определяемый индивидуальными именами пользователей. К примеру:

acl foo proxy_auth REQUIRED acl bar proxy_auth lisa sarah frank joe acl daytime time 08:00-17:00 acl all src 0/0 http_access allow bar http_access allow foo daytime http_access deny all

В этом примере пользователям lisa, sarah, joe, и frank разрешено использовать прокси в любое время. Другим пользователям разрешен доступ только в дневное время.

Да. Успешные запросы аутентификации кешируются на один час по умолчанию. Это значит (в худшем случае), что есть возможность для кого-нибудь использовать ваш кеш в течении часа после того, как он был удален из базы аутентификации.

Вы можете контролировать время истечения срока действия пароля при помощи опции authenticate_ttl .

Squid размещает пароли открытым текстом в памяти кеша.

Squid передает открытым текстом имя пользователя и пароль, когда общается с внешним процессом аутентификации. Заметьте однако, что эти межпроцессовые взаимодействия происходят по TCP-соединениям, привязанным к loopback-интерфейсу. Посему не представляется возможным процессам с других компьюретов «выследить» трафик аутентификации.

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

Winbind — новое дополнение к Samba, предоставляющее некоторые потрясающие возможности для бюджетов пользователей на основе NT. Для Squid winbind представляет собой правильное и эффективное решение и для basic и для NTLM challenge/response аутентификации в противопоставление контролеру домена NT.

Требуется Samba версии 2.2.4 или выше. Samba 2.2.4, 2.2.5 и 3.0a17 умеют работать с аутентификатором winbind в Squid 2.5.

Аутентификация через winbind успешно работает под Linux, FreeBSD и Solaris.

Настройка Samba

Samba долбжна быть собрана с такими опциями в configure:

--with-winbind --with-winbind-auth-challenge (needed for ntlm)

Опционально, для сборки Samba 2.2.5 можно наложить патч smbpasswd.diff См. ниже SMBD and Machine Trust Accounts, чтобы определить нужен ли вам этот патч.

Отредактируйте ваш smb.conf, чтобы winbindd заработал. Как шаблон для секции [global] файла smbd.conf можно использовать нижеследующее.

workgroup = mydomain password server = myPDC security = domain winbind uid = 10000-20000 winbind gid = 10000-20000 winbind use default domain = yes

• Запустите nmbd (требуется, чтобы убедится, что все верно работает).
• Запустите winbindd.
• Проверьте общую функциональность winbindd при помощи «wbinfo -t»:

# wbinfo -t Secret is good

# wbinfo -a mydomain\\myuser%mypasswd plaintext password authentication succeeded error code was NT_STATUS_OK (0x0) challenge/response password authentication succeeded error code was NT_STATUS_OK (0x0)

SMBD и Machine Trust Accounts

Демон smbd, не больно нужный для winbindd, может понадобиться для управления доверительным аккаунтом машины.

Нормальные члены домена регулярно меняют пароль аккаунта. Windows и Samba сервера по умолчанию меняют этот пароль каждые семь дней.

Компонентом Samba отвечающим за управление паролем доверительного аккаунта является smbd. Smbd необходим, чтобы получать запросы, вызывающие смену пароля. Если машина будет использоваться как файл- или принт-сервер, то запущенный для обслуживания обычных запросов smbd должен все нормально поддерживать.

Однако в случае, когда хелпер winbind Сквида единственный из запущенных компонент Samba, smbd может простаивать. Действительно, может не быть других причин запускать smbd вообще.

Есть две простые возможности изменить доверительный аккаунт. Обе могут реализовываться посредством ежедневной смены доверительного пароля при помощи cron.

UglySolution.pl — это простой скрипт на perl, чтобы загрузить smbd, подсоедениться к расшаренному ресурсу Samba с использованием smbclient и сгенирировать достаточно фальшивой активности, чтобы вызвать смену доверительного пароля машины smbd.

smbpasswd.diff — это патч для утилиты smbpasswd от Samba 2.2.5, позволяющий изменять пароль аккаунта машины. Этот минимальный патч, просто реализующий в интерфейсе командной строки уже существующую функцию Samba.

После накладки патча, синтаксис смены пароля smbpasswd выглядит так:

smbpasswd -t DOMAIN -r PDC

В Samba версии 3.x все намного проще. Smbd больше не нужен, чтобы управлять машиной с доверительным аккаунтом, никаких утилит больше патчить тоже не нужно.

Команда Samba team реализовала возможность смены пароля машины с доверительным аккаунтом при помощи новой команды «net». Все что нужно — ежедневное выполнение «net rpc changetrustpw» при помощи cron.

Настройка Squid

Squid должен быть собран с такими опциями в configure:

--enable-auth="ntlm,basic" --enable-basic-auth-helpers="winbind" --enable-ntlm-auth-helpers="winbind"

Тестирование Squid без аутентификации

Прежде чем продолжать, проверьте общую функциональность Squid. Убедитесь, что squid работает без авторизации.

Тестирование winbind ntlm helper невозможно из командной строки, но winbind basic-аутентификатор может быть протестирован как и любой другой basic helper:

# /usr/local/squid/libexec/wb_auth -d /wb_auth[65180](wb_basic_auth.c:136): basic winbindd auth helper . mydomain\myuser mypasswd /wb_auth[65180](wb_basic_auth.c:107): Got 'mydomain\myuser mypasswd' from squid (length: 24). /wb_auth[65180](wb_basic_auth.c:54): winbindd result: 0 /wb_auth[65180](wb_basic_auth.c:57): sending 'OK' to squid OK

Хелпер должен вернуть «OK», если получил верные имя_пользователя/пароль.

Установите аутентификаторы. Добавьте нижеследующее, чтобы включить и winbind basic и ntlm аутентификаторы. IE будет использовать ntlm и остальные basic:

auth_param ntlm program /usr/local/squid/libexec/wb_ntlmauth auth_param ntlm children 5 auth_param ntlm max_challenge_reuses 0 auth_param ntlm max_challenge_lifetime 2 minutes auth_param basic program /usr/local/squid/libexec/wb_auth auth_param basic children 5 auth_param basic realm Squid proxy-caching web server auth_param basic credentialsttl 2 hours

acl AuthorizedUsers proxy_auth REQUIRED .. http_access allow all AuthorizedUsers

Тестирование Squid с аутентификацией

1. Internet Explorer: Проверьте работу через squid с использованием IE. Если вы вошли в домен, запрос пароля не должен появится. Убедитесь, что запросы действительно авторизуются, заглянув в access.log. Имя пользователя/домен должны в нем присутствовать.
2. Netscape, mozilla, opera. Проверьте работу с другими броузерами. Стандартный диалог запроса пароля должен появиться. Вход в домен не требуется, если пользователь в домене по умолчанию и установлено «winbind use default domain = yes» в smb.conf. В противном случае имя пользователя должно быть введено в формате «domain\username».

Если в access.log нет имени пользователя и/или не происходи запрос пароля в броузере, то установки acl/http_access в squid.conf неверны.

Какие схемы аутентификации используются в squid

Инструкция используется, если программа Kaspersky Web Traffic Security установлена из rpm- или deb-пакета на готовую операционную систему.

Если вы настраиваете аутентификацию с доменом, в названии которого содержится корневой домен .local , то для корректной работы Kerberos-аутентификации требуется выполнить предварительные действия в операционной системе.

1. Проверьте состояние службы avahi-daemon. Для этого выполните команду: systemctl status avahi-daemon
2. Если служба запущена, остановите ее. Для этого выполните команду: systemctl stop avahi-daemon
3. Отключите автоматический запуск службы. Для этого выполните команду: systemctl disable avahi-daemon

Чтобы настроить сервис Squid для Kerberos-аутентификации, выполните следующие действия:

1. Если вы используете операционные системы CentOS версии 8.x или Red Hat Enterprise Linux версии 8.x, настройте политику использования криптографичеких алгоритмов. Для этого выполните команду: update-crypto-policies —set LEGACY
2. Скопируйте файл squid.keytab в директорию /etc/squid/.
3. Настройте доступ к keytab-файлу. Для этого выполните следующие команды в зависимости от используемой операционной системы:
   • CentOS, Red Hat Enterprise Linux или SUSE Linux Enterprise Server: chown squid:squid /etc/squid/squid.keytab chmod 400 /etc/squid/squid.keytab
   • Ubuntu, Debian или Альт Сервер: chown proxy:proxy /etc/squid/squid.keytab chmod 400 /etc/squid/squid.keytab

По умолчанию владельцем файла krb5.keytab является суперпользователь.

• CentOS или Red Hat Enterprise Linux: auth_param negotiate program /usr/lib64/squid/negotiate_kerberos_auth -k /etc/squid/squid.keytab -s HTTP/@ auth_param negotiate children 100 startup=0 idle=10 auth_param negotiate keep_alive on acl authenticated_user proxy_auth REQUIRED http_access deny !authenticated_user
• SUSE Linux Enterprise Server: auth_param negotiate program /usr/sbin/negotiate_kerberos_auth -k /etc/squid/squid.keytab -s HTTP/@ auth_param negotiate children 100 startup=0 idle=10 auth_param negotiate keep_alive on acl authenticated_user proxy_auth REQUIRED http_access deny !authenticated_user
• Ubuntu, Debian или Альт Сервер: auth_param negotiate program /usr/lib/squid/negotiate_kerberos_auth -k /etc/squid/squid.keytab -s HTTP/@ auth_param negotiate children 100 startup=0 idle=10 auth_param negotiate keep_alive on acl authenticated_user proxy_auth REQUIRED http_access deny !authenticated_user

• CentOS или Red Hat Enterprise Linux: auth_param negotiate program /usr/lib64/squid/negotiate_kerberos_auth -d -k /etc/squid/squid.keytab -s HTTP/@
• SUSE Linux Enterprise Server: auth_param negotiate program /usr/sbin/negotiate_kerberos_auth -d -k /etc/squid/squid.keytab -s HTTP/@
• Ubuntu, Debian или Альт Сервер: auth_param negotiate program /usr/lib/squid/negotiate_kerberos_auth -d -k /etc/squid/squid.keytab -s HTTP/@

Отладочные события будут записаны в файл /var/log/squid/cache.log.

• Для CentOS или Red Hat Enterprise Linux добавьте в файл /etc/sysconfig/squid строку: KRB5RCACHETYPE=none
• Для Ubuntu версии 18.04.х, Debian версии 9.х или Альт Сервер добавьте в файл /etc/default/squid строку: KRB5RCACHETYPE=none
• Для SUSE Linux Enterprise Server версии 15.х или Debian версии 10.х:
  1. Создайте файл /etc/systemd/system/squid.service.d/override.conf следующего содержания: [Service] Environment=KRB5RCACHETYPE=none
  2. Выполните команду: systemctl daemon-reload

По умолчанию Replay cache включен.

Replay cache обеспечивает более надежную защиту, но может снижать производительность программы.

Кеш, используемый в технологии Kerberos для хранения записей о запросах пользователей на аутентификацию. Этот механизм помогает защитить инфраструктуру от атак повторного воспроизведения. Во время таких атак злоумышленники записывают трафик пользователя, чтобы воспроизвести ранее отправленные им сообщения и успешно пройти аутентификацию на прокси-сервере. При использовании replay cache сервер аутентификации обнаруживает дубликат запроса и отправляет в ответ сообщение об ошибке.

Сервис Squid будет настроен для использования Kerberos-аутентификации.

Squid+LDAP

«Ещё одно HOWTO про squid? Их и так уже полно в Интернете!» Это правда, squid — один из самых документированных OpenSource-продуктов. Ежегодно десятки энтузиастов более или менее подробно описывают свои наработки и открытия в блогах и HOWTO-руководствах, а ведь есть ещё превосходная документация на официальном сайте, подробнейшие комментарии в конфигурационном файле squid.conf, множество man-страниц. И, тем не менее, у тех, кто принимается за настройку, остаётся ещё очень много вопросов. На наш взгляд, это связано с трудностью нахождения баланса. С одной стороны, есть готовые HOWTO-решения частных задач, которые могут сразу заработать (а могут и не заработать) в Вашем окружении. Следуя им, есть все шансы не заметить и упустить тонкие и важные детали настроек, кроме того, Вы загоняете себя в те рамки, которые были удобны авторам HOWTO, но не обязательно будут лучшим решением для Вас. С другой стороны, погружаясь в чтение подробнейшей документации, всегда есть риск «за деревьями не увидеть леса», то есть упустить важные общие направления, погрязнув в деталях. Для обретения баланса, как всегда, требуется найти «золотую середину»: чётко осознавать ту задачу, которая перед Вами стоит, возможности того окружения, в котором Вы будете эту задачу решать, и, конечно же, возможности самого инструмента, который у Вас в руках.

Не пытаясь объять необъятное, в этом руководстве, — надеемся, это всё-таки не будет HOWTO-руководством, — мы постараемся рассмотреть отдельный пласт задач — интеграция сервера squid с каталогом LDAP. Поверьте, здесь тоже есть с чем разобраться, начиная с классической дилеммы «какую структуру каталога выбрать?» и заканчивая сотнями мелочей, которые могут возникнуть в процессе интеграции. Итак, поехали!

1. Перед тем как начать

1.1. Squid и его хелперы

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

В терминологии squid хелпер — это интерактивная программа, на вход которой подаётся один или несколько параметров (не путайте с аргументами командной строки), обработав которые, она выдаёт принятое ей положительное или отрицательное решение в виде строки, которая начинается с OK или ERR соответственно. Две основных категории хелперов — это хелперы аутентификации и так называемые хелперы внешних ACL.

Хелперы аутентификации на основании переданных им параметров, — в простейшей Basic-аутентификации это имя пользователя и пароль, — проводят проверку подлинности пользователя. При вызове такого хелпера из squid в случае успешного прохождения аутентификации пользователем во внутреннюю переменную squid %LOGIN помещается имя этого пользователя.

Внешние же хелперы, анализируя переданные им параметры, пытаются выяснить правомерность того или иного обращения к squid. Например, в классическом варианте применения ext_ldap_group_acl (squid_ldap_group) этот хелпер, на основании переменной %LOGIN и переданного ему названия группы, пытается определить, является ли указанный в переменной пользователь членом этой группы.

Поскольку нас в первую очередь интересует интеграция squid с каталогом LDAP, то мы рассмотрим поставляемые в составе squid хелперы аутентификации squid_ldap_auth и digest_ldap_auth, а также внешний хелпер squid_ldap_group. Обратите внимание, что с выходом в августе 2012 года squid версии 3.2 названия многих хелперов изменились на более логичные. Так, squid_ldap_auth теперь называется basic_ldap_auth, а squid_ldap_group — ext_ldap_group_acl. Тем не менее, это одни и те же программы с одними и теми же аргументами. В примерах мы будем придерживаться новых названий хелперов, чтобы соответствовать реалиям сегодняшнего дня.

Кроме штатных, поставляемых с дистрибутивом (пакетом) squid хелперов, можно сконфигурировать сервер на использование любой другой внешней программы, удовлетворяющей всё тем же критериям: она должна считывать параметры со стандартного потока ввода и выдавать на стандартный вывод итоговое сообщение, начинающееся с OK либо ERR. Программа может быть написана на любом компилируемом или интерпретируемом языке, и даже на языке интерпретатора команд оболочки. Примеры таких хелперов будут приведёны ниже.

Наконец, несколько слов о том, как хелперы настраиваются в конфигурационном файле squid.conf. Первое, на что хотелось бы обратить внимание, — это оформление вызова хелперов в squid.conf. Обычно перед тем, как вызов хелпера будет помещён в конфигурационный файл, его тестируют прямо из командной оболочки (примеры будут приведены далее). При этом многим аргументам командной строки передаются сложные текстовые значения, содержащие пробелы, и эти значения обрамляются кавычками. Так вот, если вызов из командной строки позволяет для обрамления текстовых значений аргументов использовать как одинарные, так и двойные кавычки, то при оформлении этого вызова в файле squid.conf для обрамления текстовых значений аргументов допускается использовать только двойные кавычки. Если вы ошибётесь, squid просто не будет вызывать этот хелпер, хотя и ошибок не выдаст. Например, при вызове хелпера из оболочки значения его аргументов вполне можно заключить в одинарные кавычки:

# /path/to/basic_ldap_auth -b 'dc=mycompany,dc=ru' -f 'uid=%s' -d

Но в squid.conf те же значения аргументов хелпера обрамляются двойными кавычками:

auth_param basic program /path/to/basic_ldap_auth -b "dc=mycompany,dc=ru" -f "uid=%s" 

Второе, на что необходимо обратить внимание — это работа со значениями, содержащими пробелы. Типичная ситуация — многие системные администраторы используют пробелы в названиях групп LDAP, например группа с RDN cn=Inet Full Access. Если подобные группы используются для разграничения доступа в ACL squid, то наличие пробела необходимо учитывать как при тестировании хелпера из командной строки, так и при оформлении директивы acl в squid.conf . Чтобы не быть голословными, мы рассмотрим подобный случай в дальнейшем на примере.

1.2. Поиск записей в каталоге LDAP

Хотелось бы коротко напомнить, как работает операция поиска LDAP, поскольку эти знания являются ключевыми для последующего понимания взаимодействия squid и LDAP-каталога. Данные в каталоге можно логически представить в виде дерева подчинённых друг другу записей. Для описания совокупности всех записей в каталоге даже существует соответствующий термин — информационное дерево каталога (Directory Information Tree, DIT). Для наглядности введём дерево, на которое мы будем опираться в дальнейших примерах:

# Корневая запись dn: dc=mycompany,dc=ru objectClass: organization objectClass: dcObject dc: mycompany o: My Company # Ветка "Люди" dn: ou=People,dc=mycompany,dc=ru objectClass: organizationalUnit ou: People dn: uid=vitaly,ou=People,dc=mycompany,dc=ru objectClass: inetOrgPerson uid: vitaly cn: Vitaly Fridzon sn: Fridzon userPassword: vitalyPassword dn: uid=anton,ou=People,dc=mycompany,dc=ru objectClass: inetOrgPerson uid: anton cn: Anton Ponkrashov sn: Ponkrashov userPassword: antonPassword dn: uid=alex,ou=People,dc=mycompany,dc=ru objectClass: inetOrgPerson uid: alex cn: Aleksey Savrasenko sn: Savrasenko userPassword: alexPassword # Ветка "Руководство" dn: ou=Managers,dc=mycompany,dc=ru objectClass: organizationalUnit ou: People dn: uid=vasily,ou=Managers,dc=mycompany,dc=ru objectClass: inetOrgPerson uid: vasily cn: Vasily Karasev sn: Karasev userPassword: vasilyPassword # Ветка "Группы" dn: ou=Groups,dc=mycompany,dc=ru objectClass: organizationalUnit ou: Groups

Примечание: В нашем каталоге пароли (значения атрибутов userPassword в записях пользователей) указаны в открытом виде. Это сделано для простоты и удобства работы с последующими примерами. В реальном каталоге, конечно же, такого быть не должно! Используйте хэши паролей или другие схемы аутентификации.

Операция поиска LDAP — это процесс отбора из всех записей каталога тех, которые удовлетворяют заданным критериям. Поиск осуществляется «сверху-вниз», то есть начиная от какой-то определённой записи каталога (она называется базой поиска, в английском варианте — basedn) в сторону подчинённых ей записей. Итак, первым критерием поиска является базовая запись, то есть запись, с которой поиск будет начинаться. Вторым критерием является так называемый диапазон поиска (в английском варианте — scope), то есть какие именно записи (начиная от базовой и вниз по дереву) будут рассматриваться в качестве предмета, по которому во время поиска будет производиться отбор. Стандартные диапазоны поиска: base (поиск затрагивает только базовую запись), one (поиск затрагивает записи на один уровень ниже базовой, но не саму базовую запись) и sub (поиск по всему дереву, начиная с указанной базовой записи и включая её саму). Во многих LDAP-клиентах, в том числе в связанных с LDAP стандартных хелперах squid, диапазон поиска по умолчанию задан в sub, но это значение можно переопределить. Приведём несколько примеров LDAP-поиска по нашему каталогу с помощью ldapsearch.

Пример 1.2.1. Обход всего каталога

# ldapsearch -x -LLL -b 'dc=mycompany,dc=ru' 1.1 dn: dc=mycompany,dc=ru dn: ou=People,dc=mycompany,dc=ru dn: uid=vitaly,ou=People,dc=mycompany,dc=ru dn: uid=anton,ou=People,dc=mycompany,dc=ru dn: uid=alex,ou=People,dc=mycompany,dc=ru dn: ou=Managers,dc=mycompany,dc=ru dn: uid=vasily,ou=Managers,dc=mycompany,dc=ru dn: ou=Groups,dc=mycompany,dc=ru

Поиск от корневой записи dc=mycompany,dc=ru с диапазоном sub (по умолчанию). Возвращаются все имеющиеся в каталоге записи.

Пример 1.2.2. Обход ветки «Люди» (изменяем базовую запись)

# ldapsearch -x -LLL -b 'ou=People,dc=mycompany,dc=ru' 1.1 dn: ou=People,dc=mycompany,dc=ru dn: uid=alex,ou=People,dc=mycompany,dc=ru dn: uid=anton,ou=People,dc=mycompany,dc=ru dn: uid=vitaly,ou=People,dc=mycompany,dc=ru

Поиск с указанием более «узкой» базовой записи ou=People,dc=mycompany,dc=ru с диапазоном sub (по умолчанию). Возвращаются все записи указанной ветки, в том числе сама базовая запись.

Пример 1.2.3. Обход ветки «Люди» (изменяем диапазон поиска)

# ldapsearch -x -LLL -b 'ou=People,dc=mycompany,dc=ru' -s one 1.1 dn: uid=alex,ou=People,dc=mycompany,dc=ru dn: uid=anton,ou=People,dc=mycompany,dc=ru dn: uid=vitaly,ou=People,dc=mycompany,dc=ru

Поиск с той же базовой записью, что и в предыдущем примере, но с диапазоном one. Возвращаются только записи людей, то есть только записи, дочерние по отношению к базовой.

Как видите, всё очень просто и прозрачно.

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

Пример 1.2.4. Выбор всех записей людей из каталога

# ldapsearch -x -LLL -b 'dc=mycompany,dc=ru' '(objectClass=inetOrgPerson)' 1.1 dn: uid=vitaly,ou=People,dc=mycompany,dc=ru dn: uid=anton,ou=People,dc=mycompany,dc=ru dn: uid=alex,ou=People,dc=mycompany,dc=ru dn: uid=vasily,ou=Managers,dc=mycompany,dc=ru

Поиск с теми же условиями, что и в первом примере, с добавлением фильтра «нас интересуют только записи с объектным классом inetOrgPerson «. Как видите, возвращены записи из обоих веток People и Manages. Аналогичных результатов можно добиться и другим фильтром:

# ldapsearch -x -LLL -b 'dc=mycompany,dc=ru' '(uid=*)' 1.1 dn: uid=vitaly,ou=People,dc=mycompany,dc=ru dn: uid=anton,ou=People,dc=mycompany,dc=ru dn: uid=alex,ou=People,dc=mycompany,dc=ru dn: uid=vasily,ou=Managers,dc=mycompany,dc=ru

В данном случае фильтр означает «отбор записей, у которых есть атрибут uid «. Еще один, более комплексный вариант такого отбора:

# ldapsearch -x -LLL -b 'dc=mycompany,dc=ru' '(&(objectClass=inetOrgPerson)(uid=*))' 1.1 dn: uid=vitaly,ou=People,dc=mycompany,dc=ru dn: uid=anton,ou=People,dc=mycompany,dc=ru dn: uid=alex,ou=People,dc=mycompany,dc=ru dn: uid=vasily,ou=Managers,dc=mycompany,dc=ru

Мы объединили оба наших фильтра логическим «И». Результат тот же.

Пример 1.2.5. Выбор записи конкретного человека

# ldapsearch -x -LLL -b 'dc=mycompany,dc=ru' '(uid=vasily)' 1.1 dn: uid=vasily,ou=Managers,dc=mycompany,dc=ru

Поиск с теми же условиями, что и в первом примере, с добавлением фильтра «только записи, у которых есть атрибут uid со значением vasily«. Примеры неудачного поиска:

# ldapsearch -x -LLL -b 'dc=mycompany,dc=ru' '(uid=petr)' 1.1 # ldapsearch -x -LLL -b 'ou=People,dc=mycompany,dc=ru' '(uid=vasily)' 1.1

В первом случае в каталоге нет записей с атрибутом uid , имеющим значение petr. Во втором случае в ветке People нет записей с атрибутом uid , имеющим значение vasily.

Трудно изложить концепцию фильтрации в двух словах, но и приведённых примеров достаточно, чтобы чувствовать себя уверенно в последующей работе. Подробнее о поисковых фильтрах LDAP можно почитать в RFC 4515, а о самом поиске — в RFC 4511.

После такой обстоятельной вводной части пора переходить к настройке squid.

Последнее изменение страницы — 13 октября 2016 года.