[rt-users] Problems with new users
Kevin Falcone
falcone at bestpractical.com
Fri Mar 2 11:48:10 EST 2012
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.com');
> Set($CorrespondAddress, 'rt-dev at linguamatics.com');
> Set($CommentAddress, 'rt-dev-comment at linguamatics.com');
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20120302/ad1c5aeb/attachment.sig>
More information about the rt-users
mailing list