Re: [rt-users] Problems with new users

2012-03-02 Thread Kevin Falcone 
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 S

Re: [rt-users] Problems with new users

2012-02-24 Thread Scott Pestana 
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

# 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, 'l

Re: [rt-users] Problems with new users

2012-02-23 Thread Thomas Sibley 
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

Re: [rt-users] Problems with new users

2012-02-23 Thread Scott Pestana 

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

Re: [rt-users] Problems with new users

2012-02-23 Thread Thomas Sibley 
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

Re: [rt-users] Problems with new users

2012-02-23 Thread 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, 2

Re: [rt-users] Problems with new users

2012-02-14 Thread Kevin Falcone 
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


pgpLsNsSaBSyi.pgp
Description: PGP signature

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

Re: [rt-users] Problems with new users

2012-02-14 Thread 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/Auth

Re: [rt-users] Problems with new users

2012-02-14 Thread 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


pgpIlUdgRBkvD.pgp
Description: PGP signature

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

Re: [rt-users] Problems with new users

2012-02-14 Thread Scott Pestana 

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: 
(&(

Re: [rt-users] Problems with new users

2012-02-13 Thread Kevin Falcone 
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


pgpxxDAeUsglJ.pgp
Description: PGP signature

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

Re: [rt-users] Problems with new users

2012-02-10 Thread Scott Pestana 

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


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

Re: [rt-users] Problems with new users

2012-02-10 Thread Kenneth Crocker 
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.pest...@linguamatics.com> 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