RT::Authen::ExternalAuth and SSO via Apache authentication for RT4

Google tells me there are people interested in this question that
aren’t finding a solution, so hopefully this is useful to some of them.

I’ve been evaluating RT for the past week or so, looking at it as an
alternative to our current ticket system.

One of my requirements is Active Directory integration for our users
and helpdesk staff allowing for passwordless login/account creation
with a web browser and correct user information for RT users created via
e-mail. This is easy to accomplish for RT3 with the various overlays on
the wiki, combined with NTLM authentication for Apache. But I didn’t
want to start a new deployment on RT3 now that RT4 is out. (And I like
the layout better anyway.)

Rewriting the overlays for RT4 looks like too much work. The simplest
AD method for RT4 is using RT::Authen::ExternalAuth version 0.9’s LDAP
lookup. That works well, but it presents a problem in that users have
to enter their username/password to see their self service page.

In testing I noticed that the debug log was complaining about there not
being a user to authenticate. Since I still had Apache performing NTLM
authentication, I knew there was user information available via REMOTE_USER.

Modifying RT::Authen::ExternalAuth’s ExternalAuth.pm to take that information
from Apache turned out to be a three line edit. (1)

I am somewhat familiar with Perl, although I am not a Perl guru. I
didn’t audit anything to see if there were any issues. Right now I am
happy because “It Works For Me” and there are no obvious failures. I
did not sanitize the REMOTE_USER input because I trust winbind not to put
something crazy in there.

I do wonder about the two lines in my log (2) discussing a failure to enable
the user, followed by a successful enabling of the user.

Is this normal for RT::Authen::ExternalAuth, or did I break something?

James Zuelow
Systems Operations Manager
City and Borough of Juneau MIS
(907) 586-0236

(1)

(probably get munged by word wrap)
RT::Authen::ExternalAuth version 0.9
Modified: ExternalAuth.pm around line 85

CBJ BELOW

#if(defined($username)) {

$RT::Logger->debug(“Pass not going to be checked, attempting SSO”);

$pass_bypass = 1;

if ( defined $ENV{‘REMOTE_USER’} ) {
$username = $ENV{‘REMOTE_USER’};
$RT::Logger->debug(“Apache returned REMOTE_USER $username, attempting SSO”);
$pass_bypass = 1;

CBJ ABOVE

} else {

(2)

----8<----- snip -----8<----
[Sun Jul 17 22:07:54 2011] [warning]: Couldn’t enable user 41 (/usr/share/request-tracker4/lib/RT/User.pm:1066)
[Sun Jul 17 22:07:54 2011] [info]: User marked as ENABLED ( James_Zuelow ) per External Service (, )
-----8<----- snip -----8<-----

In testing I noticed that the debug log was complaining about there not
being a user to authenticate. Since I still had Apache performing NTLM
authentication, I knew there was user information available via REMOTE_USER.

Modifying RT::Authen::ExternalAuth’s ExternalAuth.pm to take that information
from Apache turned out to be a three line edit. (1)

The reason RT::Authen::ExternalAuth doesn’t do this is because RT itself
has the ability to authenticate using the information in REMOTE_USER.
Look at the WebExternal settings in etc/RT_Config.pm. It’ll be much
more maintainable to use RT’s built-in support rather than a hacked up
extension you have to patch every time you upgrade.

Cheers,
Thomas

I did look at the WebExternal settings in RT. Using them, RT does do authentication and log the user in. But at least in my experience over the last week it does not synchronize data from from AD. Admittedly, I am doing this as a side project in addition to my regular job, so I may have missed the “sync data with AD” tag for WebExternal.

With RT-Extension-LDAPImport, you can load users into RT from LDAP and
put it cron to keep it current.

ExternalAuth should support “info only” mode which syncs the user
details on first user create, but that’s currently TODO.

Thomas