RFC (Request for Comments, Запрос на комментарии) - серия документов, публикуемая сообществом исследователей и разработчиков, руководствующихся практическими интересами, в которой описывается набор протоколов и обобщается опыт функционирования Интернет.
FreeBSD: Вставка информации о пользователях Active Directory в отчеты SARG [2011]
Если раньше генератор отчетов SARG (Squid Analysis Report Generator), работающий совместно с прокси-сервером Squid, настроенным с поддержкой каких-либо методов аутентификации клиентов по имени и паролю, позволял системным администраторам изменять имена пользователей, помещаемые в поле USERID создаваемых отчетов, только с помощью поддерживаемых вручную статических таблиц, то теперь (начиная с версии 2.3) SARG "научился" получать информацию о пользователях на LDAP-серверах.
Постановка задачи
По умолчанию SARG, работающий совместно со Squid, интегрированным в домен Active Directory (далее - домен) для обеспечения поддержки NTLM и basic аутентификации клиентов, помещает в поле USERID создаваемых отчетов login'ы пользователей вида iivanov, загружаемые из лога доступа Squid. Эта коротенькая заметка посвящена дополнительной настройке SARG, которая обеспечивает добавление в поле USERID создаваемых отчетов "человеческих" имен пользователей вида Иван И. Иванов, получаемых на LDAP-серверах, работающих на контроллерах домена.
Исходные данные
Не смотря на то, что все действия, описанные ниже, выполнялись на сервере с операционной системой FreeBSD 8.2, данная инструкция подойдет для любой операционной системы семейства Linux/Unix. Единственным условием успешного решения рассматриваемой задачи является использование SARG версии ≥ 2.3 (SARG, доступный в текущей версии коллекции портов FreeBSD, соответствует этому условию).
Добавление пользователя ldap в домен
Даже с учетом того, что SARG может подключаться к LDAP-серверам, работающим на контроллерах домена, от имени любого активного пользователя этого домена, срок действия пароля которого не истек, я предпочитаю выделять для таких целей отдельного пользователя ldap. Пользователь ldap может быть создан как средствами оснастки Active Directory - Пользователи и компьютеры, так и из Командной строки (Command Prompt) Windows. В первом случае после создания аккаунта потребуется установить в его свойствах галочки Запретить смену пароля пользователем и Срок действия пароля не ограничен, второй случай позволяет сократить "трудозатраты" и заключается в выполнении единственной команды, сразу учитывающей необходимость установки нужных галочек и имеющей следующий вид (не забудьте заменить слово password выбранным паролем):
net user ldap password /add /expires:never /passwordchg:no /domain
Для проверки возможности взаимодействия между сервером с FreeBSD и LDAP-серверами, работающими на контроллерах домена, подойдет утилита net(8). Например, для того, чтобы обратиться к LDAP-серверам от имени созданного ранее пользователя ldap, имеющего пароль password, с целью получения списка пользователей домена, информация о которых имеется в LDAP-каталоге Active Directory, можно выполнить команду:
net ads search '(objectCategory=user)' sAMAccountName -U ldap%password
Настройка взаимодействия SARG с LDAP-серверами
Для того, чтобы SARG начал вставлять в создаваемые отчеты "человеческие" имена пользователей, а не их login'ы, необходимо добавить в файл его конфигурации, по умолчанию имеющий имя /usr/local/etc/sarg/sarg.conf, строки:
задающие следующие значения параметров SARG: usertab - метод замены имен пользователей; LDAPHost - имя LDAP-сервера (в рассматриваемом случае - имя домена, разрешаемое в список IP-адресов его контроллеров); LDAPBindDN и LDAPBindPW - имя и пароль, используемые при подключении к LDAP-серверам; LDAPBaseSearch - базовый каталог LDAP (в рассматриваемом случае - Подразделение (Organization Unit) Active Directory, содержащее пользователей прокси-сервера); LDAPFilterSearch - фильтр поиска объектов LDAP (в рассматриваемом случае - поиск объектов, имеющих значения LDAP-атрибутов sAMAccountName, совпадающие с login'ами, пользователей полученным SARG'ом из журнала доступа Squid).
Во избежание вопросов нужно отметить, что по умолчанию SARG использует в качестве "человеческих" имен пользователей значения LDAP-атрибутов CN (Common Name), являющиеся объединениями значений LDAP-атрибутов giveName, initials и SN (имен, инициалов и фамилий). Такое поведение SARG может быть изменено посредством добавления еще одной строки в файл его конфигурации. Например, для того, чтобы SARG добавлял в поле USERID создаваемых отчетов значения LDAP-атрибутов displayName (отображаемые имена), данная строка должна иметь следующий вид:
LDAPTargetAttr displayName
Для проверки работоспособности функций LDAP можно запустить SARG с ключом -x, обеспечивающим вывод отладочной информации на консоль. В случае отсутствия ошибок процесс генерации отчета должен сопровождаться примерно такими сообщениями:
SARG: Init
SARG: Loading configuration from /usr/local/etc/sarg/sarg.conf
При возникновения каких-либо перебоев в работе функций LDAP вместо генерации отчета будет отображено соответствующее сообщение об ошибке. Например, в случае проблем с подключением к LDAP-серверам оно будет выглядеть так:
SARG: Init
SARG: Loading configuration from /usr/local/etc/sarg/sarg.conf
SARG: Cannot bind to LDAP server: Can't contact LDAP server
Удаление строк с пустым полем USERID из отчетов
После активации поддержки LDAP в отчетах SARG могут появляться строки с пустым полем USERID. Это обстоятельство обусловлено тем, что записи с кодом TCP_DENIED/407, добавляемые Squid'ом в журнал доступа при возникновении ошибок аутентификации, не содержат login'ы пользователей. При обработке таких записей SARG не располагает исходными данными для "выяснения" имен пользователей и оставляет поля USERID пустыми.
Для того, чтобы SARG игнорировал все записи журнала доступа Squid, не имеющие в своем составе login'ы пользователей, необходимо добавить в файл его конфигурации строку:
records_without_userid ignore
Согласование кодировок русских букв в отчетах
Активация поддержки LDAP может вызвать частичную или полную рассогласованность кодировок русских букв в отчетах SARG, визуально выглядящую как отображение нечитаемой абракадабры вместо символов кириллицы. Для устранения данной неприятности нужно: во-первых, изменить кодировку отчетов SARG на UTF-8, а, во-вторых, изменять на время создания отчетов имя локализации пользователя, запускающего SARG, на ru_RU.UTF-8.
Для изменения кодировки отчетов SARG на UTF-8 необходимо в файле его конфигурации привести определение параметра charset к такому виду:
charset UTF-8
а для изменения имени локализации соотвтествующего пользователя перед созданием отчетов SARG на ru_RU.UTF-8, следует предварять команды запуска SARG командами изменения значения переменной окружения LANG на ru_RU.UTF-8. На всякий случай напоминаю, что при использовании командного интерпретатора sh(1) или bash(1) команда изменения значения переменной окружения LANG на ru_RU.UTF-8 будет выглядеть так:
export LANG=ru_RU.UTF-8
а в случае применения интепретатора команд tcsh(1) вот так:
setenv LANG=ru_RU.UTF-8
Заключение
В результате выполнения несложной последовательности действий, которая описана в этой заметке, Вы сможете повысить удобочитаемость отчетов SARG и лишний раз без зазрения совести напомнить руководству, что прикладываете все силы для облегчения труда людей, которые осуществляют административное регулирование использования ресурсов Интернет сотрудниками компании.