Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Request Tracker: Users

Problems with new users

 

 

Request Tracker users RSS feed   Index | Next | Previous | View Threaded


scott.pestana at linguamatics

Feb 10, 2012, 12:45 PM

Post #1 of 14 (1373 views)
Permalink
Problems with new users

Hello RT Users,
To preface, I've got several years experience and training with the
Linux platform and PERL, but I'm completely new to RT; I've done a few
web searches and a three or four different google searches of the email
archive and can't find any insight into our problem.

We're having a strange problem with our users in our two RT
instances, that we think are related. When our internal IT Support
instance of RT was created everything was working well for some time,
and we currently have RT configured to work with our LDAP database for
users and their credentials. However, new users (new employees) trying
to use RT are not able to get the same functionality.

For example: one user can send in emails to the RT queue and
proceed normally. However if he tries to log in to the web version, the
RT system treats him like is associated with a different queue than the
rest of our users. When he tried to create a ticket through the web RT
would create the ticket in this wrong queue, and he immediately got an
error that he did not have permissions to view his ticket.
RT creates an internal user for him, unlike the rest of our
employees who don't show up in the user list because they exist in the
configured LDAP. I disabled the (discontinued) queue, and 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.

Can anyone help me with this first problem?

--
N. Scott Pestana
IT Infrastructure
Linguamatics

--------
RT Training Sessions (http://bestpractical.com/services/training.html)
* Boston March 5 & 6, 2012


kenn.crocker at gmail

Feb 10, 2012, 3:07 PM

Post #2 of 14 (1321 views)
Permalink
Re: Problems with new users [In reply to]

Scott,

I can, but it would be helpful to know how uyou have set up your
privileges, both Globally and by Queue. Also, in order for LDAP info to get
into a User, they must have the "ModifySelf" right applied. OVerall, I
think this is all a privileges problem.

Kenn

On Fri, Feb 10, 2012 at 12:45 PM, Scott Pestana <
scott.pestana [at] linguamatics> wrote:

> Hello RT Users,
> To preface, I've got several years experience and training with the
> Linux platform and PERL, but I'm completely new to RT; I've done a few web
> searches and a three or four different google searches of the email archive
> and can't find any insight into our problem.
>
> We're having a strange problem with our users in our two RT instances,
> that we think are related. When our internal IT Support instance of RT was
> created everything was working well for some time, and we currently have RT
> configured to work with our LDAP database for users and their credentials.
> However, new users (new employees) trying to use RT are not able to get
> the same functionality.
>
> For example: one user can send in emails to the RT queue and proceed
> normally. However if he tries to log in to the web version, the RT system
> treats him like is associated with a different queue than the rest of our
> users. When he tried to create a ticket through the web RT would create
> the ticket in this wrong queue, and he immediately got an error that he did
> not have permissions to view his ticket.
> RT creates an internal user for him, unlike the rest of our employees
> who don't show up in the user list because they exist in the configured
> LDAP. I disabled the (discontinued) queue, and 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.
>
> Can anyone help me with this first problem?
>
> --
> N. Scott Pestana
> IT Infrastructure
> Linguamatics
>
> --------
> RT Training Sessions (http://bestpractical.com/**services/training.html<http://bestpractical.com/services/training.html>
> )
> * Boston March 5 & 6, 2012
>


scott.pestana at linguamatics

Feb 10, 2012, 3:45 PM

Post #3 of 14 (1323 views)
Permalink
Re: Problems with new users [In reply to]

Kenn,
I'm not sure how to give you the info you're asking for but...

If I look under Configuration->Global->Group Rights, Everyone, into
the Rights for Staff tab I found that ModifySelf / "Modify one's own RT
account" is not checked currently. The same is true for Privileged and
Unprivileged. Should I start with enabling ModifySelf / "Modify one's
own RT account" for the Privileged Users group? For Everyone?

Right now the rights that are granted are the same for
Everyone/Privileged/Unprivileged entries are "Create tickets" and "Reply
to tickets"

Under the Global-User Rights we only have root and RT Admin
listed. They have the "Do anything and everything" right, logically enough.

Under the Configuration->Queues, into itsupport, there are no Users
listed for the User Rights. For Group Rights, Everyone has CreateTicket
and the Unprivileged have SeeQueue & ShowTicket.

-Scott

On 2/10/2012 6:07 PM, Kenneth Crocker wrote:
> Scott,
>
> I can, but it would be helpful to know how uyou have set up your
> privileges, both Globally and by Queue. Also, in order for LDAP info
> to get into a User, they must have the "ModifySelf" right applied.
> OVerall, I think this is all a privileges problem.
>
> Kenn
>
> On Fri, Feb 10, 2012 at 12:45 PM, Scott Pestana
> <scott.pestana [at] linguamatics
> <mailto:scott.pestana [at] linguamatics>> wrote:
>
> Hello RT Users,
> To preface, I've got several years experience and training with
> the Linux platform and PERL, but I'm completely new to RT; I've
> done a few web searches and a three or four different google
> searches of the email archive and can't find any insight into our
> problem.
>
> We're having a strange problem with our users in our two RT
> instances, that we think are related. When our internal IT
> Support instance of RT was created everything was working well for
> some time, and we currently have RT configured to work with our
> LDAP database for users and their credentials. However, new users
> (new employees) trying to use RT are not able to get the same
> functionality.
>
> For example: one user can send in emails to the RT queue and
> proceed normally. However if he tries to log in to the web
> version, the RT system treats him like is associated with a
> different queue than the rest of our users. When he tried to
> create a ticket through the web RT would create the ticket in this
> wrong queue, and he immediately got an error that he did not have
> permissions to view his ticket.
> RT creates an internal user for him, unlike the rest of our
> employees who don't show up in the user list because they exist in
> the configured LDAP. I disabled the (discontinued) queue, and
> 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.
>
> Can anyone help me with this first problem?
>
> --
> N. Scott Pestana
> IT Infrastructure
> Linguamatics
>
> --------
> RT Training Sessions (http://bestpractical.com/services/training.html)
> * Boston March 5 & 6, 2012
>
>
>
>
> --------
> 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


falcone at bestpractical

Feb 13, 2012, 9:06 AM

Post #4 of 14 (1277 views)
Permalink
Re: Problems with new users [In reply to]

On Fri, Feb 10, 2012 at 03:45:25PM -0500, Scott Pestana wrote:
> For example: one user can send in emails to the RT queue and
> proceed normally. However if he tries to log in to the web version,
> the RT system treats him like is associated with a different queue
> than the rest of our users. When he tried to create a ticket
> through the web RT would create the ticket in this wrong queue, and
> he immediately got an error that he did not have permissions to view
> his ticket.

It'd be useful to see some sort of screenshot of what he's seeing.

> RT creates an internal user for him, unlike the rest of our
> employees who don't show up in the user list because they exist in
> the configured LDAP. I disabled the (discontinued) queue, and

As a heads up, RT *always* create an internal user, even for users
pulled from LDAP.

There is no password stored, but RT must have an internal user account,
otherwise the user can't be associated with tickets.

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

As I mentioned on your other mail, debug level logs of what happens on
login are much more likely to show us what is going on than
descriptions of the problem.

I'll also note that your ExternalAuth config didn't allow for LDAP
auth, so I'm not sure what password your users are using.

-kevin


scott.pestana at linguamatics

Feb 14, 2012, 12:22 PM

Post #5 of 14 (1294 views)
Permalink
Re: Problems with new users [In reply to]

Kevin,
Comments inline:

On 2/13/2012 12:06 PM, Kevin Falcone wrote:
> On Fri, Feb 10, 2012 at 03:45:25PM -0500, Scott Pestana wrote:
>> For example: one user can send in emails to the RT queue and
>> proceed normally. However if he tries to log in to the web version,
>> the RT system treats him like is associated with a different queue
>> than the rest of our users. When he tried to create a ticket
>> through the web RT would create the ticket in this wrong queue, and
>> he immediately got an error that he did not have permissions to view
>> his ticket.
> It'd be useful to see some sort of screenshot of what he's seeing.
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.

>> RT creates an internal user for him, unlike the rest of our
>> employees who don't show up in the user list because they exist in
>> the configured LDAP. I disabled the (discontinued) queue, and
> As a heads up, RT *always* create an internal user, even for users
> pulled from LDAP.
>
> There is no password stored, but RT must have an internal user account,
> otherwise the user can't be associated with tickets.
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.

>> 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.
> As I mentioned on your other mail, debug level logs of what happens on
> login are much more likely to show us what is going on than
> descriptions of the problem.
>
> I'll also note that your ExternalAuth config didn't allow for LDAP
> auth, so I'm not sure what password your users are using.
>
> -kevin

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

[Tue Jan 24 17:47:48 2012] [debug]: Attempting to use external auth
service: Lingua_LDAP
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:64)
[Tue Jan 24 17:47:48 2012] [debug]: SSO Failed and no user to test with.
Nexting
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:92)
[Tue Jan 24 17:47:48 2012] [debug]: Autohandler called ExternalAuth.
Response: (0, No User)
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/html/Elements/DoAuth:11)
[Tue Jan 24 17:48:08 2012] [error]: WebRT: Queue could not be loaded.
(/opt/rt4/share/html/Elements/Error:82)
[Tue Jan 24 17:49:16 2012] [debug]: About to think about scrips for
transaction #24282 (/opt/rt4/sbin/../lib/RT/Transaction.pm:173)
[Tue Jan 24 17:49:16 2012] [debug]: About to think about scrips for
transaction #24283 (/opt/rt4/sbin/../lib/RT/Transaction.pm:173)
[Tue Jan 24 17:49:16 2012] [debug]: About to think about scrips for
transaction #24284 (/opt/rt4/sbin/../lib/RT/Transaction.pm:173)
[Tue Jan 24 17:49:16 2012] [debug]: About to think about scrips for
transaction #24285 (/opt/rt4/sbin/../lib/RT/Transaction.pm:173)
[Tue Jan 24 17:49:16 2012] [debug]: About to think about scrips for
transaction #24286 (/opt/rt4/sbin/../lib/RT/Transaction.pm:173)
[Tue Jan 24 17:49:16 2012] [debug]: About to think about scrips for
transaction #24287 (/opt/rt4/sbin/../lib/RT/Transaction.pm:173)
[Tue Jan 24 17:49:28 2012] [debug]:
RT::Authen::ExternalAuth::CanonicalizeUserInfo called by
RT::Authen::ExternalAuth
/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/E
xternalAuth.pm 553 with: Disabled: 0, EmailAddress: , Gecos: ilewin,
Name: ilewin, Privileged: 1
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:450)
[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
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:536)
[Tue Jan 24 17:49:28 2012] [debug]: About to think about scrips for
transaction #24288 (/opt/rt4/sbin/../lib/RT/Transaction.pm:173)
[Tue Jan 24 17:49:28 2012] [debug]: About to think about scrips for
transaction #24289 (/opt/rt4/sbin/../lib/RT/Transaction.pm:173)
[Tue Jan 24 17:49:28 2012] [debug]: About to think about scrips for
transaction #24290 (/opt/rt4/sbin/../lib/RT/Transaction.pm:173)
[Tue Jan 24 17:49:52 2012] [debug]: Attempting to use external auth
service: Lingua_LDAP
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:64)
[Tue Jan 24 17:49:52 2012] [debug]: SSO Failed and no user to test with.
Nexting
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:92)
[Tue Jan 24 17:49:52 2012] [debug]: Autohandler called ExternalAuth.
Response: (0, No User)
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/html/Elements/DoAuth:11)
[Tue Jan 24 17:50:07 2012] [error]: WebRT: Queue could not be loaded.
(/opt/rt4/share/html/Elements/Error:82)


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


falcone at bestpractical

Feb 14, 2012, 12:51 PM

Post #6 of 14 (1276 views)
Permalink
Re: Problems with new users [In reply to]

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


scott.pestana at linguamatics

Feb 14, 2012, 1:36 PM

Post #7 of 14 (1267 views)
Permalink
Re: Problems with new users [In reply to]

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


falcone at bestpractical

Feb 14, 2012, 2:44 PM

Post #8 of 14 (1263 views)
Permalink
Re: Problems with new users [In reply to]

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


scott.pestana at linguamatics

Feb 23, 2012, 9:07 AM

Post #9 of 14 (1183 views)
Permalink
Re: Problems with new users [In reply to]

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
Attachments: RT_SiteConfig.pm (3.94 KB)


trs at bestpractical

Feb 23, 2012, 9:15 AM

Post #10 of 14 (1187 views)
Permalink
Re: Problems with new users [In reply to]

On 02/23/2012 12:07 PM, Scott Pestana wrote:
> #/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?

Why aren't you using the rtldapimport script that ships with
RT::Extension::LDAPImport?

/opt/rt4/local/plugins/RT-Extension-LDAPImport/bin/rtldapimport --help

Thomas
--------
RT Training Sessions (http://bestpractical.com/services/training.html)
* Boston March 5 & 6, 2012


scott.pestana at linguamatics

Feb 23, 2012, 12:07 PM

Post #11 of 14 (1181 views)
Permalink
Re: Problems with new users [In reply to]

Thomas,
I didn't know it existed. I can't find rtldapimport anywhere on
the CPAN page, and a google search for "rtldapimport
site:bestpractical.com" only finds hits in version control.

It looks as though the README (as hosted on metacpan) talks about
it. I can't install RT::Extension::LDAPImport yet because I've not yet
set up RT's DB. I want to wait for thoughts on my RT_Siteconfig.pm
before I follow through with the make initialize-database. I'll take a
look at the script then.

-Scott

On 2/23/2012 12:15 PM, Thomas Sibley wrote:
> On 02/23/2012 12:07 PM, Scott Pestana wrote:
>> #/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?
> Why aren't you using the rtldapimport script that ships with
> RT::Extension::LDAPImport?
>
> /opt/rt4/local/plugins/RT-Extension-LDAPImport/bin/rtldapimport --help
>
> Thomas
> --------
> 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

--------
RT Training Sessions (http://bestpractical.com/services/training.html)
* Boston March 5 & 6, 2012


trs at bestpractical

Feb 23, 2012, 12:14 PM

Post #12 of 14 (1180 views)
Permalink
Re: Problems with new users [In reply to]

On 02/23/2012 03:07 PM, Scott Pestana wrote:
> It looks as though the README (as hosted on metacpan) talks about
> it. I can't install RT::Extension::LDAPImport yet because I've not yet
> set up RT's DB.

The README is also included in the release tarball. You can download
that and look through it before you install it.

Thomas
--------
RT Training Sessions (http://bestpractical.com/services/training.html)
* Boston March 5 & 6, 2012


scott.pestana at linguamatics

Feb 24, 2012, 11:12 AM

Post #13 of 14 (1167 views)
Permalink
Re: Problems with new users [In reply to]

Can someone take a look at the RT_SiteConfig.pm I have set up, let
me know if we're doing anything wrong here?

Based of the conversations I've had I think I need to make these
changes:

- Set($AutoCreate, {Privileged=>1});
+ Set($AutoCreate, {Privileged=>0});

- 'attr_match_list' => [ 'EmailAddress' ]
+ 'attr_match_list' => [ 'EmailAddress',
+ 'uid' ],



-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
Attachments: RT_SiteConfig.pm (3.94 KB)


falcone at bestpractical

Mar 2, 2012, 8:48 AM

Post #14 of 14 (1088 views)
Permalink
Re: Problems with new users [In reply to]

On Thu, Feb 23, 2012 at 12:07:33PM -0500, Scott Pestana wrote:
> 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});

This only affects people logging in using the UI. This changes from
making them Privileged to the default of making them Unprivileged.
Users who email first will always be Unprivileged.

> - 'attr_match_list' => [ 'EmailAddress' ]
> + 'attr_match_list' => [ 'EmailAddress',
> + 'uid' ],

attr_match_list is (quoting from the documentation)
# The list of RT attributes that uniquely identify a user
uid is not an RT attribute.#

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

Why not just use the provided rtldapimport script?
It's documented in the README along with all the config options.
You may want to test the development release made by my colleague,
0.32_02, it has a number of useful enhancements.

You've still never really answered why you think the problem user is
"associated with an old queue that was used for testing" but I believe
your problem is that you need to add this user to the Groups in your
system that have rights.

-kevin

> #/usr/bin/perl
> #RT_User_Update.pl - NSP 20120222
> use RT;
> use RT::Extension::LDAPImport;
> Set($LDAPHost,'[1]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 ([2]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: [3]www.linguamatics.com
>
> References
>
> Visible links
> 1. file:///Users/falcone/tmp/ldap:/ldapserver.linguamatics.com
> 2. http://bestpractical.com/services/training.html
> 3. http://www.linguamatics.com/

> # Any configuration directives you include here will override
> # RT's default configuration file, RT_Config.pm
> #
> # To include a directive here, just copy the equivalent statement
> # from RT_Config.pm and change the value. We've included a single
> # sample value below.
> #
> # This file is actually a perl module, so you can include valid
> # perl code, as well.
> #
> # The converse is also true, if this file isn't valid perl, you're
> # going to run into trouble. To check your SiteConfig file, use
> # this comamnd:
> #
> # perl -c /path/to/your/etc/RT_SiteConfig.pm
> #
> # You must restart your webserver after making changes to this file.
>
> Set( $rtname, 'Linguamatics Dev');
>
> # You must install Plugins on your own, this is only an example
> # of the correct syntax to use when activating them.
> # There should only be one @Plugins declaration in your config file.
> #Set(@Plugins,(qw(RT::Extension::QuickDelete RT::Extension::CommandByMail)));
> Set(@Plugins, qw(RT::Authen::ExternalAuth));
>
> Set($rtname, 'Linguamatics');
> Set($Organization, 'linguamatics.com');
> Set($DatabaseUser, '######################');
> Set($DatabasePassword, '######################');
> Set($DatabaseName, '######################');
> Set($DatabaseHost, "db.linguamatics.com");
> Set($DatabaseRTHost, "db.linguamatics.com");
>
> # GRANT ALL PRIVILEGES ON rt_dev.* TO 'rt_devuser'@'owlwoman.linguamatics.com' IDENTIFIED BY 'rt_d3vus3r';
>
> #Set(%FullTextSearch, Enable => 1, Indexed => 0, );
> Set( %FullTextSearch,
> Enable => 1,
> Indexed => 1,
> Table => 'AttachmentsIndex',
> MaxMatches => '10000',
> );
>
> Set( $CanonicalizeEmailAddressMatch, '@owlwoman\.linguamatics\.com$' );
> Set( $CanonicalizeEmailAddressReplace, '@linguamatics.com ');
> #Set($RTAddressRegexp,qr{^(?:(?:rt_dev(?:|-comment)|testsupport(?:|-comment))\@(owlwoman\.)?linguamatics\.com)$}i);
> Set($RTAddressRegexp,qr{^(?:rt-dev(?:|-comment)\@(?:owlwoman\.)?linguamatics\.com)$}i);
> Set($OwnerEmail , 'sysadmin [at] linguamatics');
> Set($CorrespondAddress, 'rt-dev [at] linguamatics');
> Set($CommentAddress, 'rt-dev-comment [at] linguamatics');
> Set($Timezone, 'Europe/London');
> Set($UseFriendlyToLine, 1);
> Set($FriendlyFromLineFormat, "\"%s\" <%s>");
>
> Set($WebPath, '/local/rt-dev');
> Set($WebDomain, 'owlwoman.linguamatics.com');
> Set($WebBaseURL, 'https://secure.linguamatics.com');
> Set($CanonicalizeRedirectURLs, 1);
> Set($ParseNewMessageForTicketCcs, 1);
> Set($WebExternalAuth, 1);
> Set($WebExternalAuto, 1);
> Set($AutoCreate, {Privileged=>1});
>
> Set($ExternalAuthPriority, ['Lingua_LDAP']);
> Set($ExternalInfoPriority, ['Lingua_LDAP']);
> Set($ExternalServiceUsesSSLorTLS, 0);
> Set($AutoCreateNonExternalUsers, 1);
> Set($ExternalSettings, {
> 'Lingua_LDAP' => {
> 'type' => 'ldap',
> 'server' => 'ldapserver.linguamatics.com',
> 'base' => 'ou=users,dc=linguamatics,dc=com',
> 'filter' => '(|(objectClass=posixAccount)(objectClass=account))',
> 'tls' => 0,
> 'net_ldap_args' => [ version => 3 ],
> 'attr_match_list' => [ 'EmailAddress' ],
> 'attr_map' => { 'Name' => 'uid',
> 'EmailAddress' => 'mail',
> 'RealName' => 'cn',
> 'ExternalAuthId' => 'uid',
> 'Gecos' => 'gecos'
> }
> # 'group' => 'cn=staff,ou=Groups,dc=linguamatics,dc=com',
> # 'group_attr' => 'memberUid',
> # 'ssl_version' => 3,
> # 'd_filter' => '(employeeType=other)'
> }
> });
>
> =item C<$LogToFile>, C<$LogDir>, C<$LogToFileNamed>
> Logging to a standalone file is also possible. The file needs to both
> exist and be writable by all direct users of the RT API.
> =cut
>
> Set($LogToFile, debug);
> Set($LogDir, q{var/log});
> Set($LogToFileNamed, "rt.log"); #log to rt.log
>
>
> 1;

> --------
> RT Training Sessions (http://bestpractical.com/services/training.html)
> * Boston ? March 5 & 6, 2012

Request Tracker users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.