[rt-users] Problems with new users

[Kevin Falcone]

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.

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

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

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

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

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

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20120214/d0143b83/attachment.sig>