LDAP SMB overlay update

There’s a small update to the LDAP SMB overlay that I modified. A bug
prevents autocreate of accounts when authenticating with LDAP or from
grabbing user information from LDAP when autocreating with SMB.

Main Features and Changes

  • Fixed some bugs and rearranged code.
  • Added authentication and auto account creation through SMB.
  • Order and choice of authentication methods may be specified.
  • Home/ticket page default refresh intervals may be specified.

http://www.mosemann.com/software/LDAPSMB1.2_RT3.tar.gz

Russell Mosemann, Ph.D. * Computing Services * Concordia University, Nebraska
"When young I saw the signs ‘Slow children at play’. Later in life I
saw ‘Slow men at work’ and was happy they found a productive niche."

Hi everyone,

Long time listener, first time poster…

I’m setting up a site for an open source project that I’m working on and I
would like to have ‘anonymous’ people submit tickets through e-mail or the
web interface.

I’d also like to let those people view the tickets and, I guess, edit the
ones that they have submitted.

I’ve googled, read the wiki, looked at the archives but it doesn’t seem like
anyone is using RT in this way (read: I don’t want to use Bugzilla, if you
want ;).

Even /SelfService seems to require an account in advance.

I guess that I could create a ‘guest’ user that can only read tickets. I
should note that there are other queues on the system that aren’t going to be
made available to the public.

Any suggestions? Am I missing something here?

Regards,
g. matthew rice matt@starnix.com starnix, toronto, ontario, ca
phone: 647.722.5301 x242 gpg id: EF9AAD20
http://www.starnix.com professional linux services & products

Hi, I am new to RT, so not everything may be
correct that I right, but here it is what I’ve figured out so far:

You should create an unprivileged user
(‘guest’, or whatever). Then for each queue you want him to have
access, modify the configuration of the queue (NOT the global rights of
the unprivileged users), and grant the unprivileged user group the
SeeQueue and CreateTicket rights (maybe Modify ticket as well if you
wish).

The only problem with this approach (that I couldn’t solve yet) is,
that when the unprivileged user logs in to create a ticket, he can
select the target queue, but does not see (consequently, cannot fill)
any custom fields for this queue. If anyone has an idea, how to solve
this problem, it would be greatly appreciated.

Robert

G. Matthew Rice wrote:

Hi everyone,

Long time listener, first time poster…

I’m setting up a site for an open source project that I’m working on and I
would like to have ‘anonymous’ people submit tickets through e-mail or the
web interface.

I’d also like to let those people view the tickets and, I guess, edit the
ones that they have submitted.

I’ve googled, read the wiki, looked at the archives but it doesn’t seem like
anyone is using RT in this way (read: I don’t want to use Bugzilla, if you
want ;).

Even /SelfService seems to require an account in advance.

I guess that I could create a ‘guest’ user that can only read tickets. I
should note that there are other queues on the system that aren’t going to be
made available to the public.

Any suggestions? Am I missing something here?

Regards,

There was a script for autogenerated passwords (in the wiki? - I am
having trouble remembering where I got it - try the archives also). It
works well for us. It sends an encrypted password to the first time
user (new email address) that will allow them to log in. Works well
with 3.2.2 (have yet to test it with 3.4.x).On Thu, 03 Mar 2005 08:45:13 +0100, Robert Fekete frobert@analogic-computers.com wrote:

Hi, I am new to RT, so not everything may be correct that I right, but here
it is what I’ve figured out so far:

You should create an unprivileged user (‘guest’, or whatever). Then for
each queue you want him to have access, modify the configuration of the
queue (NOT the global rights of the unprivileged users), and grant the
unprivileged user group the SeeQueue and CreateTicket rights (maybe Modify
ticket as well if you wish).

The only problem with this approach (that I couldn’t solve yet) is, that
when the unprivileged user logs in to create a ticket, he can select the
target queue, but does not see (consequently, cannot fill) any custom fields
for this queue. If anyone has an idea, how to solve this problem, it would
be greatly appreciated.

Robert

G. Matthew Rice wrote:
Hi everyone, Long time listener, first time poster… I’m setting up a site
for an open source project that I’m working on and I would like to have
’anonymous’ people submit tickets through e-mail or the web interface. I’d
also like to let those people view the tickets and, I guess, edit the ones
that they have submitted. I’ve googled, read the wiki, looked at the
archives but it doesn’t seem like anyone is using RT in this way (read: I
don’t want to use Bugzilla, if you want ;). Even /SelfService seems to
require an account in advance. I guess that I could create a ‘guest’ user
that can only read tickets. I should note that there are other queues on the
system that aren’t going to be made available to the public. Any
suggestions? Am I missing something here? Regards,


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

RT Administrator and Developer training is coming to your town soon!
(Boston, San Francisco, Austin, Sydney) Contact training@bestpractical.com
for details.

Be sure to check out the RT Wiki at http://wiki.bestpractical.com

The article is in the RT Wiki -> Contribuitions under Other at the
bottom of the page. You want to go to the link for the Univirsity of
Oslo: http://www.usit.uio.no/it/rt/modifications.html

sh…On Thu, 3 Mar 2005 06:32:43 -0500, Stephen Hancock sh.hancock@gmail.com wrote:

There was a script for autogenerated passwords (in the wiki? - I am
having trouble remembering where I got it - try the archives also). It
works well for us. It sends an encrypted password to the first time
user (new email address) that will allow them to log in. Works well
with 3.2.2 (have yet to test it with 3.4.x).

On Thu, 03 Mar 2005 08:45:13 +0100, Robert Fekete frobert@analogic-computers.com wrote:

Hi, I am new to RT, so not everything may be correct that I right, but here
it is what I’ve figured out so far:

You should create an unprivileged user (‘guest’, or whatever). Then for
each queue you want him to have access, modify the configuration of the
queue (NOT the global rights of the unprivileged users), and grant the
unprivileged user group the SeeQueue and CreateTicket rights (maybe Modify
ticket as well if you wish).

The only problem with this approach (that I couldn’t solve yet) is, that
when the unprivileged user logs in to create a ticket, he can select the
target queue, but does not see (consequently, cannot fill) any custom fields
for this queue. If anyone has an idea, how to solve this problem, it would
be greatly appreciated.

Robert

G. Matthew Rice wrote:
Hi everyone, Long time listener, first time poster… I’m setting up a site
for an open source project that I’m working on and I would like to have
’anonymous’ people submit tickets through e-mail or the web interface. I’d
also like to let those people view the tickets and, I guess, edit the ones
that they have submitted. I’ve googled, read the wiki, looked at the
archives but it doesn’t seem like anyone is using RT in this way (read: I
don’t want to use Bugzilla, if you want ;). Even /SelfService seems to
require an account in advance. I guess that I could create a ‘guest’ user
that can only read tickets. I should note that there are other queues on the
system that aren’t going to be made available to the public. Any
suggestions? Am I missing something here? Regards,


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

RT Administrator and Developer training is coming to your town soon!
(Boston, San Francisco, Austin, Sydney) Contact training@bestpractical.com
for details.

Be sure to check out the RT Wiki at http://wiki.bestpractical.com

This is not, I guess, strictly an RT question, but the context should
be pretty obvious.

If anyone here has actually managed to get one of the
NTLM-authentication modules for Apache to work reliably against a
Windows 2000 or 2003 Active Directory server?

If so, please ping me off-list – I’d love to pick your brains a bit.

-n

------------------------------------------------------------memory@blank.org
Calling Motif a GUI is like calling a pile of bricks an apartment building.
http://blank.org/memory/----------------------------------------------------

The situation thus far:

I’ve got samba’s mod_ntlm_winbind providing NTLM authentication to my
RT instance, and it is actually more-or-less working: with a few
caveats, Windows users can connect directly via IE and browse the
SelfService interface…

…except…

…we’ve been running without WebExternalAuth for the better part of a
year now, so most users already have an “account” created by
rt-mailgate where the account username is "user@company.com", and if
they log into the SelfService interface via WebExternalAuth, a new
user gets created for them that can’t see the “other” user’s tickets.

Is there a simple way to make rt-mailgate create new users with only a
short username? (Obviously this would have to be smart enough to fall
back to user@domain if there’s an existing user with the same short
username but a different address.)

And, if anyone’s ever dealt with this problem before, I’d love to be
able to pick your brains about the merge issues.

-n

------------------------------------------------------------memory@blank.org
"Ever since the US election, there’s been a lot of loose talk about
discovering the will of the people.' What all the pundits and politicians fail to realize is that the system worked perfectly and the people got EXACTLY what they wanted: Another precious week of not having to call EITHER of those losersPresident.’" (–Ian Barkley-Yeung)
http://blank.org/memory/----------------------------------------------------

…we’ve been running without WebExternalAuth for the better part of a
year now, so most users already have an “account” created by
rt-mailgate where the account username is "user@company.com", and if
they log into the SelfService interface via WebExternalAuth, a new
user gets created for them that can’t see the “other” user’s tickets.

Is there a simple way to make rt-mailgate create new users with only a
short username? (Obviously this would have to be smart enough to fall
back to user@domain if there’s an existing user with the same short
username but a different address.)

You want to create RT/User_Local.pm and override CanonicalizeUserInfo

=item CanonicalizeUserInfo HASH of ARGS

CanonicalizeUserInfo can convert all User->Create options.

it takes a hashref of all the params sent to User->Create and

returns that same hash, by default nothing is done.

This function is intended to allow users to have their info looked up via

an outside source and modified upon creation.

=cut

And, if anyone’s ever dealt with this problem before, I’d love to be
able to pick your brains about the merge issues.

Sounds like a job for a small perl script. Something along these lines…
(I was going to warn you that it was untested, but it does work here :wink:

#!/usr/bin/perl
use lib qw(/opt/rt3/lib/);
use RT;
RT::LoadConfig();
RT::Init();
use RT::Users;
my $users = RT::Users->new($RT::SystemUser);
$users->UnLimit();
while (my $user = $users->Next) {
next unless ($user->Name =~ /^(.*?)@example.com$/);
my ($ret,$msg) = $user->SetName($1);
print “$msg\n”;
}

Okay, I am like 0.00001mm away from the Holy Grail: single-sign-on RT
in a Windows Active Directory environment using Samba and Apache/*nix.

Only one small stumbling block remains:

I’m using the UiO LDAP synch code (http://www.usit.uio.no/it/rt/modifications.html)
to have usernames looked up in the ADS LDAP tree. This works fine
when a user is auto-created via incoming email, but doesn’t cover the
case of a user being auto-created by logging in to the self-service
web interface via WebExternalAuth.

Obviously I just need to modify RT so that it looks up the username
it’s getting from the webserver in the LDAP directory and correctly
populates the RealName and Email fields, so um… where would I do
that, precisely?

-n

------------------------------------------------------memory@blank.org
You can’t say “tits” on the radio, but you can say "Pamela Anderson Lee"
and what’s the difference? (–Sarah Vowell)
http://blank.org/memory/----------------------------------------------

Obviously I just need to modify RT so that it looks up the username
it’s getting from the webserver in the LDAP directory and correctly
populates the RealName and Email fields, so um… where would I do
that, precisely?

RT::Interface::Web::WebExternalAutoInfo ?

Obviously I just need to modify RT so that it looks up the username
it’s getting from the webserver in the LDAP directory and correctly
populates the RealName and Email fields, so um… where would I do
that, precisely?

RT::Interface::Web::WebExternalAutoInfo ?

Or http://www.mosemann.com/software/LDAPSMB1.2_RT3.tar.gz and forget about
trying to do authentication through the web server.

Russell Mosemann, Ph.D. * Computing Services * Concordia University, Nebraska
"I’m 70% sure I passed with an F or better." - student comment after test

In the immortal words of Jesse Vincent (jesse@bestpractical.com):

RT::Interface::Web::WebExternalAutoInfo ?

Well, that makes sense, but I’ve created a lib/RT/Interface/Web_Local.pm
with:

sub WebExternalAutoInfo {
	my $user = shift;

	$RT::Logger->debug( "WebExternalAutoInfo: Looking for $user");
	my %LdapUserInfo = LdapUserFindByUsername($user);
	$LdapUserInfo{'Privileged'} = 1;
    
	# and return the wad of stuff
	return {%LdapUserInfo};
}

…and that Logger instance never, ever gets called.

Weirdly, LdapUserFindByMailaddr (out of my User_Local.pm) does get
called as the user is logging in over the web, and using caller() to
get a traceback in the debug tells me that it’s coming from:

[Wed Mar 30 00:54:32 2005] [info]: LdapUserFindByMailaddr: Looking for
samaccountname cn mail filter= (&(mail=)
(objectClass=person)) base= cn=Users,dc=elided,dc=com scope= one
callstack= 1st: RT::User::LdapUserFindByMailaddr
2nd: RT::User::LookupExternalUserInfo
3rd: RT::User::Create
(/usr/local/rt3/lib/RT/User_Local.pm:136)

…which makes sense, since User->Create calls CanonicalizeUserInfo,
but shouldn’t WebExternalAuto be called first?

-n

------------------------------------------------------------memory@blank.org
#!/usr/bin/perl -iake_one_down_pass_it_around:bottles_of_beer:on_the_wall:99
for(($t,$a,$b,$i)=split/:/,$^I;$i;print){$
="-$i$a$b,-$i$a,-T$t,-".–$i."$a$b"
;s/(-1
.*?e)s/$1/g;y/_-/ \n/}# (–Randolph Chung and Joey Hess)
http://blank.org/memory/----------------------------------------------------