LDAP Auth, Part Three

OK, so with the assistance of this august crew, I got my LDAP
authentication working (yayyyy).

Then I went through the Users table and started “repairing” the
autocreated users, changing “Name” to their LDAP uid so that they could
actually get to their tickets.

But now, I run into the situation where if the helpdesk staff opens a
ticket for someone, and they’ve never communicated with RT via e-mail
(to have their account autocreated based on the LDAP information), then
the account is autocreated with their e-mail address in the Name field.

Is there any equivalent to
"LokkupSenderInExternalDatabase"/“LookupExternalUserInfo” that also
gets called when a helpdesk weenie enters an e-mail address in the web
interface and RT can’t find a user for them?

D

I believe the reason RT has it’s own user database is for historical and
for referential purposes. An external database might allow users to be
deleted and RT wouldn’t know who owns/changed tickets.

Check out http://lists.fsck.com/pipermail/rt-users/2002-November/010910.html
for a way to have RT canonicalize the auto created uid. Use this only
if your external auth util prevents duplicate uid’s. Also note that the
changes indicated in the mentioned post need to be made more than once
in config.pm.

Good Luck,
Ray

Derek J. Balling wrote:

That’s for the e-mail interface, which we’ve already got covered.

The trick is that there’s no similar routines which get called for WEB
autocreated accounts.

DOn Friday, December 6, 2002, at 08:40 AM, Ray Thompson wrote:

I believe the reason RT has it’s own user database is for historical
and for referential purposes. An external database might allow users
to be deleted and RT wouldn’t know who owns/changed tickets.

Check out
http://lists.fsck.com/pipermail/rt-users/2002-November/010910.html
for a way to have RT canonicalize the auto created uid. Use this only
if your external auth util prevents duplicate uid’s. Also note that
the changes indicated in the mentioned post need to be made more than
once in config.pm.

Good Luck,
Ray

Derek J. Balling wrote:

OK, so with the assistance of this august crew, I got my LDAP
authentication working (yayyyy).
Then I went through the Users table and started “repairing” the
autocreated users, changing “Name” to their LDAP uid so that they
could actually get to their tickets.
But now, I run into the situation where if the helpdesk staff opens a
ticket for someone, and they’ve never communicated with RT via e-mail
(to have their account autocreated based on the LDAP information),
then the account is autocreated with their e-mail address in the Name
field.
Is there any equivalent to
“LokkupSenderInExternalDatabase”/“LookupExternalUserInfo” that also
gets called when a helpdesk weenie enters an e-mail address in the
web interface and RT can’t find a user for them?
D


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users
Have you read the FAQ? The RT FAQ Manager lives at
http://fsck.com/rtfm


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

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

I edited the User.pm file and the config.pm file like the example in
(of course i made changes to make it work for our site.)
http://lists.fsck.com/pipermail/rt-users/2002-May/008527.html
i then edited the autohandler file in the WebRT/html folder (See below)

I made it see if the user wasnt in the rt db then it looked in ldap if they
were there I created
a user with no pass since my LDAP authentication changes would handle
verifying the password
let me know if you have questions.
HTH
John
%# $Header: /raid/cvsroot/rt/webrt/autohandler,v 1.3 2002/05/03 05:54:02
jesse Exp $
<& /Elements/Footer, %ARGS &>
<%INIT>
$m->{‘rt_base_time’} = time;
#if it’s a noauth file, don’t ask for auth.
if ($m->base_comp->path =~ ‘^/+NoAuth/’) {
$m->call_next();
$m->abort();
}

If RT is configured for external auth, let’s get REMOTE_USER

We intentionally don’t test for REMOTE_USER to meet our policy

elsif ($RT::WebExternalAuth){
$user = $ENV{‘REMOTE_USER’};
$session{‘CurrentUser’} = RT::CurrentUser->new();
$session{‘CurrentUser’}->Load($user);
unless ($session{‘CurrentUser’}->id() ) {
delete $session{‘CurrentUser’};
$m->comp(‘/Elements/Login’, %ARGS, Error=> ‘You are not an authorized
user’);
$m->abort();
}
}

If the user is loging in, let’s authenticate

elsif (defined ($user) && defined ($pass)){
$session{‘CurrentUser’} = RT::CurrentUser->new();
$session{‘CurrentUser’}->Load($user);

  • my $Found = 1;
    unless ($session{‘CurrentUser’}->id() ) {
    delete $session{‘CurrentUser’};
  • #{{{ adding
  • the user may not be registered. create a new one for him if he is

  • in ldap.

  • $Found = 0;
  • my %Uinfo = ();
  • if ($RT::LookupSenderInExternalDatabase) {
  • my $email = "$user\@qualcomm.com";
    
  • my $name = "";
    
  • ($Found,%Uinfo) = RT::LookupExternalUserInfo($email,$name);
    
  • if ($Found) {
    
  •   my $NewUser = RT::User->new($RT::SystemUser);
    
  •   my ($Val, $Message) =
    
  •   $NewUser->Create(Name => $Uinfo{'Name'},
    
  •                               EmailAddress => $Uinfo{'EmailAddress'},
    
  •                               RealName => $Uinfo{'RealName'},
    
  •                               Password => undef,
    
  •                               Privileged => 0,
    
  •                               Comments => 'Autocreated on ticket login'
    
  •                               );
    
  •   $user = $Uinfo{'Name'};
    
  •   $email = $Uinfo{'EmailAddress'};
    
  •   unless ($Val) {
    
  •     # Deal with the race condition of two
    
  •     # account creations at once
    
  •     #
    
  •     if ($user) {
    
  •      $NewUser->LoadByName($user);
    
  •     }
    
  •     unless ($NewUser->Id) {
    
  •      $NewUser->LoadByEmail($email);
    
  •     }
    
  •     unless ($NewUser->Id) {
    
  •       my $explanation = "User creation failed in:";
    
  •       $explanation .= "Login: $Message";
    
  •       MailError( To => $RT::OwnerEmail,
    
  •                      Subject => "User could not be created",
    
  •                      Explanation => $explanation,
    
  •                      LogLevel => 'crit'
    
  •                    );
    
  •     } # unless new user id the second one
    
  •     else # user create try auth again.
    
  •     {
    
  •     } # unless new user id the second one
    
  •   } # unless Val
    
  • } #If found
    
  • } # If LookupSenderInExternalDatabase
  • #}}}
  • unless ($Found)
  • {
    $m->comp(‘/Elements/Login’, %ARGS, Error=> ‘Your username or password
    is incorrect’);
    $m->abort();
  • }
    };
  • added this to load the user since one was just made.

  • if ($Found)
  • {
  • $session{‘CurrentUser’} = RT::CurrentUser->new();
  • $session{‘CurrentUser’}->Load($user);
  • }
  • else
  • {
  • $m->comp(‘/Elements/Login’, %ARGS, Error=> ‘Your username or password
    is incorrect’);
  • $m->abort();
  • }
    unless ($session{‘CurrentUser’}->IsPassword($pass)) {
    delete $session{‘CurrentUser’};
    $m->comp(‘/Elements/Login’, Error => ‘Your username or password is
    incorrect’, %ARGS);
    $m->abort();
    }
    … (more in file i didnt edit)
    At 11:48 AM 12/6/2002, you wrote:

That’s for the e-mail interface, which we’ve already got covered.

The trick is that there’s no similar routines which get called for WEB
autocreated accounts.

D

I believe the reason RT has it’s own user database is for historical and
for referential purposes. An external database might allow users to be
deleted and RT wouldn’t know who owns/changed tickets.

Check out http://lists.fsck.com/pipermail/rt-users/2002-November/010910.html
for a way to have RT canonicalize the auto created uid. Use this only if
your external auth util prevents duplicate uid’s. Also note that the
changes indicated in the mentioned post need to be made more than once in
config.pm.

Good Luck,
Ray

Derek J. Balling wrote:

OK, so with the assistance of this august crew, I got my LDAP
authentication working (yayyyy).
Then I went through the Users table and started “repairing” the
autocreated users, changing “Name” to their LDAP uid so that they could
actually get to their tickets.
But now, I run into the situation where if the helpdesk staff opens a
ticket for someone, and they’ve never communicated with RT via e-mail
(to have their account autocreated based on the LDAP information), then
the account is autocreated with their e-mail address in the Name field.
Is there any equivalent to
“LokkupSenderInExternalDatabase”/“LookupExternalUserInfo” that also
gets called when a helpdesk weenie enters an e-mail address in the web
interface and RT can’t find a user for them?
D


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users
Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm


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

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm


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

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

<>< Proverbs 3:5 “Trust in the Lord with all your heart and lean not on
your own understanding;”

I believe the reason RT has it’s own user database is for historical
and for referential purposes. An external database might allow users
to be deleted and RT wouldn’t know who owns/changed tickets.

Check out
http://lists.fsck.com/pipermail/rt-users/2002-November/010910.html
for a way to have RT canonicalize the auto created uid. Use this only
if your external auth util prevents duplicate uid’s. Also note that
the changes indicated in the mentioned post need to be made more than
once in config.pm.

The available LDAP-aware LookupExternalUserInfo sets
$Name=$EmailAddress in different places. With RT in ‘debug’ mode, it’s
easy to find out if You changed enough of LookupExternalUserInfo to get
things going.
Our crude hack for using the LDAP uid for authentication is attached
below.

Regards,
Harald

uid.diff (2.79 KB)