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
--------
RT Training Sessions (http://bestpractical.com/services/training.html)
* Boston March 5 & 6, 2012
