Kevin,
We're setting up a new development RT server to try to pick apart
our issues (and also as a staging platform for RT upgrades). In that
spirit I thought I'd ask you to look over the RT_SiteConfig.pm I've set
up based on our existing instances (don't worry its short, and
attached). After our conversations, I think I want to make these changes:
- Set($AutoCreate, {Privileged=>1});
+ Set($AutoCreate, {Privileged=>0});
- 'attr_match_list' => [ 'EmailAddress' ]
+ 'attr_match_list' => [ 'EmailAddress',
+ 'uid' ],
Then I will want to install from CPAN RT::Extension::LDAPImport.pm
(hm, that author's name seems familiar...) and then set up a
RT_User_Update.pl script that will look something like this (based on
the CPAN documentation):
#/usr/bin/perl
#RT_User_Update.pl - NSP 20120222
use RT;
use RT::Extension::LDAPImport;
Set($LDAPHost,'ldap://ldapserver.linguamatics.com'); #CPAN leaves
out the $....
Set($LDAPUSER,'');
# again
Set($LDAPPassword,'');
# and again
connect_ldap();
#Mirror RT_SiteConfig.pm for the Attribute Mapping:
Set($LDAPMapping, { 'Name' => 'uid', 'EmailAddress' => 'mail',
'RealName' => 'cn',
'ExternalAuthId' => 'uid', 'Gecos' => 'gecos' };
#Pull in the records since last time:
import_users( 'import' => 1 );
#Clean up
disconnect_ldap();
1;
And then we'll run that perl script on our RT server (owlwoman,
etc) whenever new employees come on board (and have been entered into
LDAP). Does this make sense?
-Scott
On 2/14/2012 5:44 PM, Kevin Falcone wrote:
On Tue, Feb 14, 2012 at 04:36:19PM -0500, Scott Pestana wrote:
That's correct, we don't want him to have special privileges;
other than the ability to see status of tickets that he
opened/requested. Oddly enough we have another employee who started
at roughly the same time as Ian, and Tracy doesn't have this issue,
nor does she have an un-privileged Privileged User. When she logs
in she gets a view similar to mine (I'm on IT Support, have
privileges, and haven't had an issue). At least that's what my
memory tells me. I'm going to check on this tomorrow to see what
her experience as a user is, I could be wildly wrong about this.
This sounds like you may want this user to just be Unprivileged and
use the SelfService interface. You'll still need to hand out some
rights so that Requestors can see their own tickets, etc.
However, you can go compare this user and Tracy's group memberships
from the Memberships tab on their user page and I suspect Tracy will
be in groups and Ian isn't or that Tracy has tickets requested but Ian
doesn't. Also, if Ian's user record had no Email Address then RT has
no way to associate his tickets with the logged in user (See my later
comment about how RT can't know the user's email address).
When he logs in and goes to the "RT at a glance" page (
rt/index.html ), his view (to me) implies he's associated with a
queue that was originally set up for testing.
What about it makes you think he is accessing a testing queue?
It just sounds like he has no rights in the system.
I'm not sure I understand it either. ;) We are using a rather
complex set up with apache spread across multiple servers performing
different roles, all united by SSO on the apache instance acting as
a gateway. The credentials are (I believe) passed through so an
employee only needs to authenticate once for all of our internal
resources. We are also getting closer to using Kerberos/Domain
authentication for seamless SSO for our windows users.
That makes more sense, you're authing with SSO and trying to pull
information from LDAP. However, your LDAP is keyed to look up on
email address and when someone logs in via the web UI, there's no way
to have their email address (think about it, RT only gets the username
they logged in with, not their email address which is stored in LDAP).
Often, ExternalAuth is keyed to look up on Username *and*
EmailAddress, but yours is configured for just EmailAddress.
Based on this I think our issues stem from him logging in via
the web before opening a ticket via email. Funnily enough when he
emailed IT support for help with something around the office, the RT
system worked like a charm. I'm starting to think I may be
over-thinking this entire situation...
This also supports my above comment, since someone emailing into your
system *would* be able to find their LDAP account, because RT has
their email account.
It sounds like many of these problems could be solved with
RT-Extension-LDAPImport pulling users into the system so they'll exist
before sending email or logging into the system.
-kevin
--------
RT Training Sessions (http://bestpractical.com/services/training.html)
* Boston --- March 5& 6, 2012
--
N. Scott Pestana
IT Infrastructure
Linguamatics
275 Grove Street, Suite 2-400
Newton, MA 02466
Tel: +1-774-571-7135
US Tel: +1-617-674-3256
UK Tel: 011-44-1223-421360
UK Fax: 011-44-1223-421361
Web: www.linguamatics.com
# Any configuration directives you include here will override
# RT's default configuration file, RT_Config.pm
#
# To include a directive here, just copy the equivalent statement
# from RT_Config.pm and change the value. We've included a single
# sample value below.
#
# This file is actually a perl module, so you can include valid
# perl code, as well.
#
# The converse is also true, if this file isn't valid perl, you're
# going to run into trouble. To check your SiteConfig file, use
# this comamnd:
#
# perl -c /path/to/your/etc/RT_SiteConfig.pm
#
# You must restart your webserver after making changes to this file.
Set( $rtname, 'Linguamatics Dev');
# You must install Plugins on your own, this is only an example
# of the correct syntax to use when activating them.
# There should only be one @Plugins declaration in your config file.
#Set(@Plugins,(qw(RT::Extension::QuickDelete RT::Extension::CommandByMail)));
Set(@Plugins, qw(RT::Authen::ExternalAuth));
Set($rtname, 'Linguamatics');
Set($Organization, 'linguamatics.com');
Set($DatabaseUser, '######################');
Set($DatabasePassword, '######################');
Set($DatabaseName, '######################');
Set($DatabaseHost, "db.linguamatics.com");
Set($DatabaseRTHost, "db.linguamatics.com");
# GRANT ALL PRIVILEGES ON rt_dev.* TO 'rt_devuser'@'owlwoman.linguamatics.com'
IDENTIFIED BY 'rt_d3vus3r';
#Set(%FullTextSearch, Enable => 1, Indexed => 0, );
Set( %FullTextSearch,
Enable => 1,
Indexed => 1,
Table => 'AttachmentsIndex',
MaxMatches => '10000',
);
Set( $CanonicalizeEmailAddressMatch, '@owlwoman\.linguamatics\.com$' );
Set( $CanonicalizeEmailAddressReplace, '@linguamatics.com ');
#Set($RTAddressRegexp,qr{^(?:(?:rt_dev(?:|-comment)|testsupport(?:|-comment))\@(owlwoman\.)?linguamatics\.com)$}i);
Set($RTAddressRegexp,qr{^(?:rt-dev(?:|-comment)\@(?:owlwoman\.)?linguamatics\.com)$}i);
Set($OwnerEmail , '[email protected]');
Set($CorrespondAddress, '[email protected]');
Set($CommentAddress, '[email protected]');
Set($Timezone, 'Europe/London');
Set($UseFriendlyToLine, 1);
Set($FriendlyFromLineFormat, "\"%s\" <%s>");
Set($WebPath, '/local/rt-dev');
Set($WebDomain, 'owlwoman.linguamatics.com');
Set($WebBaseURL, 'https://secure.linguamatics.com');
Set($CanonicalizeRedirectURLs, 1);
Set($ParseNewMessageForTicketCcs, 1);
Set($WebExternalAuth, 1);
Set($WebExternalAuto, 1);
Set($AutoCreate, {Privileged=>1});
Set($ExternalAuthPriority, ['Lingua_LDAP']);
Set($ExternalInfoPriority, ['Lingua_LDAP']);
Set($ExternalServiceUsesSSLorTLS, 0);
Set($AutoCreateNonExternalUsers, 1);
Set($ExternalSettings, {
'Lingua_LDAP' => {
'type' => 'ldap',
'server' => 'ldapserver.linguamatics.com',
'base' => 'ou=users,dc=linguamatics,dc=com',
'filter' =>
'(|(objectClass=posixAccount)(objectClass=account))',
'tls' => 0,
'net_ldap_args' => [ version => 3 ],
'attr_match_list' => [ 'EmailAddress' ],
'attr_map' => { 'Name' => 'uid',
'EmailAddress' => 'mail',
'RealName' => 'cn',
'ExternalAuthId' => 'uid',
'Gecos' => 'gecos'
}
# 'group' => 'cn=staff,ou=Groups,dc=linguamatics,dc=com',
# 'group_attr' => 'memberUid',
# 'ssl_version' => 3,
# 'd_filter' => '(employeeType=other)'
}
});
=item C<$LogToFile>, C<$LogDir>, C<$LogToFileNamed>
Logging to a standalone file is also possible. The file needs to both
exist and be writable by all direct users of the RT API.
=cut
Set($LogToFile, debug);
Set($LogDir, q{var/log});
Set($LogToFileNamed, "rt.log"); #log to rt.log
1;
--------
RT Training Sessions (http://bestpractical.com/services/training.html)
* Boston March 5 & 6, 2012
