Binding Request Traker 4.x on Ubuntu to ldap using the example of ActiveDirectory

What is this RT

I have been using the Secure Scout application tracker in an outsourcing company for a long time now called BestPractical Request Tracker. Request Tracker is good because it is useless, written in Perl, undemanding of resources, flexible and allows you to tie any functionality to yourself. There is no point in telling more, in due time zar0ku1 wrote a good article on installing RT 3.8, then the manual refreshed a little @ Spanish pilot, and mister_j even talked about RT programming.

We will go a little further and find out how to bind RT authorization to ldap using the example of AD, so that users can create requests and track their execution using their domain account. In addition to individualizing the tracker, you will be able 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 web server's capabilities to identify the user automatically (for example, NTLM). It must be said 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 tie authentication to the login form so that the domain user is automatically created in RT when entering the application portal, or you can create a script that will periodically load new users from the directory. BestPractical, again, insists on both options.
')

Enabling import uchetok from LDAP

To connect to the 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 a Perl module specially created for import purposes:

 sudo cpan -i RT::Extension::LDAPImport 

Then add the following lines to /opt/rt4/etc/RT_SiteConfig.pm in the RT configuration file:

 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 ), pumping up their name, login and email ( $ LDAPMapping ). Accounts will automatically have access to RT ( $ LDAPCreatePrivileged ) and information about them 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. Want to know more - read the manual on the module.

The import process itself is simple. For starters, 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, the import can be fully run:

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

If for you, as well as it was enough for me not to divide users into groups during import, then users will by default be added to RT in the Imported From LDAP group. This group will need to be given in RT the corresponding rights to the queue, or manually disassemble users. Separately, I’ll note that users don’t have any passwords yet, they cannot log in to RT, we just imported information about them into RT and 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 another owner of the ldap directory, you also need a Perl module:

 sudo cpan -i RT::Authen::ExternalAuth 

In the RT_SiteConfig.pm configuration file , add the 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 point out the entire domain, starting from the root, with a base for searching information. Who needs more - go and read the manual .

For independent work

I should note that after connecting to ldap, the creation of local users becomes impossible, but old users from the internal database continue to successfully login. Flashick suggested that in order to create local uchetok in RT you need to add Set($AutoCreateNonExternalUsers, 1);
to the config Set($AutoCreateNonExternalUsers, 1);
Set($AutoCreateNonExternalUsers, 1);

One more thing - if “Log on to” is enabled in the user domain, for now disable it and next time I will tell you how to fix it.

Next time I will talk about how to make the authorization transparent for the user, without requiring him of a password and login, receiving this information automatically.

UPD1: Flashick says that in version RT 4.4 both plug-ins already exist by default and do not need to be downloaded and installed separately.

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