How to Enable Self-Service Password Reset in Request Tracker (RT)

enable self service password reset on request tracker

In this tutorial, you will learn how to enable self-service password reset in Request Tracker (RT). By default, RT doesn’t ship with a built-in password reset feature, and there’s a very good security reason for this decision.

Request Tracker has a unique architecture that may create a potential security vulnerability when it comes to password management. Unlike typical web applications where users must explicitly register for an account, RT automatically creates user accounts for anyone who sends an email to the ticket system. These users, called unprivileged users or requestors, are created simply by submitting a ticket via email.

If RT included an unrestricted password reset feature out of the box, anyone who has ever sent an email to your RT instance could potentially use the “forgot password” link to create a password and log into the self-service portal. This could potentially expose ticket information and data that these requestors should never have access to through the web interface.

And I believe that is why the self-service password reset feature was made an optional extension rather than a core feature. The extension, called RT-Extension-ResetPassword, includes specific configuration options to control who can reset passwords and prevent unauthorized access.

When Should You Use Self-Service Password Reset?

You should only enable self-service password reset in RT if your users need direct access to the RT web interface and you can control who is allowed to request password resets. This typically applies to environments where:

  • You have a known, limited set of users (e.g., customers, vendors, or partners) who log into RT’s self-service portal to view or update their own tickets.
  • Your RT instance is not publicly exposed, or access is restricted behind VPN or authentication gateways.
  • You’ve configured RT so that unprivileged accounts are manually created or vetted instead of allowing automatic account creation from incoming emails.
  • You want to provide a more modern, user-friendly experience for trusted users who interact with your helpdesk online.

However, if your RT system automatically creates users when they send an email, or if it’s exposed to the public Internet, it’s safer not to enable password resets. In those cases, it’s better to either:

  • Integrate RT with an external authentication system (like LDAP, Active Directory, or SSO), or
  • Leave access to the self-service portal email-only, without passwords.
Important Note
RT-Extension-ResetPassword only works with RT’s internal authentication system. If your RT instance uses external authentication such as LDAP, Active Directory, e.t.c, this extension will not work because RT doesn’t have the ability to reset passwords in those external systems. Most medium and large organizations integrate RT with their existing directory services, which handle password resets through their own self-service portals. If your organization already has AD/LDAP, you should integrate RT with your directory service using RT::Authen::ExternalAuth instead of implementing this extension. This provides better security, centralized management, and a single password for your users across all systems.

Enable Self-Service Password Reset in Request Tracker (RT)

Prerequisites

Before you begin, ensure you have:

  • Root or sudo access to your RT server
  • RT is installed and running (we are running RT v6.0.2 in this setup)
  • CPAN or cpanm installed for Perl module management
  • A working email configuration in RT (required for sending password reset emails)
  • RT using internal authentication (not LDAP/AD/SAML).
  • Ensure RT is configured with HTTPS! While the extension will function over HTTP, it is insecure and not recommended. Refer to the link below on how to enable HTTPS for RT.

How to Enable HTTPS for Request Tracker on Linux

Step 1: Back Up Your RT Database and Configuration

Before making any changes, it’s strongly recommended that you back up your RT instance, including both the database and configuration files. Installing new plugins can sometimes require database updates or configuration changes, so having a backup ensures you can easily roll back if something goes wrong.

In our RT instance, we are using MariaDB database. Hence, to do a backup, simply run (Replace the user and database names accordingly):

mariadb-dump -u root -p rt6 > /opt/rt6_$(date +%F).sql

For other types of databases, please refer to their documentation on how to run backup.

Next, backup RT configuration:

Note
The exact RT path might differ depending on your version (e.g., /opt/rt6 for RT 6 installations). Adjust the paths accordingly.
tar czf /opt/rt_configs_$(date +%F).tar.gz /opt/rt6

Once you have a backup, you can safely proceed with installing the RT::Extension::ResetPassword plugin.

Step 2: Install RT-Extension-ResetPassword

The extension can be installed from CPAN or directly from GitHub.

Install Plugin from CPAN

To install from CPAN, you can first confirm if the extension is available on CPAN:

cpanm --info RT::Extension::ResetPassword

If it’s available, you’ll see output similar to:

BPS/RT-Extension-ResetPassword-2.00.tar.gz

This tells you:

  • BPS: the CPAN author ID for Best Practical Solutions, the developers of RT.
  • RT-Extension-ResetPassword: the distribution name.
  • 2.00: the latest version number available on CPAN.

To ensure that you are installing the latest version, check that this version matches the latest release tag on GitHub: RT-Extension-ResetPassword Tags. If a newer tag exists, you may want to install directly from the GitHub repository instead of CPAN.

To install the plugin from CPAN run the command below:

cpanm RT::Extension::ResetPassword

Install the Plugin from GitHub

To install the latest release from Github repo, simply clone the repo;

git clone https://github.com/bestpractical/rt-extension-resetpassword.git

Change in to the source directory;

cd rt-extension-resetpassword/

Then build and install the extension:

perl Makefile.PL

If any modules are Perl missing, for example, you may get such an error:

Can't locate inc/Module/Install.pm in @INC (you may need to install the inc::Module::Install module) (@INC entries checked: /usr/local/lib64/perl5/5.40 /usr/local/share/perl5/5.40 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5) at Makefile.PL line 1.
BEGIN failed--compilation aborted at Makefile.PL line 1.

Then you can install the module as shown below:

cpanm Module::Install

Once the required modules are installed, regenerate the Makefile for building and install the extension:

perl Makefile.PL

If all goes well, proceed to build and install the extension:

make
make install

Step 3: Initialize the Database

The extension requires database schema updates to create the necessary tables and fields for tracking password reset requests and tokens.

Note
You can initialize the database only the first time you install this module. Running the initialization more than once may create duplicate data in your database. If you are upgrading this module, check the upgrade instructions to ensure any necessary changes are applied to your database.

How you initialize the DB depends on the installation method:

  • Option 1 (Manual Build via the Source repository):
    From the extension directory, run:
    make initdb
  • Option 2 (cpanm installation):
    You need to locate the installed extension directory (where RT Extension lives usually /opt/rtN/local/plugins) and run the same command. For example, if you are running RT 6:
    Navigate to plugins directory:
    cd /opt/rt6/local/plugins/RT-Extension-ResetPassword
    Then initialize the DB (Replace RT_MAJ_VER with major RT version like 6, and EXT_VAR with the version of the installed password reset extension). Provide database root user password when prompted.
    RT_MAJ_VER=6
    EXT_VER=2.00
    /opt/rt${RT_MAJ_VER}/sbin/rt-setup-database \
    --action insert \
    --datadir etc \
    --datafile etc/initialdata \
    --dba root \
    --prompt-for-dba-password \
    --package RT::Extension::ResetPassword \
    --ext-version ${EXT_VER}

Step 4: Configure RT_SiteConfig.pm to Enable Password Reset Option

Now you need to enable and configure the extension in RT’s main configuration file. Edit your RT configuration file (typically located at /opt/rtN/etc/RT_SiteConfig.pm:

vim /opt/rt6/etc/RT_SiteConfig.pm

Append the following lines:

# Enable the ResetPassword extension
Plugin('RT::Extension::ResetPassword');

# Basic Configuration Options
Set($AllowUsersWithoutPassword, 0);
Set($CreateNewUserAndSetPassword, 0);
Set($CreateNewUserAsPrivileged, 0);
Set($DisableResetPasswordOnLogin, 0);
Set($PasswordChangeLinkExpirySeconds, 14400);
Set($ResetPasswordFromAddress, '[email protected]');
Set($MinimumPasswordLength, 10);

Where:

  • $AllowUsersWithoutPassword: Allows existing users without a password to request a password reset and set one. If set to false, only users who already have a password can use the reset feature. Adds password status and filtering options on the user admin page.
  • $CreateNewUserAsPrivileged: When true, newly created users become privileged users. This is risky as it can allow anyone to create a privileged account; usually should remain false.
  • $CreateNewUserAndSetPassword: When true, allows non-existent users to create new accounts during the password reset process. Use with caution, especially if combined with $CreateNewUserAsPrivileged.
  • $DisableResetPasswordOnLogin: When true, hides the “Forgot password?” link on the login page, limiting password resets to admin-initiated actions only.
  • $PasswordChangeLinkExpirySeconds: Defines how long password reset links remain valid, in seconds. The default is 14400s (four hours).
  • $ResetPasswordFromAddress: Specifies a different “From” address for password reset emails instead of using the default $CorrespondAddress.
  • $MinimumPasswordLength: Sets the minimum password length (to 10 characters as shown above). Default is 5 characters.

Save and exit the file.

Then check the configuration for any errors:

perl -c /opt/rt6/etc/RT_SiteConfig.pm

Ensure the syntax is Ok.

Next, clear your mason cache and restart the web server.

rm -rf /opt/rt6/var/mason_data/obj

I am using HTTPD. Hence, replace the service name accordingly.

systemctl restart httpd

Step 5: Verify the Password Reset Option on the RT Login Page

Return to the RT login page and confirm that the Forgot Password option is now visible and enabled.

How to Enable Self-Service Password Reset in Request Tracker (RT)

Click on the link to open the password reset form. You will notice that the password reset link is sent via email.

request tracker password reset form

Therefore, ensure that your RT instance is properly configured to send outgoing emails. Proceed to the next step to configure the email settings.

Step 6: Configure Email Settings

For the self-service password reset feature to work, RT must be able to send password reset tokens to users via email. In our setup, we have already configured RT to deliver emails through MSMTP, using both Gmail and Office 365 as SMTP relays. You can refer to the guide below for detailed configuration steps:

Configure Request Tracker (RT) to send Mails using MSMTP

RT will automatically use the same email delivery configuration to send password reset messages. No additional mail settings are required. Just ensure your MSMTP setup is working correctly by testing regular ticket email notifications before enabling the password reset feature.

Step 7: Test Self Password Reset Feature on RT

The password reset feature is now enabled. To verify it works, follow these steps as a user who already has an RT account:

  1. Open the RT web interface in your browser.
  2. On the login page, click “Forgot password?” as shown above.
  3. You will be prompted to enter your account email address.
    How to Enable Self-Service Password Reset in Request Tracker (RT)
  4. Enter it and click Send it!
  5. Check your email inbox for the password reset message. This email should contain a link to reset your password. Be sure to check the spam folder.
    Here is my sample password reset email from RT:
    How to Enable Self-Service Password Reset in Request Tracker (RT)
  6. You can also check the logs. For example, since we use MSMTP for email delivery, check MSMTP as well as RT logs:
    tail -f /var/log/rt6/rt.log /opt/rt6/var/log/msmtp.log
    Sample logs:
    ==> /opt/rt6/var/log/msmtp.log <==
    Oct 31 14:55:02 host=smtp.gmail.com tls=on auth=on [email protected] [email protected] [email protected] mailsize=658 smtpstatus=250 smtpmsg='250 2.0.0 OK 1761915764 5b1f17b1804b1-47728a96897sm94079545e9.11 - gsmtp' exitcode=EX_OK

    ==> /var/log/rt6/rt.log <==
    [42751] [Fri Oct 31 14:55:01 2025] [info]: Password reset token send to [email protected] (/opt/rt6/local/plugins/RT-Extension-ResetPassword/html/NoAuth/ResetPassword/Request.html:102)
  7. Click the link and follow the instructions to set a new password.
Note
By default, RT enforces a minimum password length of 5 characters. This is generally is not sufficient. You can adjust it to a lenght that is defined by your internal password policies. Modern security practices emphasize longer, unique passwords rather than strict complexity rules. You can still adjust this policy in RT’s configuration if your organization has specific or stricter requirements. For improved security and centralized account management, consider integrating RT with an external authentication source such as LDAP/Active Directory, OAuth2, or Single Sign-On (SSO). These methods reduce reliance on local passwords and help enforce consistent access policies across your organization.

Optional: Customizing RT Password Reset Email Template

Request Tracker allows you to customize the content and appearance of password reset emails. You can update the template to include your organization’s branding, security guidance, or additional instructions for users.

By default, this is how the password reset template is like:

Subject: RT Password Reset Request

Greetings,

Someone at { RT::Interface::Web::RequestENV('REMOTE_ADDR') } requested that RT send you this message
allowing you to reset your password. If you didn't request this message, please
notify your RT administrator immediately.

To reset your password, click on the following URL and enter your new password:

{ RT->Config->Get('WebURL') }NoAuth/ResetPassword/Reset/{ $Token }/{ $User->id }

Just like the one you saw on the password reset email above.

To customize the RT password reset email template, you can login to RT web interface as administrator and:

  • Click on Admin in the top menu.
  • Under Global Configuration, choose Templates.
    custom password reset template on RT
  • You will see a list of RT templates.
  • Click on the PasswordReset template to update it.
  • You can remove the default content and replace with your own. For example, this is our sample custom template.
    Subject: RT Password Reset Request

    Hello { $User->Name },

    We have received a request to reset the password for your RT account. If this request came from you, please click the link below within the next { int( RT->Config->Get('PasswordChangeLinkExpirySeconds') / 3600 ) } hours to complete the password reset.
    { RT->Config->Get('WebURL') }NoAuth/ResetPassword/Reset/{ $Token }/{ $User->id }
    For your security:
    - Use a unique, strong password with at least { RT->Config->Get('MinimumPasswordLength') } characters.
    - Never share your password or reset link with anyone.
    If you did not request a password reset, please ignore this email.
    Should you have any questions, feel free to contact the support team at [email protected].

    Best regards,
    Kifarunix Support Team
    Finally, this is how our customized template is like:
    sample custom password reset template on request tracker
  • When done, save the changes.

You can then send out a test password reset email to confirm your changes.

Conclusion

Self-service password reset in Request Tracker is a powerful feature that improves user convenience while reducing administrative overhead, but it should be enabled thoughtfully. It is best suited for controlled environments where users are known and vetted, access to RT is not public, and accounts are created or approved manually.

For organizations with external authentication systems like LDAP, Active Directory, or SSO, integrating RT with these services is the safer approach.

SUPPORT US VIA A VIRTUAL CUP OF COFFEE

We're passionate about sharing our knowledge and experiences with you through our blog. If you appreciate our efforts, consider buying us a virtual coffee. Your support keeps us motivated and enables us to continually improve, ensuring that we can provide you with the best content possible. Thank you for being a coffee-fueled champion of our work!

Photo of author
Kifarunix
DevOps Engineer and Linux Specialist with deep expertise in RHEL, Debian, SUSE, Ubuntu, FreeBSD... Passionate about open-source technologies, I specialize in Kubernetes, Docker, OpenShift, Ansible automation, and Red Hat Satellite. With extensive experience in Linux system administration, infrastructure optimization, information security, and automation, I design and deploy secure, scalable solutions for complex environments. Leveraging tools like Terraform and CI/CD pipelines, I ensure seamless integration and delivery while enhancing operational efficiency across Linux-based infrastructures.

Leave a Comment