<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Kevin,<br>
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:<br>
<br>
- Set($AutoCreate, {Privileged=>1});<br>
+ Set($AutoCreate, {Privileged=>0});<br>
<br>
- 'attr_match_list' => [ 'EmailAddress' ]<br>
+ 'attr_match_list' => [ 'EmailAddress',<br>
+ 'uid'
],<br>
<br>
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):<br>
<br>
#/usr/bin/perl<br>
#RT_User_Update.pl - NSP 20120222<br>
use RT;<br>
use RT::Extension::LDAPImport;<br>
Set($LDAPHost,'<a class="moz-txt-link-freetext" href="ldap://ldapserver.linguamatics.com">ldap://ldapserver.linguamatics.com</a>'); #CPAN
leaves out the $....<br>
Set($LDAPUSER,'');
# again<br>
Set($LDAPPassword,'');
# and again<br>
connect_ldap();<br>
<br>
#Mirror RT_SiteConfig.pm for the Attribute Mapping:<br>
Set($LDAPMapping, { 'Name' => 'uid', 'EmailAddress' => 'mail',
'RealName' => 'cn', <br>
'ExternalAuthId' => 'uid', 'Gecos' => 'gecos' };<br>
<br>
#Pull in the records since last time:<br>
import_users( 'import' => 1 );<br>
<br>
#Clean up<br>
disconnect_ldap();<br>
<br>
1;<br>
<br>
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?<br>
<br>
-Scott<br>
<br>
On 2/14/2012 5:44 PM, Kevin Falcone wrote:
<blockquote cite="mid:20120214224431.GV96259@jibsheet.com"
type="cite">
<pre wrap="">On Tue, Feb 14, 2012 at 04:36:19PM -0500, Scott Pestana wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> 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.
</pre>
</blockquote>
<pre wrap="">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).
</pre>
<blockquote type="cite">
<pre wrap=""> 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.
</pre>
</blockquote>
<pre wrap="">What about it makes you think he is accessing a testing queue?
It just sounds like he has no rights in the system.
</pre>
<blockquote type="cite">
<pre wrap=""> 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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap=""> 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...
</pre>
</blockquote>
<pre wrap="">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
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">--------
RT Training Sessions (<a class="moz-txt-link-freetext" href="http://bestpractical.com/services/training.html">http://bestpractical.com/services/training.html</a>)
* Boston — March 5 & 6, 2012</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
N. Scott Pestana<br>
IT Infrastructure<br>
Linguamatics<br>
275 Grove Street, Suite 2-400<br>
Newton, MA 02466<br>
<br>
Tel: +1-774-571-7135<br>
<br>
US Tel: +1-617-674-3256<br>
UK Tel: 011-44-1223-421360<br>
UK Fax: 011-44-1223-421361<br>
Web: <a class="moz-txt-link-abbreviated"
href="http://www.linguamatics.com">www.linguamatics.com</a> <br>
<br>
</div>
</body>
</html>