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
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?
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.
Create new Application
App registrations
Hit button “Register”
Manage > Certificates & secrets
Copy that value (key) You will never see it again !!! This will be used as OIDCClientSecret in module configuration later
Manage > Token configuration
Click button “Add”
Click button “Add”
Manage > Authentication
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:
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 .
Thank you, I got it working!
But I had these problems:
Set($WebRemoteUserAutocreate,1);Thank you for this info!
@ChrisF - I have migrated my instance from CentOS 7.9 to Ubuntu 24.04 recently and I was leveraging your steps and things were working well until getting to the Entra ID portion. Do you still have your setup working? Did you have to make any changes. I think that there may have been some slight changes to RT (5.0.6) and Microsoft for things to break. I’d like to understand if this is still working for and whether there is anything you could share about your environment. Cheers!
Hi Carlos,
Posting this here for posterity, even if you do not need it anymore.
I have since moved my setup to nginx + oauth2-proxy + requesttracker5.0.7 and it’s working nicely. I will describe my configuration in the hopes that it helps someone. It took a fair bit of stuffing about to get it working but it works nicely now.
Please note, my oauth2-proxy server is on another host to my request-tracker server, so I enforce HTTPS between the two and limit connection with firewall. You might be able to skip the oauth2-proxy ssl certificate and use http://127.0.0.1:4180 in the RT5 nginx configuration, if they are on the same server.
This is on ubuntu 24.04.
Azure enterprise app
Create an ‘app registration’.
Note the <client id>, <tenant id>, and create a client secret. note the <client secret value>.
give consent to openid on Microsoft Graph. oauth2-proxy docs have a nice video: https://youtu.be/IUNfxhOzr4E
Setup oauth2-proxy
Install a DNS record for oauth.your.domain.here pointing at what will be your oauth server.
On that host, install certbot and run:
apt install python3-certbot-nginx
certbot certonly -d oauth.<your.domain.here> --agree-tos --nginx -m whatever@your.domain.here
create an oauth2-proxy user:
adduser oauth2-proxy
give oauth2-proxy read access to the ssl certificate from letsencrypt by copying the ssl certs after renewal via hook.
mkdir -p /etc/oauth2-proxy/ssl
nano /etc/letsencrypt/renewal-hooks/deploy/oauth.<your.domain.here>.sh
/etc/letsencrypt/renewal-hooks/deploy/oauth.<your.domain.here>.sh:
#!/bin/sh
pathtoyourcertsdir="/etc/oauth2-proxy/ssl"
domain="oauth.<your.domain.here>"
basedomain="$(basename $RENEWED_LINEAGE)"
youruser="oauth2-proxy"
yourgroup="$(id -ng $youruser)"
reloadcommand="systemctl restart oauth2-proxy.service"
if [ "$domain" = "$basedomain" ];then
cp "$RENEWED_LINEAGE/fullchain.pem" "$pathtoyourcertsdir/server_cert.pem"
cp "$RENEWED_LINEAGE/privkey.pem" "$pathtoyourcertsdir/server_key.pem"
chown $youruser:$yourgroup "$pathtoyourcertsdir/server_cert.pem"
chown $youruser:$yourgroup "$pathtoyourcertsdir/server_key.pem"
$reloadcommand
fi
test renewal with:
RENEWED_LINEAGE=/etc/letsencrypt/live/oauth.<your.domain.here> /etc/letsencrypt/renewal-hooks/deploy/oauth.<your.domain.here>.sh
ls /etc/oauth2-proxy/ssl
# (should see two files there, the certficate and key)
Download and install oauth2-proxy:
wget https://github.com/oauth2-proxy/oauth2-proxy/releases/download/v7.8.1/oauth2-proxy-v7.8.1.linux-amd64.tar.gz
tar xzvf oauth2-proxy-v7.8.1.linux-amd64.tar.gz
cp oauth2-proxy-v7.8.1.linux-amd64/oauth2-proxy /usr/bin/oauth2-proxy
Generate a <cookie secret> with openssl:
openssl rand -base64 32 | tr -- '+/' '-_'
Configure oauth2-proxy:
nano /etc/oauth2-proxy/oauth2-proxy.cfg
Add the following config lines:
/etc/oauth2-proxy/oauth2-proxy.cfg:
http_address = "127.0.0.1:4180"
https_address = "0.0.0.0:4181"
reverse_proxy = true
tls_cert_file = "/etc/oauth2-proxy/ssl/server_cert.pem"
tls_key_file = "/etc/oauth2-proxy/ssl/server_key.pem"
email_domains = [
"<your.domain.here>"
]
client_id = "<client-id>"
client_secret = "<client-secret>"
scope = "openid"
cookie_secret = "<cookie-secret>"
# configure for Azure AD
provider = "entra-id"
oidc_issuer_url = "https://login.microsoftonline.com/<tenant-id>/v2.0"
set_xauthrequest = true
Setup systemd unit file:
wget https://raw.githubusercontent.com/oauth2-proxy/oauth2-proxy/refs/heads/master/contrib/oauth2-proxy.service.example
cp oauth2-proxy.service.example /etc/systemd/system/oauth2-proxy.service
systemctl daemon-reload
systemctl enable --now oauth2-proxy
check the output of
systemctl status oauth2-proxy
Should be running okay. Check the output of
ss -ltpn
Should show oauth2-proxy listening on *:4181.
Allow firewall
ufw allow proto tcp from <rt.server.ip.address> to any port 4181
systemd for requesttracker cgi
Create two files:
/etc/systemd/system/rt5.service:
[Unit]
Description=RT5 ticketing system
After=syslog.target mysql.service
Wants=mysql.service
[Service]
Type=simple
ExecStart=/opt/rt5/sbin/rt-server.fcgi
User=www-data
Group=www-data
StandardInput=socket
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=rt5
[Install]
WantedBy=multi-user.target
/etc/systemd/system/rt5.socket:
[Unit]
Description=RT5 Socket for web server
[Socket]
ListenStream=/var/run/rt5.socket
Accept=false
SocketUser=www-data
SocketGroup=www-data
SocketMode=0600
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=rt5
[Install]
WantedBy=sockets.target
Request Tracker certbot
On the requesttracker server:
apt install python3-certbot-nginx
certbot certonly -d <your.rt.domain.name> --agree-tos --nginx -m whatever@your.domain.here
Nginx Settings
/etc/nginx/rt5-cgi.conf:
fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
fastcgi_param SCRIPT_NAME "";
fastcgi_param PATH_INFO $uri;
fastcgi_param REQUEST_URI $request_uri;
fastcgi_param DOCUMENT_URI $document_uri;
fastcgi_param DOCUMENT_ROOT $document_root;
fastcgi_param SERVER_PROTOCOL $server_protocol;
fastcgi_param GATEWAY_INTERFACE CGI/1.1;
fastcgi_param SERVER_SOFTWARE nginx/$nginx_version;
fastcgi_param REMOTE_ADDR $remote_addr;
fastcgi_param REMOTE_PORT $remote_port;
fastcgi_param SERVER_ADDR $server_addr;
fastcgi_param SERVER_PORT $server_port;
fastcgi_param SERVER_NAME $server_name;
fastcgi_param REMOTE_USER $email;
systemctl enable --now rt5.service
systemctl status rt5
/etc/nginx/sites-available/rt.conf:
server {
listen 443 ssl;
ssl_certificate /etc/letsencrypt/live/<your.rt.domain.here>/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/<your.rt.domain.here>/privkey.pem;
server_name <your.rt.domain.here>;
access_log /var/log/nginx/access.<your.rt.domain.here>.log;
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
location /oauth2/ {
proxy_pass https://oauth.<your.domain.here>:4181;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Auth-Request-Redirect $request_uri;
}
location = /oauth2/auth {
proxy_pass https://oauth.<your.domain.here>:4181;
proxy_set_header Content-Length "";
proxy_pass_request_body off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Auth-Request-Redirect $request_uri;
}
location / {
auth_request /oauth2/auth;
auth_request_set $user $upstream_http_x_auth_request_user;
auth_request_set $email $upstream_http_x_auth_request_email;
add_header X-test $email always;
error_page 401 =403 /oauth2/sign_in;
client_max_body_size 100M;
include /etc/nginx/rt5-fcgi.conf;
fastcgi_pass unix:/var/run/rt5.socket;
}
location /REST/1.0/NoAuth/ {
auth_request off;
include /etc/nginx/rt5-fcgi.conf;
fastcgi_pass unix:/var/run/rt5.socket;
}
}
Configure RT5
edit RT_SiteConfig.pm
/opt/rt5/etc/RT_SiteConfig.pm:
Set($WebRemoteUserAuth, 1);
Set($WebFallbackToRTLogin,1);
Final Notes
Make sure that your users USERNAME matches the email address from Azure AD.
Make sure you assign you users to the enterprise application.
Hope this helps someone!