Azure AD Authentication for RT

RT version 5.0.1, CentOS 7.9, MariaDB, Apache, FastCGI

Hello,

I would like to leverage Microsoft Azure AD for external authentication against RT. Has someone successfully accomplished this? I’ve reviewed the following, but I keep coming up short:

Thank you,
Carlos

1 Like

You can use LDAP for AD integration:

https://docs.bestpractical.com/rt/5.0.0/RT/Authen/ExternalAuth/LDAP.html

Thank you for the suggestion, however, I’m looking for something less restrictive and would allow any Microsoft Azure AD (AAD) user to authenticate against our RT instance. In our particular case, we cannot use LDAP since those variables are not exposed via AAD.

I believe RT can be configured to just have the least restrictive LDAP filter, so that any user within your AD organization can authenticate.

In our particular case, we cannot use LDAP since those variables are not exposed via AAD.

Which variables are not exposed? So long as you can authenticate to LDAP you should be good!

I may be missing something, but I am referring to Microsoft Azure AD not Active Directory (LDAP) in the traditional sense. My users do not authenticate to a “local” Forest/Domain. Their identity lives in the Azure cloud.

If there is a way to connect to Microsoft Azure AD via LDAP, I would be interested in learning how. Thank you.

It seems you’re right, it isn’t enabled by default but is possible:

Q: Can I set up a secure LDAP connection with Azure AD?

A: No. Azure AD does not support the Lightweight Directory Access Protocol (LDAP) protocol or Secure LDAP directly. However, it’s possible to enable Azure AD Domain Services (Azure AD DS) instance on your Azure AD tenant with properly configured network security groups through Azure Networking to achieve LDAP connectivity. For more information, see Configure secure LDAP for an Azure Active Directory Domain Services managed domain

Azure AD Domain Services is essentially a managed Active Directory provided by Microsoft. There is a significant uplift in cost to leverage it and overkill for my use case. What I’m trying to do should be relatively straightforward, and I was just hoping someone had done it already.

Thank you!

Could you use OAuth2 extension perhaps?

1 Like

Thank you for the suggestion! I will dig into this and let everyone know how I make out.

Did you ever get this working? A quick look suggested only Google was supported.

I am getting close. I was playing with and testing mod_auth_mellon. Since I am running Apache, I figured I would leverage Apache Auth with enhancement from Mellon. Thanks for checking in!

I am looking at using RT::Authen::OAuth2 in Ubuntu.

Have you been able to get it working?

Sorry for the delay. I didn’t get notified. To answer your question, no, I did not get this working. This has been a low priority, but I am persistent. I will find a way!

I am looking for the same thing. I want to leverage Azure AD, 2FA, etc.

I have reached out to sales to see if I can pay someone to deploy this…will let you know If they tell me it isn’t possible.

Hey Peter, and for anyone else looking to get this working, I will share how I got this working. This took me a while so I’m hoping this helps save other people time in future.

This is working fine for me in RT 5.0.3 with Apache2 on Ubuntu 22.04 using Certbot for SSL and Postgresql for DB. Your mileage may vary.

First of all, there’s no need to use an RT extension to enable this, because RT supports the REMOTE_USER environment variable, and if you are using Apache2 for a web server, there are extensions that can setup OpenID Connect so that Apache2 will authenticate you against Azure AD using OAuth2.0 and pass through claim as the REMOTE_USER request-specific environment variable.

I didn’t find any direct documentation on how to do this, so I had to piece together bits. The REMOTE_USER documentation is pretty much aimed only at Active Directory / LDAP authentication.

Prerequisites

To start with, make sure that you install the apache2 mod auth_openidc. On Ubuntu, this is packaged as libapache2-mod-auth-openidc

sudo apt install libapache2-mod-auth-openidc

Then, enable the mod and restart apache2

sudo a2enmod auth_openidc

Make sure your RT is using SSL. I used Certbot for this, instructions:

sudo apt install python3-certbot python3-certbot-apache
sudo certbot

Follow the prompts to enable SSL for your RT virtualhost, then update the RT configuration to suit SSL.

vim /opt/rt5/etc/RT_SiteConfig.pm

Set( $WebPort, '443' );

Update your rt-mailgate configuration to suit (I use /etc/aliases):

rt:         "|/opt/rt5/bin/rt-mailgate --queue general --action correspond --url https://<rturl.company.com.au>/"
rt-comment: "|/opt/rt5/bin/rt-mailgate --queue general --action comment --url https://<rturl.company.com.au>/"

Certbot will create a 2nd configuration in your /etc/apache2/sites-available/ directory with -le-ssl.conf appended to the file name. Your old configuration will be updated to redirect to SSL and the new configuration will have the SSL configuration in it. Certbot will create a cron entry to renew your certificate automatically.

Restart apache2 and make sure RT is working, test submitting ticket via email, etc. If it’s working, continue, otherwise, troubleshoot.

Setup Azure AD

Authenticating against your Azure AD is fairly straight-forward, but requires that you know a few things.

We’ll go over how to get the information you need here.

  1. tenant-id Your tenant_id can be found in your Azure Portal AD Settings Page. It will be referred to as the Directory ID
  2. client-id Your app_id. This you get when you create a new App in the Azure Portal. We will need this in module configuration as OIDCClientID
  3. client-secret Your app’s client_secret. You’ll get this when you go through setting up the rest of the newly registered App you just created. It will be referred to as the OIDCClientSecret in our module configuration.
  4. random-passphrase The some_custom_passphrase should be something you generate that’s lengthy and specific to your server. Generally, this is some 32-character long thing, like: ZasT5bgtwzA4RKcGPz68wvWVtBj8dzwV or some such.
  5. rturl.company.com.au Your RT URL.

Create new Application

  1. Login to the Azure AD portal

App registrations

  • New application registration
  • Choose any name that fits for your
  • Choose the account type for your environment
  • Reply URI
    • Web
    • The URI must match the OIDCRedirectUri you configure in mod_auth_openidc later
    • I used https://<rturl.company.com.au>/login for this which works for me (replace rturl.company.com.au with your rt domain)

Hit button “Register”

  • Application ID will be used as OIDCClientID in module configuration
  • Directory (tenant) ID will be needed for your module configuration

Manage > Certificates & secrets

  • New Client Secret
  • Enter a description
  • Choose a expiration duration
  • Hit button “Add”

Copy that value (key) You will never see it again !!! This will be used as OIDCClientSecret in module configuration later

Manage > Token configuration

  • Add optional claim
  • Token Type: ID
  • Select upn

Click button “Add”

  • Confirm Turn on the Microsoft Graph profile permission (required for claims to appear in token).

Click button “Add”

Manage > Authentication

  • Implicit grant and hybrid flows
  • Check the box next to Access tokens (used for implicit flows)
  • Check the box next to ID tokens (used for implicit and hybrid flows)

Click button “Save”

Apache configuration

This is my apache2 configuration, yours will differ somewhat, but this should get you started. You’ll need to replace the following throughout:

  • tenant-id
  • rturl.company.com.au
  • client-id
  • client-secret
  • random-passphrase

cat /etc/apache2/sites-available/rt-le-ssl.conf

<IfModule mod_ssl.c>
<VirtualHost <rturl.company.com.au>:443>

        # OIDC settings
        OIDCProviderMetadataURL https://sts.windows.net/<tenant-id>/.well-known/openid-configuration
        OIDCRedirectURI https://<rturl.company.com.au>/login
        OIDCClientID <client-id>
        OIDCClientSecret <client-secret>
        OIDCCryptoPassphrase <random-passphrase>
        OIDCRemoteUserClaim upn
        OIDCStateMaxNumberOfCookies 10 true # not sure if this is needed
        # END OIDC settings

        ErrorLog /opt/rt5/var/log/apache2.error
        TransferLog /opt/rt5/var/log/apache2.access
        LogLevel debug

        SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
        LimitRequestFieldSize 32768

        ServerName <rturl.company.com.au>

        AddDefaultCharset UTF-8

        ScriptAlias / /opt/rt5/sbin/rt-server.fcgi/

        DocumentRoot "/opt/rt5/share/html"
        <Location />

                #OIDC Settings
                SSLRequireSSL
                SSLOptions +StdEnvVars
                AuthType openid-connect
                Require valid-user
                AllowOverride Authconfig Limit
                Order allow,deny
                Allow from all
                # End OIDC Settings

                Options +ExecCGI
                AddHandler fcgid-script fcgi
        </Location>

        <Location /REST/1.0/NoAuth/mail-gateway>
                Require local
        </Location>

	SSLCertificateFile /etc/letsencrypt/live/<rturl.company.com.au>/fullchain.pem
	SSLCertificateKeyFile /etc/letsencrypt/live/<rturl.company.com.au>/privkey.pem
	Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

Configure RT

First, you need to make sure to update your RT user that you are going to login with to use their email address as their user name. This tripped me up at first.

Next, create a new file, /opt/rt5/etc/RT_SiteConfig.d/SSO.conf:

Set($WebRemoteUserAuth, 1);
Set($WebFallbackToRTLogin, 1); # Not neccessary but I like this
Set($WebRemoteUserContinuous, 1); # also not neccessary, this is the default

Now, restart apache2 and you should be able to login with SSO to Azure AD!

sudo systemctl restart apache2

I’m not sure if this will work with multi-tenant so your customers can login to self-service using SSO, that’s what I’m going to test next.

Disclaimer: This is my configuration and it works okay for me. No guarantee that this will work for you. If you want me to consult in your implementation, please feel free to fill out the contact form on my website https://mawsontech.com.au .

4 Likes

Thank you, I got it working!

But I had these problems:

  • RT did not recognize the SSO.conf, so I added the 3 lines to the main /opt/rt5/etc/RT_SiteConfig.pm config
  • I needed to add this line to /opt/rt5/etc/RT_SiteConfig.pm in order to auto create the signed in user:
    Set($WebRemoteUserAutocreate,1);

Thank you for this info!