Binding Request Traker 4.x on Ubuntu to ldap using ActiveDirectory as an example

What is this RT

For a long time I have been using the Secure Scout request tracker in my outsourcing company, now called the BestPractical Request Tracker. Request Tracker is good because it is operssovy, written in Perl, undemanding to resources, flexible and allows you to fasten any functionality to yourself. There is no point in telling more, at one time zar0ku1 wrote a good article on installing RT 3.8, then the manual slightly refreshed @ Spanish pilot, and mister_j even talked about RT programming.

We will take a step further and find out how to tie RT authorization to ldap using the example of AD, so that users can create applications and track their progress using their domain account. In addition to individualizing the tracker, it will be possible to automatically update information (name, email, department, etc.) about RT users from the directory service.

What external authorization features are built into RT

BestPractical offers us two types of authentication through an external source: using the login form (which throws the authorization request further) or bypassing the login form using the capabilities of the web server to automatically identify the user (for example, NTLM). I must say that BestPractical recommends including both features, which we will do.

In order not to plunge into the abyss of technical manuals, I will say this: you can fasten authentication to the login form so that the domain user is automatically created in RT when you enter the application portal, or you can create a script that will periodically download new users from the directory. BestPractical, again, insists on both options.

Enabling import of accounts from LDAP

To connect to a domain, you need to create a regular user account in AD (or in your directory service implementation).

PS C:\> New-ADUser -Name "Request Tracker" -GivenName rt -SamAccountName rt -UserPrincipalName rt@example.com -AccountPassword (Read-Host -AsSecureString "rt_password")

On the RT host, you need to download the Perl module specially created for import purposes:

sudo cpan -i RT::Extension::LDAPImport

Then add the following to the RT configuration file (in my case, this is /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); 

In this example, I specify to import all users of the domain ( $ LDAPFilter ), starting from the root ( $ LDAPBase ), swapping their name, login and email ( $ LDAPMapping ). Accounts will automatically have access to RT ( $ LDAPCreatePrivileged ) and their information will be updated with each new import request ( $ LDAPUpdateUsers ).

The import module allows you to import accounts from different departments, import groups, download more information about LDAP users, etc. It’s enough for me that I showed you. If you want to know more, read the manual modulo.

The import process itself is simple. To get started, you can run a test import and see how it ended:

sudo /opt/rt4/local/plugins/RT-Extension-LDAPImport/bin/rtldapimport --debug > ldapimport.debug 2>&1
sudo cat ldapimport.debug 

As a rule, errors occur when the firewall is enabled and the LDAP search database is incorrectly specified. If everything went well, you can start the import fully:

sudo /opt/rt4/local/plugins/RT-Extension-LDAPImport/bin/rtldapimport --import

If, like me, it was enough not to separate users into groups when importing, then users will by default be added to RT in the Imported From LDAP group . This group will need to be given the appropriate rights to the queue in RT, or manually disassemble the users. I’ll separately note that users still don’t have any passwords, they can’t log into RT, we just imported information about them into RT and we can configure access levels for them.

In order for user information to be updated regularly, you can create a task in the scheduler, for example:

sudo echo "01 1    * * *   root    /opt/rt4/local/plugins/RT-Extension-LDAPImport/bin/rtldapimport --import" >> /etc/crontab

Authorization through an external source

To actually send requests to a domain controller or other owner of the ldap directory, you also need the Perl module:

sudo cpan -i RT::Authen::ExternalAuth

In the RT_SiteConfig.pm configuration file, you need to add information about the downloaded plugin:

Set(@Plugins, qw(RT::Extension::LDAPImport RT::Authen::ExternalAuth));

And provide information for accessing the ldap directory:

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',
                                        },
                                     },
                                  } );

In this example, I again do not bind groups, import a minimum of information and indicate the entire domain, starting from the root, as the base for searching for information. Who needs more - go and read the manual .

For independent work

It should be noted that after connecting to ldap, creating local users becomes impossible, but old users from the internal database continue to log in successfully. Flashick suggested that in order to be able to create local accounts in RT, you need to add one more thing to the config : if “Login to” is enabled in the domain for users, then disconnect for now, and next time I’ll tell you how to fix it. Next time I’ll talk about how to make authorization transparent to the user without requiring a password and login, getting this information automatically. UPD1: Flashick says that in version RT 4.4 both plugins are already by default and do not need to be downloaded and installed separately.Set($AutoCreateNonExternalUsers, 1);







UPD2: throughout the process, starting with the installation, I recorded several videos in a playlist for those who like to monitor the process visually.