[rt-users] Problems with new users

[Scott Pestana]

Kevin,
     Thanks so much for your help, I've got much more out of this than 
trying to go through the eBook.  Comments inline:

On 2/14/2012 3:51 PM, Kevin Falcone wrote:
> On Tue, Feb 14, 2012 at 03:22:49PM -0500, Scott Pestana wrote:
>>         When logged in he got the RT at a glance page, with an empty queue in the upper right hand
>>     corner next to "new ticket", and all the sections (10 highest priority tickets I own, 10
>>     newest unowned tickets, bookmarked tickets, quick ticket creation, my reminders, quick search,
>>     dashboards, refresh) all load up / display normally, but without any content.
> This sounds like he is a Privileged user but that he isn't in any of
> the normal Groups where you've assigned rights.  This would prevent
> him from being able to see anything in the system.  If you add him to
> your normal user groups, the rights should be applied.
     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.

>
>>>   As a heads up, RT *always* create an internal user, even for users
>>>   pulled from LDAP.
>>         Noted, I had seen them by directly querying the SQL tables I'm just a bit confused by why
>>     they don't show up under the Privileged Users display.
> Probably because they're Unprivileged.  Try searching for them.  RT
> only lists the Privileged users.  It's quite possible to have tens or
> hundreds of thousands of Unprivileged users in a public RT instance
> and listing them out in the admin UI is rarely useful.
     Understood; I can see how this makes a lot of sense.  We'll have 
quite a few customers now that we have put our external customer RT 
instance into production.
>>   edited the user created form him to disassociate it from him
>>   (rename, re-email, etc), and then had him try to log in again.
>>   Again, RT created a user with his name/credentials in its own SQL
>>   database instead of querying LDAP, and associated his user with the
>>   now disabled queue.  He can no longer create tickets because the
>>   queue is disabled, and I can't figure out how to alter his account
>>   to associate him with the proper queue.
> I'm not sure what you mean by "the proper queue" here.  What page are
> these folks visiting to trigger a disabled Queue?  Have you set
> preferences or a configuration for an invalid Queue?
     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.  I disabled that queue in the 
hopes that after altering/removing his info from his User entry in SQL, 
when he tried to access again, a new entry in the RT SQL would be 
created for him and be associated with the only queue we have enabled.  
A new user entry popped up, but he still saw the same view into that RT 
instance.  I can't see any indication of why that RT at a glance 
connects him to the old queue, but this may be due to my inexperience 
with the plumbing of RT.

>>         Here are debug level logs of our little misadventure.  ilewin is the new employee. I'm
>>     wondering now if the users have been imported into the internal RT database by an export /
>>     import, and now new users (employees) aren't pre-loaded into the DB.  The way we're doing
> It's possible that someone in the past ran RT-Extension-LDAPImport and
> didn't add it as a cron job.

     That sounds like it could be the key to our issue.  I will look 
into that process and what we'll need to do to implement it for (both 
of) our instances.

>
>>     this, is there an option I could change to allow LDAP auth?  I heard some back and forth from
>>     the admin who set up this instance that there was so incompatibility with ExternalAuth&  LDAP
>>     auth.
> You said ExternalAuth and LDAP auth and I'm not sure I understand what
> you're doing.  Do you have some apache auth configured in addition to
> RT-Authen-ExternalAuth?
     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.

>>     [Tue Jan 24 17:49:28 2012] [debug]: Attempting to get user info using this external service:
>>     Lingua_LDAP (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.
>>     pm:458)
>>     [Tue Jan 24 17:49:28 2012] [debug]: Attempting to use this canonicalization key: EmailAddress
>>     (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:472)
>>     [Tue Jan 24 17:49:28 2012] [debug]: LDAP Search ===  Base: ou=users,dc=linguamatics,dc=com ==
>>     Filter: (&(|(objectClass=posixAccount)(objectClass=account))) == Attrs: cn,mail,uid,g
>>     ecos,uid
>>     (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm:195)
>>     [Tue Jan 24 17:49:28 2012] [info]: RT::Authen::ExternalAuth::CanonicalizeUserInfo returning
>>     Disabled: 0, EmailAddress: , Gecos: ilewin, Name: ilewin, Privileged: 1
> This implies that a user logged in and was created as a Privileged
> user, but that when ExternalAuth attempted to pull data using the
> EmailAddress, it couldn't find anyone in LDAP.

     This is what I found so confusing, there's no clear difference 
between his LDAP entry and Tracy's.

> Keep in mind that the user who has been created by logging in has no
> EmailAddress, so it's impossible to look them up in the external auth
> system.
>
> I suggest chatting with the admin who set this up to get a full list
> of how he imported users and a better description of the actual
> authentication configuration, including anything done at the apache
> level.
>
> -kevin
>

     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...


-- 
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