ExternalAuth workaround? while waiting for 0.9

Greetings all,

Has anyone that is using ExternalAuth developed a workaround for the “new
user” creation issue with ExternalAuth?

The issue was outlined in another rt-user message(I can’t seem to find
now). It relates to when non-privleged users are created through the
creation of a ticket from an email, and then they login using LDAP. The
email generates a user with username and email address as their email
address. ExternalAuth throws an error when it attempts to create the new
user, as a user already exists with the same email address.

I need ExternalAuth to find the user that has the same email address, and
change that user’s info to the info it grabs from LDAP.

If I was a perl programmer, I’d figure out how to customize it myself, but
unfortunately, I’m just stepping into that world… most perl stuff i use,
I’ve “borrowed” from the web :stuck_out_tongue:
Has anyone developed a workaround?

The only thing I can think of, is taking all LDAP users, and loading them
into RT with their info, and everytime a new user is created in LDAP, they
get created in RT… but that seems like a fair amount of work…

Thanks!

Mike Johnson
Datatel Programmer/Analyst
Northern Ontario School of Medicine
955 Oliver Road
Thunder Bay, ON P7B 5E1
Phone: (807) 766-7331
Email: mike.johnson@nosm.ca

Greetings all,

Has anyone that is using ExternalAuth developed a workaround for the “new
user” creation issue with ExternalAuth?

The issue was outlined in another rt-user message(I can’t seem to find
now). It relates to when non-privleged users are created through the
creation of a ticket from an email, and then they login using LDAP. The
email generates a user with username and email address as their email
address. ExternalAuth throws an error when it attempts to create the new
user, as a user already exists with the same email address.

I need ExternalAuth to find the user that has the same email address, and
change that user’s info to the info it grabs from LDAP.

If I was a perl programmer, I’d figure out how to customize it myself, but
unfortunately, I’m just stepping into that world… most perl stuff i use,
I’ve “borrowed” from the web :stuck_out_tongue:
Has anyone developed a workaround?

The only thing I can think of, is taking all LDAP users, and loading them
into RT with their info, and everytime a new user is created in LDAP, they
get created in RT… but that seems like a fair amount of work…

Thanks!


Mike Johnson
Datatel Programmer/Analyst
Northern Ontario School of Medicine
955 Oliver Road
Thunder Bay, ON P7B 5E1
Phone: (807) 766-7331
Email: mike.johnson@nosm.ca

Hi Mike,

We use a customized version of the CanonicalizeEmailAddress() function
which looks up the E-mail address in the LDAP directory and maps it to
their primary E-mail address before creating the account. Then it does
not conflict with the ExternalAuth process which will then pull the
same information. Here is our version which should give you some ideas:

sub CanonicalizeEmailAddress {
my $self = shift;
my $email = shift;

# Leave some addresses intact
if ( $email =~ /[\w-]+\@mysafe1.rice.edu$/ ) {
    return ($email);
}
if ( $email =~ /[\w-]+\@mysafe2.rice.edu$/ ) {
    return ($email);
}

# Example: the following rule would treat all email
# coming from a subdomain as coming from second level domain
# foo.com
if ( my $match   = RT->Config->Get('CanonicalizeEmailAddressMatch') and
     my $replace = RT->Config->Get('CanonicalizeEmailAddressReplace') )
{
    $email =~ s/$match/$replace/gi;
}
$email .= '@rice.edu' if ($email =~ /^[\w-]+$/);

# Now we should have an Email address that is of the form addr@rice.edu
# Use LDAP to map this to the primary vanity Email alias.

my $params = ( Name => undef,
               EmailAddress => undef);

my $ldap = new Net::LDAP($RT::LdapServer)
  or $RT::Logger->critical("CanonicalizeEmailAddress: Cannot connect to LDAP\n"),
    return ($email);

my $mesg = $ldap->bind();

if ($mesg->code != LDAP_SUCCESS) {
  $RT::Logger->critical("CanonicalizeEmailAddress: Unable to bind to $RT::LdapServer: ",
    ldap_error_name($mesg->code), "\n");

  return ($email);
}

# First check to see if the E-mail address uniquely characterizes the
# user. If so, update the information with the LDAP query results.
my $filter = "(mailAlternateAddress=$email)";
$mesg = $ldap->search(base   => $RT::LdapBase,
                      filter => $filter,
                      attrs  => [ $RT::LdapMailAttr ]);

if ($mesg->code != LDAP_SUCCESS and $mesg->code != LDAP_PARTIAL_RESULTS)  {
  $RT::Logger->critical("Unable to search in LDAP: ", ldap_error_name($mesg->code), "\n");

  return ($email);
}

# The search succeeded with just one match
if ($mesg->count == 1) {
  $email = ($mesg->first_entry->get_value($RT::LdapMailAttr))[0];
}

$mesg = $ldap->unbind();
if ($mesg->code != LDAP_SUCCESS) {
  $RT::Logger->critical("Could not unbind from LDAP: ", ldap_error_name($mesg->code), "\n");

}
undef $ldap;
undef $mesg;
return ($email);

}

You will also need these somewhere ahead of there use:

use Net::LDAP;
use Net::LDAP::Constant qw(LDAP_SUCCESS LDAP_PARTIAL_RESULTS);
use Net::LDAP::Util qw (ldap_error_name);
use Net::LDAP::Filter;

We have them at the top under “use strict”.

Cheers,
Ken

Would this also ensure that when LDAP finds the matching email in RT’s
users, it’ll update the other info to what LDAP has?(essentially overwriting
the email address as username that was set when a non-user emails RT)

The function looks up the E-mail address in the LDAP directory
and if it is found looks up the corresponding primary E-mail
address and uses that instead. Then the rest of the ExternAuth
piece populates the other information for the user from the
directory using that E-mail address.

Cheers,
Ken

Every E-mail address passes through this function first. This
is why the clean-up/fix-up works.

KenOn Tue, Aug 03, 2010 at 11:15:50AM -0400, Mike Johnson wrote:

Ah, so this is called everytime a new user emails the system? (sorry, still
learning how RT even works :stuck_out_tongue: never mind how it’s coded hehe)

On Tue, Aug 3, 2010 at 11:08 AM, Kenneth Marshall ktm@rice.edu wrote:

On Tue, Aug 03, 2010 at 10:59:15AM -0400, Mike Johnson wrote:

Would this also ensure that when LDAP finds the matching email in RT’s
users, it’ll update the other info to what LDAP has?(essentially
overwriting
the email address as username that was set when a non-user emails RT)

The function looks up the E-mail address in the LDAP directory
and if it is found looks up the corresponding primary E-mail
address and uses that instead. Then the rest of the ExternAuth
piece populates the other information for the user from the
directory using that E-mail address.

Cheers,
Ken


Mike Johnson
Datatel Programmer/Analyst
Northern Ontario School of Medicine
955 Oliver Road
Thunder Bay, ON P7B 5E1
Phone: (807) 766-7331
Email: mike.johnson@nosm.ca

Would this also ensure that when LDAP finds the matching email in RT’s
users, it’ll update the other info to what LDAP has?(essentially overwriting
the email address as username that was set when a non-user emails RT)On Thu, Jul 29, 2010 at 9:46 AM, Kenneth Marshall ktm@rice.edu wrote:

On Thu, Jul 29, 2010 at 09:36:33AM -0400, Mike Johnson wrote:

Greetings all,

Has anyone that is using ExternalAuth developed a workaround for the “new
user” creation issue with ExternalAuth?

The issue was outlined in another rt-user message(I can’t seem to find
now). It relates to when non-privleged users are created through the
creation of a ticket from an email, and then they login using LDAP. The
email generates a user with username and email address as their email
address. ExternalAuth throws an error when it attempts to create the new
user, as a user already exists with the same email address.

I need ExternalAuth to find the user that has the same email address, and
change that user’s info to the info it grabs from LDAP.

If I was a perl programmer, I’d figure out how to customize it myself,
but
unfortunately, I’m just stepping into that world… most perl stuff i
use,
I’ve “borrowed” from the web :stuck_out_tongue:
Has anyone developed a workaround?

The only thing I can think of, is taking all LDAP users, and loading them
into RT with their info, and everytime a new user is created in LDAP,
they
get created in RT… but that seems like a fair amount of work…

Thanks!


Mike Johnson
Datatel Programmer/Analyst
Northern Ontario School of Medicine
955 Oliver Road
Thunder Bay, ON P7B 5E1
Phone: (807) 766-7331
Email: mike.johnson@nosm.ca

Hi Mike,

We use a customized version of the CanonicalizeEmailAddress() function
which looks up the E-mail address in the LDAP directory and maps it to
their primary E-mail address before creating the account. Then it does
not conflict with the ExternalAuth process which will then pull the
same information. Here is our version which should give you some ideas:

sub CanonicalizeEmailAddress {
my $self = shift;
my $email = shift;

Leave some addresses intact

if ( $email =~ /[\w-]+@mysafe1.rice.edu$/ ) {
return ($email);
}
if ( $email =~ /[\w-]+@mysafe2.rice.edu$/ ) {
return ($email);
}

Example: the following rule would treat all email

coming from a subdomain as coming from second level domain

foo.com

if ( my $match = RT->Config->Get(‘CanonicalizeEmailAddressMatch’) and
my $replace = RT->Config->Get(‘CanonicalizeEmailAddressReplace’) )
{
$email =~ s/$match/$replace/gi;
}
$email .= ‘@rice.edu’ if ($email =~ /^[\w-]+$/);

Now we should have an Email address that is of the form addr@rice.edu

Use LDAP to map this to the primary vanity Email alias.

my $params = ( Name => undef,
EmailAddress => undef);

my $ldap = new Net::LDAP($RT::LdapServer)
or $RT::Logger->critical(“CanonicalizeEmailAddress: Cannot connect to
LDAP\n”),
return ($email);

my $mesg = $ldap->bind();

if ($mesg->code != LDAP_SUCCESS) {
$RT::Logger->critical("CanonicalizeEmailAddress: Unable to bind to
$RT::LdapServer: ",
ldap_error_name($mesg->code), “\n”);

 return ($email);

}

First check to see if the E-mail address uniquely characterizes the

user. If so, update the information with the LDAP query results.

my $filter = “(mailAlternateAddress=$email)”;
$mesg = $ldap->search(base => $RT::LdapBase,
filter => $filter,
attrs => [ $RT::LdapMailAttr ]);

if ($mesg->code != LDAP_SUCCESS and $mesg->code != LDAP_PARTIAL_RESULTS)
{
$RT::Logger->critical("Unable to search in LDAP: ",
ldap_error_name($mesg->code), “\n”);

 return ($email);

}

The search succeeded with just one match

if ($mesg->count == 1) {
$email = ($mesg->first_entry->get_value($RT::LdapMailAttr))[0];
}

$mesg = $ldap->unbind();
if ($mesg->code != LDAP_SUCCESS) {
$RT::Logger->critical("Could not unbind from LDAP: ",
ldap_error_name($mesg->code), “\n”);

}
undef $ldap;
undef $mesg;
return ($email);
}

You will also need these somewhere ahead of there use:

use Net::LDAP;
use Net::LDAP::Constant qw(LDAP_SUCCESS LDAP_PARTIAL_RESULTS);
use Net::LDAP::Util qw (ldap_error_name);
use Net::LDAP::Filter;

We have them at the top under “use strict”.

Cheers,
Ken

Mike Johnson
Datatel Programmer/Analyst
Northern Ontario School of Medicine
955 Oliver Road
Thunder Bay, ON P7B 5E1
Phone: (807) 766-7331
Email: mike.johnson@nosm.ca

Ah, so this is called everytime a new user emails the system? (sorry, still
learning how RT even works :stuck_out_tongue: never mind how it’s coded hehe)On Tue, Aug 3, 2010 at 11:08 AM, Kenneth Marshall ktm@rice.edu wrote:

On Tue, Aug 03, 2010 at 10:59:15AM -0400, Mike Johnson wrote:

Would this also ensure that when LDAP finds the matching email in RT’s
users, it’ll update the other info to what LDAP has?(essentially
overwriting
the email address as username that was set when a non-user emails RT)

The function looks up the E-mail address in the LDAP directory
and if it is found looks up the corresponding primary E-mail
address and uses that instead. Then the rest of the ExternAuth
piece populates the other information for the user from the
directory using that E-mail address.

Cheers,
Ken

Mike Johnson
Datatel Programmer/Analyst
Northern Ontario School of Medicine
955 Oliver Road
Thunder Bay, ON P7B 5E1
Phone: (807) 766-7331
Email: mike.johnson@nosm.ca