Что это за RT
Давно использую у себя в аутсорсерской компании трекер заявок от Secure Scout, который теперь называется BestPractical Request Tracker. Request Tracker хорош тем, что он опесорсовый, написан на Perl, нетребователен к ресурсам, гибок и позволяет прикрутить к себе какой угодно функционал. Больше рассказывать нет смысла, в свое время zar0ku1 написал неплохую статью по установке RT 3.8, затем мануал немного освежил @Испанский лётчик, а mister_j даже рассказал о программировании RT.
Мы шагнем немного дальше и выясним, как привязать авторизацию RT к ldap на примере AD, чтобы пользователи могли создавать заявки и отслеживать их выполнение, используя свою доменную учетку. Помимо индивидуализации трекера, появится возможность автоматического обновления информации (имя, email, подразделение и т.д.) о пользователях RT из службы каталогов.
Какие возможности внешней авторизации встроены в RT
BestPractical предлагает нам два вида аутентификации через внешний источник: используя форму входа (которая перекидывает запрос авторизации дальше) или минуя форму входа с использованием возможностей веб-сервера опознавать пользователя автоматически (например NTLM). Нужно сказать, что BestPractical рекомендует включать обе возможности, что мы и сделаем.
Чтобы не погружаться в пучину технический мануалов, скажу так: можно прикрутить аутентификацию к форме входа так, чтобы пользователь домена автоматически создавался в RT при входе на портал заявок, а можно создать скрипт, который будет периодически загружать новых пользователей из каталога. BestPractical, опять же, настаивает на обоих вариантах.
Включение импорта учеток из LDAP
Для подключения к домену нужно создать обычную пользовательскую учетку в AD (или в вашей реализации службы каталогов).
PS C:> New-ADUser -Name "Request Tracker" -GivenName rt -SamAccountName rt -UserPrincipalName rt@example.com -AccountPassword (Read-Host -AsSecureString "rt_password")
На хост RT нужно скачать специально созданный для целей импорта модуль Perl:
sudo cpan -i RT::Extension::LDAPImport
Затем добавить в конфигурационный файл RT (в моем случае это /opt/rt4/etc/RT_SiteConfig.pm) строки:
Set(@Plugins, qw(RT::Extension::LDAPImport));
Set($LDAPHost,'domaincontroller.example.com');
Set($LDAPUser,'examplert');
Set($LDAPPassword,'rt_password');
Set($LDAPBase,'dc=example,dc=com');
Set($LDAPFilter, ' (&(objectCategory=person))');
Set($LDAPMapping, {Name => 'sAMAccountName',
RealName => 'cn',
EmailAddress => 'mail'
});
Set($LDAPCreatePrivileged, 1);
Set($LDAPUpdateUsers, 1);
В данном примере я указываю для импорта всех пользователей домена ($LDAPFilter), начиная с корня ($LDAPBase), подкачивая их имя, логин и email ($LDAPMapping). Учетные записи будут автоматически иметь доступ к RT ($LDAPCreatePrivileged) и информация о них будет обновляться при каждом новом запросе на импорт ($LDAPUpdateUsers).
Модуль импорта позволяет импортировать учетные записи из разных подразделений, импортировать группы, загружать больше информации об пользователях LDAP и т.д. Мне же достаточно того что я вам показал. Хотите знать больше — читайте мануал по модулю.
Процесс импорта сам по себе прост. Для начала можно запустить тестовый импорт и посмотреть, чем он закончился:
sudo /opt/rt4/local/plugins/RT-Extension-LDAPImport/bin/rtldapimport --debug > ldapimport.debug 2>&1
sudo cat ldapimport.debug
Как правило, ошибки возникают при включенных firewall и некорректно указанной базе поиска по LDAP. Если все прошло удачно, импорт можно запускать полноценно:
sudo /opt/rt4/local/plugins/RT-Extension-LDAPImport/bin/rtldapimport --import
Если вам, как и мне было достаточно не разделять пользователей по группам при импорте, то пользователи будут по умолчанию добавлены в RT в группу Imported From LDAP. Этой группе надо будет дать в RT соответствующие права на очереди, или вручную разобрать пользователей. Отдельно отмечу — никаких паролей у пользователей пока еще нет, входить в RT они не могут, мы просто импортировали информацию о них в RT и можем настраивать им уровни доступа.
Для того, чтобы информацию о пользователях обновлялась регулярно, можно создать задачу в планировщике, например:
sudo echo "01 1 * * * root /opt/rt4/local/plugins/RT-Extension-LDAPImport/bin/rtldapimport --import" >> /etc/crontab
Авторизация через внешний источник
Для фактической передачи запросов контроллеру домена или другому владельцу каталога ldap тоже нужен модуль Perl:
sudo cpan -i RT::Authen::ExternalAuth
В файл конфигурации RT_SiteConfig.pm нужно добавить информацию о скачанном плагине:
Set(@Plugins, qw(RT::Extension::LDAPImport RT::Authen::ExternalAuth));
И указать информацию для доступа к каталогу ldap:
Set($ExternalAuthPriority, [ 'My_AD' ] );
Set($ExternalInfoPriority, ['My_AD'] );
Set( $UserAutocreateDefaultsOnLogin, { Privileged => 1 , Lang => 'ru'} );
Set($ExternalSettings, {
'My_AD' => {
'type' => 'ldap',
'server' => 'domaincontroller.example.com',
'user' => 'examplert',
'pass' => 'rt_password',
'base' => 'dc=example,dc=com',
'filter' => '(objectCategory=person)',
'attr_match_list' => ['Name'],
'attr_map' => {
'Name' => 'sAMAccountName',
'EmailAddress' => 'mail',
'RealName' => 'cn',
},
},
} );
В этом примере я опять не делаю привязку групп, импортирую минимум информации и указываю базой для поиска информации весь домен, начиная с корня. Кому нужно больше — заходите и читайте мануал.
Для самостоятельной работы
Должен отметить, что после подключения к ldap создание локальных пользователей становится невозможным, но старые пользователи из внутренней БД продолжают успешно авторизоваться. Если кто знает как включить возможность создания локальных учеток при привязанном AD — пишите. Еще один момент — если в домене для пользователей включен «Вход на», то пока отключайте, а в следующий раз расскажу, как поправить.
В следующий раз расскажу о том, как сделать авторизацию прозрачной для пользователя, не требуя от него пароля и логина, получая эту информацию автоматически.
Автор: semaev
