VM,
Are you successful in your effort? <<
Not yet. It may be awhile as I have my fingers in a few pies besides
RT.
what is the difference in user creation when RT is integrated with
AD? <<
I’m not sure yet. I’m still trying to understand how RT works. Right
now, logged in as root, I can’t even manually create a user in RT at
all, let alone have a user automatically imported from Active Directory.
Once I’ve figured out how to create a user manually, then I’ll learn how
to make RT and AD do it for me.
What I’m trying to avoid, of course, is having to manually administer
the creation of users and the assignment of rights to each user.
Instead, I want RT to Import the user accounts from Active Directory,
rather than for me as the administrator to have to create hundreds of
user accounts in RT (either up front, or as people request access), each
matching an account we already have in our Active Directory datastore.
As for rights, it looks like I can assign rights to users by inheritance
through roles (eg. Requestor) and groups. From what I’m reading in the
user manual it looks like it can be done this way. If I’m successful, I
should have a set of configuration files that can be posted to the list
to help others accomplish the same thing. We’ll see.
Best regards,
Gene EvansFrom: testwreq wreq [mailto:testwreq@gmail.com]
Sent: Friday, August 06, 2010 2:58 PM
To: Eugene M. Evans
Subject: Re: [rt-users] RT 3.8 Active Directory integration and single
sign-on
Hello Gene,
I am looking to accomplish the similar thing. Are you successful in your
effort?
Question:
You want to integrate RT with Active Directory such that an RT user
account will automatically be created when a user first submits a ticket
request via email. RT does this without integration. So, then what is
the difference in user creation when RT is integrated with AD?
Regards, vm
Mike,
Thankyou for the reply. Looks like I'll need to dive a bit
deeper than
I first anticipated. I’ll post my results.
Sincerely,
Gene Evans
IT Administrator
Heapy Engineering
937-224-0861 x1404
From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of
rt-users-request@lists.bestpractical.com
Sent: Thursday, August 05, 2010 8:49 AM
To: rt-users@lists.bestpractical.com
Subject: RT-Users Digest, Vol 77, Issue 20
Send RT-Users mailing list submissions to
rt-users@lists.bestpractical.com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
or, via email, send a message with subject or body ‘help’ to
rt-users-request@lists.bestpractical.com
You can reach the person managing the list at
rt-users-owner@lists.bestpractical.com
When replying, please edit your Subject line so it is more
specific than
“Re: Contents of RT-Users digest…”
Today's Topics:
1. RT 3.8 Active Directory integration and single sign-on
(Eugene M. Evans)
2. Re: RT 3.8 Active Directory integration and single
sign-on
(Mike Johnson)
Message: 1
Date: Wed, 4 Aug 2010 22:58:07 -0400
From: "Eugene M. Evans" <EMEvans@heapy.com>
To: <rt-users@lists.bestpractical.com>
Subject: [rt-users] RT 3.8 Active Directory integration and
single
sign-on
Message-ID:
BFA145AA31FEBC449D510ADC62FF513E14A6D5@dayxchng0.heapy.local
Content-Type: text/plain; charset=“us-ascii”
I am trying to accomplish two things:
First, to integrate RT with Active Directory such that an RT
user
account will automatically be created in either of the following
cases.
a) when a user first submits a ticket request via email, and
b) when a user first logs in via the RT web interface
Secondly, Single sign-on, such that once an RT account has been
created
an MS-Windows user will not need to enter their password on
subsequent
visits to the RT web interface.
I've started by attempting to implement the Auth::ExternalAuth
extension
but have been unable to get it working. I cannot log into the
RT web
interface using any account except the root account that has
already
been created within RT. Once in RT as root, I am unable to
create a new
user. I get the error “User could not be created: Could not
set user
info.”
I've tried the solution mentioned in this thread -->
http://www.gossamer-threads.com/lists/rt/users/94218 to get RT
to
auto-create users, but to no avail.
Note that when I uncomment the statement
“Set($WebExternalAuto,1);” and
restart apache the RT login screen provides no login box in
which to
enter a username or a password.
Any advice would be greatly appreciated.
Below is my RT configuration.
#Begin /opt/rt3/etc/RT_SiteConfig.pm tail ...
# The following two statements support single sign-on.
# but I have commented them out for now since they are # said to
conflict with the ExternalAuth extension.
# See http://wiki.bestpractical.com/view/ExternalAuth
<http://wiki.bestpractical.com/view/ExternalAuth> .
# Tell RT to trust the webserver to handle authentication.
# Set($WebExternalAuth, 3);
# If the webserver hands RT a user RT is not # familiar with, RT
should
just go ahead and # create an account.
# Set($WebExternalAuto, 1);
...
# Include the configuration for the ExternalAuth extension.
require
“/opt/rt3/local/plugins/RT-Authen-ExternalAuth/etc/RT_SiteConfig.pm”;
Set($AutoCreate,{Privileged => 0});
1;
#End /opt/rt3/etc/RT_SiteConfig.pm
#Begin
/opt/rt3/local/plugins/RT-Authen-ExternalAuth/etc/RT_SiteConfig.pm in
its entirety.
Set($ExternalAuthPriority, [ 'Heapy_AD_LDAP' ] );
Set($ExternalInfoPriority, [ 'Heapy_AD_LDAP' ] );
Set($ExternalServiceUsesSSLorTLS, 0);
Set($AutoCreateNonExternalUsers, 0);
Set($ExternalSettings, {
'Heapy_AD_LDAP' => {
'type' => 'ldap',
'server' =>
'serverxyz.domain.domainSuffix',
'user' =>
'cn=ldap,ou=Services,dc=domain,dc=domainSuffix',
'pass' =>
‘the_ldap_password’,
‘base’ =>
‘dc=domain,dc=domainSuffix’,
'filter' =>
'(&(ObjectCategory=User)(ObjectClass=Person))',
'd_filter' =>
'(userAccountControl:1.2.840.113556.1.4.803:=2)',
# 'tls' => 0,
# 'ssl_version' => 3,
'net_ldap_args' => [ version =>
3
],
‘group’ =>
‘cn=group,ou=Services,dc=domain,dc=domainSuffix’,
‘group_attr’ => ‘member’,
'attr_match_list' => [ 'Name',
'EmailAddress' ],
'attr_map' => { 'Name' =>
'sAMAccountName',
‘EmailAddress’ =>
‘mail’,
‘Organization’ =>
‘physicalDeliveryOfficeName’,
‘RealName’ =>
‘cn’,
‘ExternalAuthId’ =>
‘sAMAccountName’,
‘Gecos’ =>
‘sAMAccountName’,
‘WorkPhone’
=>
‘telephoneNumber’,
‘Address1’ =>
‘streetAddress’,
‘City’ =>
‘l’,
‘State’ =>
‘st’,
‘Zip’ =>
‘postalCode’,
‘Country’ =>
‘co’
}
}
}
);
Set(@Plugins, qw(RT::Authen::ExternalAuth)); 1; #End
/opt/rt3/local/plugins/RT-Authen-ExternalAuth/etc/RT_SiteConfig.pm
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.bestpractical.com/pipermail/rt-users/attachments/20100804/
223f6f34/attachment-0001.html
<http://lists.bestpractical.com/pipermail/rt-users/attachments/20100804/
223f6f34/attachment-0001.html> >
Message: 2
Date: Thu, 5 Aug 2010 08:51:28 -0400
From: Mike Johnson <mike.johnson@nosm.ca>
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] RT 3.8 Active Directory integration and
single
sign-on
Message-ID:
AANLkTin4a4uuw-Q_wb4FXi9YDnATSN2OvyiuadodueU-@mail.gmail.com
Content-Type: text/plain; charset=“iso-8859-1”
b) should be done easily using ExternalAuth. when I say easily,
I mean,
as soon as you get ExternalAuth working, b is done… but it
did take
me almost a week to figure out my issues(a spelling mistake in
the
config file
:'()
a) sounds like you want ExternalAuth with AutoCreate
Privleged=>0 set,
but you’d also need to tweak the RT system.
The problem with just doing the above, if someone has already
sent an
email to your system prior to attempting to login, their email
address
generates a user in RT. That user has username = email address,
as well
as email address filled out too. Then when they go to login,
ExternalAuth pulls the user’s email address from LDAP and
attempts to
create the user with that email address, however that email
address
already exists on the autocreated user from the email they sent
in… so
the create user fails.
Ken Marshall shared something on the listserv of a way to fix
this, but
I haven’t got it working yet(I’m new to perl, still learning)
He edited the spot in RT that runs everytime an email address is
found.
>From reading the code, I believe his changes makes the
CanonicalizeEmailAddress subroutine connect to your LDAP and
pull the
LDAP info in (as defined in ExternalAuth’s config) instead of
just
creating a user using the email address alone.
What I mean is, RT out of the box, when an email comes in, the
unedited
CanonicalizeEmailAddress sub does pretty much nothing but a word
substitution(based on a config file setting), but Ken’s version
actually
connects to LDAP and pulls the real name, the username, etc.
The way Ken explained it to me, it should not only fix old
accounts that
already exist, but ensure all new accounts work correctly as
well.
Below is the code, also search the listserv for my post about
workarounds while waiting for ExternalAuth 0.09.
Good luck!
Mike
***Ken's code below***
sub CanonicalizeEmailAddress {
my $self = shift;
my $email = shift;
# Leave some addresses intact
if ( $email =~ /[\w-]+\@mysafe1.rice.edu
http://mysafe1.rice.edu/ $/ ) {
return ($email);
}
if ( $email =~ /[\w-]+@mysafe2.rice.edu
http://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 http://foo.com/
if ( my $match =
RT->Config->Get(‘CanonicalizeEmailAddressMatch’)
and
my $replace =
RT->Config->Get(‘CanonicalizeEmailAddressReplace’)
)
{
$email =~ s/$match/$replace/gi;
}
$email .= '@rice.edu http://rice.edu/ ’ if ($email =~
/+$/);
# 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”.
> I am trying to accomplish two things:
>
> First, to integrate RT with Active Directory such that an RT
user
> account will automatically be created in either of the
following
cases.
> a) when a user first submits a ticket request via email,
and
> b) when a user first logs in via the RT web interface
>
> Secondly, Single sign-on, such that once an RT account has
been
> created an MS-Windows user will not need to enter their
password on
> subsequent visits to the RT web interface.
>
> I’ve started by attempting to implement the Auth::ExternalAuth
> extension but have been unable to get it working. I cannot
log into
> the RT web interface using any account except the root account
that
> has already been created within RT. Once in RT as root, I am
unable
> to create a new user. I get the error “User could not be
created:
Could not set user info.”
>
> I’ve tried the solution mentioned in this thread →
> Carbon60: Managed Cloud Services to get RT
to
> auto-create users, but to no avail.
> Note that when I uncomment the statement
“Set($WebExternalAuto,1);”
> and restart apache the RT login screen provides no login box
in which
> to enter a username or a password.
>
> Any advice would be greatly appreciated.
>
> Below is my RT configuration.
>
>
> #Begin /opt/rt3/etc/RT_SiteConfig.pm tail …
> # The following two statements support single sign-on.
> # but I have commented them out for now since they are # said
to
> conflict with the ExternalAuth extension.
> # See ExternalAuth - Request Tracker Wiki.
>
> # Tell RT to trust the webserver to handle authentication.
> # Set($WebExternalAuth, 3);
> # If the webserver hands RT a user RT is not # familiar with,
RT
> should just go ahead and # create an account.
> # Set($WebExternalAuto, 1);
>
> …
> # Include the configuration for the ExternalAuth extension.
> require
>
“/opt/rt3/local/plugins/RT-Authen-ExternalAuth/etc/RT_SiteConfig.pm”;
> Set($AutoCreate,{Privileged => 0});
>
> 1;
> #End /opt/rt3/etc/RT_SiteConfig.pm
>
>
>
>
> #Begin
>
/opt/rt3/local/plugins/RT-Authen-ExternalAuth/etc/RT_SiteConfig.pm
> in its entirety.
>
> Set($ExternalAuthPriority, [ ‘Heapy_AD_LDAP’ ] );
> Set($ExternalInfoPriority, [ ‘Heapy_AD_LDAP’ ] );
> Set($ExternalServiceUsesSSLorTLS, 0);
> Set($AutoCreateNonExternalUsers, 0);
>
> Set($ExternalSettings, {
> ‘Heapy_AD_LDAP’ => {
>
> ‘type’ => ‘ldap’,
> ‘server’ =>
> ‘serverxyz.domain.domainSuffix’,
> ‘user’ =>
‘cn=ldap,ou=Services,dc=
> domain,dc=domainSuffix’,
> ‘pass’ =>
‘the_ldap_password’,
> ‘base’ =>
‘dc=domain,dc=
> domainSuffix’,
>
> ‘filter’ =>
> ‘(&(ObjectCategory=User)(ObjectClass=Person))’,
> ‘d_filter’ =>
> ‘(userAccountControl:1.2.840.113556.1.4.803:=2)’,
>
> # ‘tls’ => 0,
> # ‘ssl_version’ => 3,
>
> ‘net_ldap_args’ => [ version
=>
> 3 ],
> ‘group’ =>
‘cn=group,ou=Services,dc=
> domain,dc=domainSuffix’,
> ‘group_attr’ => ‘member’,
>
> ‘attr_match_list’ => [ ‘Name’,
> ‘EmailAddress’ ],
> ‘attr_map’ => { ‘Name’ =>
> ‘sAMAccountName’,
>
‘EmailAddress’ =>
> ‘mail’,
>
‘Organization’ =>
> ‘physicalDeliveryOfficeName’,
> ‘RealName’
=>
‘cn’,
>
‘ExternalAuthId’
> => ‘sAMAccountName’,
> ‘Gecos’ =>
> ‘sAMAccountName’,
>
‘WorkPhone’ =>
> ‘telephoneNumber’,
> ‘Address1’
=>
> ‘streetAddress’,
> ‘City’ =>
‘l’,
> ‘State’ =>
‘st’,
> ‘Zip’ =>
‘postalCode’,
> ‘Country’
=> ‘co’
> }
> }
> }
> );
>
> Set(@Plugins, qw(RT::Authen::ExternalAuth)); 1; #End
>
/opt/rt3/local/plugins/RT-Authen-ExternalAuth/etc/RT_SiteConfig.pm
>
>
>
>
>
>
> Discover RT’s hidden secrets with RT Essentials from O’Reilly
Media.
> Buy a copy at http://rtbook.bestpractical.com
http://rtbook.bestpractical.com/
>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.bestpractical.com/pipermail/rt-users/attachments/20100805/
193b2e31/attachment.html
<http://lists.bestpractical.com/pipermail/rt-users/attachments/20100805/
193b2e31/attachment.html> >
RT-Users mailing list
RT-Users@lists.bestpractical.com
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
End of RT-Users Digest, Vol 77, Issue 20
Discover RT's hidden secrets with RT Essentials from O'Reilly
Media.
Buy a copy at http://rtbook.bestpractical.com
http://rtbook.bestpractical.com/
