[rt-users] Problems with new users

[Scott Pestana]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20120223/624d0188/attachment.htm>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: RT_SiteConfig.pm
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20120223/624d0188/attachment.ksh>