External user authentication (i.e. LDAP)

RT Users
1

I’m looking at the “LookupExternalUserInfo” functionality. I’d like to use
our existing Novell Directory Services, accessible via LDAP, to authenticate
people, rather than building yet another independent database of user
accounts.

2

Kendric,

You want to use LookupExternalUserInfo in combination with WebExternalAuth
and will need to set up your web server to authenticate users against your
external LDAP via such modules as Apache::AuthenLDAP.

Under such a setup, there are three ways users are created in RT:

  1. via e-mail ticket submission
  2. via manual addition via the configuration tools (GUI or command-line)
  3. via the contributed code to synchronize RT with an external LDAP
    (found under http://www.fsck.com/pub/rt/contrib/2.0/)

Regards,
Christian

Christian Gilmore
Technology Leader
GeT WW Global Applications Development
IBM Software GroupFrom: rt-users-admin@lists.fsck.com
[mailto:rt-users-admin@lists.fsck.com]On Behalf Of Beachey, Kendric
Sent: Thursday, April 11, 2002 3:58 PM
To: Rt-Users (E-mail)
Subject: [rt-users] external user authentication (i.e. LDAP)

I’m looking at the “LookupExternalUserInfo” functionality. I’d like to use
our existing Novell Directory Services, accessible via LDAP, to authenticate
people, rather than building yet another independent database of user
accounts.

From what I can tell, the LookupExternalUserInfo function will always be
called with two arguments–an email address and a “friendly” name.

Does this imply that this external authentication is only performed when RT
is chewing on an incoming email? What happens when someone who is known to
NDS but not to RT comes along and tries to login to RT’s web interface? In
such a case they would provide not their email address but their NDS login
name.

If the answer is “they won’t be able to log in until they send e-mail to
RT”, would it be a good idea to create a one-off job to generate a fake
e-mail from all our users, so that the LDAP authentication will be tickled,
thus creating a user account for every user in our system?

Kendric Beachey

rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

3

You want to use LookupExternalUserInfo in combination with
WebExternalAuth
and will need to set up your web server to authenticate users
against your
external LDAP via such modules as Apache::AuthenLDAP.

Thanks for the tips, Christian.

What I’ve ended up with (so far) is a couple of hacks that do most of what I
want. I am bouncing them off Jesse to see if I’ve done anything that’s a
really bad idea, because it was only partly similar to what I found in the
contrib area.

Briefly, though:

  1. When an unknown user sends mail to RT, hack #1 will attempt to find them
    in LDAP, and, if successful, seed the UserInfo hash with various goodies it
    finds in LDAP. This will then be used by the stock RT code to generate the
    user account.

  2. When a user logs in via the web interface, hack #2 first attempts to
    authenticate them against LDAP (in two different ways, for different
    offices). If that fails, the stock code takes over to authenticate them
    against RT’s built-in user database. If that fails too, the user sends me
    e-mail to complain. :wink: If LDAP recognizes the user but RT doesn’t, the
    user once again sends me e-mail to complain. Sometime soon we hope to run a
    one-off script to populate RT with all our users so this type of complaint
    can be minimized.

I am for the time being leaving open the option of authenticating against
RT’s database if LDAP fails, because some of our offices are not yet on our
latest and greatest LDAP. This hitch also prevents me from taking the
WebExternalAuth step, which will probably be the way to go once all the
offices are upgraded.

4

Kendric,

You want to use LookupExternalUserInfo in combination with WebExternalAuth
and will need to set up your web server to authenticate users against your
external LDAP via such modules as Apache::AuthenLDAP.

Under such a setup, there are three ways users are created in RT:

  1. via e-mail ticket submission
  2. via manual addition via the configuration tools (GUI or command-line)
  3. via the contributed code to synchronize RT with an external LDAP
    (found under http://www.fsck.com/pub/rt/contrib/2.0/)

There is another contrib up there as well that will synch existing users (I
run it from crontab)

  • It’s not hooked into the LookupExternalUserInfo in any way - but does
    get things like address info and Telno into the RT2 DB, which is nice to
    have displayed on the
    tickets…

I also put up a “Quick Ticket” our helpdesk uses - where you first search
for a email-address/username
and get that inserted as the requestor…

/JE

LDAPsyncSCA.pl.gz.url (108 Bytes)

LDAPTicket.tar.gz.url (108 Bytes)

5
  1. When a user logs in via the web interface, hack #2 first attempts
    to authenticate them against LDAP (in two different ways, for
    different offices). If that fails, the stock code takes over to
    authenticate them against RT’s built-in user database.

Wouldn’t you want to try to authenticate against RT first, not
last?

(darren)

My wife always warns me about all that cholesterol in the French
fries I eat. I just laugh at her, though, because I know with all
the salt I put on them, my blood pressure is high enough to push
through any clogged arteries.
– Dean Anderson

6
  1. When a user logs in via the web interface, hack #2 first attempts
    to authenticate them against LDAP (in two different ways, for
    different offices). If that fails, the stock code takes over to
    authenticate them against RT’s built-in user database.

Wouldn’t you want to try to authenticate against RT first, not
last?

Hmmm. If the user changes their Novell password, I want that new password
to get them into RT as well. Changing their Novell password wouldn’t affect
their RT password. The idea of changing all passwords on all systems in one
simple motion is what we’re going for here.

You might be right, though, because I think Novell regards a negative
authentication (which is what you’d have if you fell through to the RT
authentication) as one of the three strikes you get before your account is
locked on suspicion of intruder activity.

But I think the intruder lockout only lasts fifteen minutes. (shrug) I
suppose I ought to change it anyway.
Kendric

7

At 12:51 Uhr -0500 17.4.2002, Beachey, Kendric wrote:

Wouldn’t you want to try to authenticate against RT first, not
last?

Hmmm. If the user changes their Novell password, I want that new password
to get them into RT as well. Changing their Novell password wouldn’t affect
their RT password. The idea of changing all passwords on all systems in one
simple motion is what we’re going for here.

This will work as well when you authenticate against RT first - RT
authentication will fail, and the subsequent authentication against
Novell will succeed.
Thus, it’ll work the same, but with fewer negative authentications
against Novell. It might also improve performance, since querying
RT’s database is probably a lot faster than connecting to an LDAP
server.

Sebastian Flothow
sebastian@flothow.de
#include <stddisclaimer.h>