Что это за 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,'example\rt');
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'                 =>  'example\rt',
        'pass'                 =>  'rt_password',
        'base'                 =>  'dc=example,dc=com',
        'filter'                  =>  '(objectCategory=person)',
        'attr_match_list'  => ['Name'],
        'attr_map'           => {
                                  'Name'              => 'sAMAccountName',
                                  'EmailAddress'  => 'mail',
                                  'RealName'       => 'cn',
                                        },
                                     },
                                  } );

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

Для самостоятельной работы


Должен отметить, что после подключения к ldap создание локальных пользователей становится невозможным, но старые пользователи из внутренней БД продолжают успешно авторизоваться. Flashick подсказал, что для возможности создания локальных учеток в RT нужно добавить в конфиг Set($AutoCreateNonExternalUsers, 1);

Еще один момент — если в домене для пользователей включен «Вход на», то пока отключайте, а в следующий раз расскажу, как поправить.

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

UPD1: Flashick говорит что в версии RT 4.4 оба плагина уже есть по умолчанию и их не надо скачивать и ставить отдельно.

UPD2: по всему процессу, начиная с установки записал несколько видео в плейлист для тех, кто любит следить за процессом наглядно.

Комментарии (8)


  1. Flashick
    08.02.2016 11:27

    А что подразумевается под созданием локальных пользователей после подключения LDAP?
    Если возможность авторизации без AD уже созданных пользователей, то для этого нужно просто в профиле задать пользователю пароль.
    Если имеется ввиду просто заведение новых пользователей, то, по крайней мере, использование только второго варианта, с RT::Authen::ExternalAuth, эту возможность оставляет.


    1. semaev
      09.02.2016 12:26

      После подключения к LDAP нет возможности создать пользователя вручную через админку RT. Приходится создавать пользователей в LDAP, а это не всегда оправдано. Например мне, как аутсорсеру, приходится в компании-клиенте в LDAP создавать дополнительные учетки для своих админов, что не всегда удобно, да и вообще множит сущности


      1. Flashick
        09.02.2016 15:41

        Странно — у меня эта возможность осталась. Правда, я не использую RT::Extension::LDAPImport, но, видимо, это значения не имеет — обновился на 4.4, где оба плагина включены, в конфиге настроен ldap, но возможность добавлять новых пользователей через админку никуда не исчезла.


  1. Flashick
    08.02.2016 13:11

    + на днях вышла версия 4.4, там оба описанных плагина теперь по умолчанию включены в РТ


    1. semaev
      09.02.2016 12:27

      А это вообще шикарная новость, спасибо, отмечу на канале