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

Mailing List Archive: Request Tracker: Users

Self user creation

 

 

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


mike at tekniq

Mar 19, 2006, 8:55 AM

Post #1 of 10 (4018 views)
Permalink
Self user creation

Hello,



I currently have my helpdesks configured to mail out a username and password
upon submission of a ticket, I see that RT is designed not to allow people
to create their own username and password but I was wondering if anyone had
configured their RT to allow users to sign up themselves via a web
interface.



Best Regards

Michael Shanks








--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.2.5/284 - Release Date: 17/03/2006


KFCrocker at lbl

Mar 20, 2006, 9:15 AM

Post #2 of 10 (3916 views)
Permalink
Re: Self user creation [In reply to]

NEVER!!

Michael Shanks wrote:

> Hello,
>
>
>
> I currently have my helpdesks configured to mail out a username and
> password upon submission of a ticket, I see that RT is designed not to
> allow people to create their own username and password but I was
> wondering if anyone had configured their RT to allow users to sign up
> themselves via a web interface.
>
>
>
> Best Regards
>
> Michael Shanks
>
>
>
>
>
>
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.2.5/284 - Release Date: 17/03/2006
>
>------------------------------------------------------------------------
>
>_______________________________________________
>http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>
>Community help: http://wiki.bestpractical.com
>Commercial support: sales[at]bestpractical.com
>
>
>Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
>Buy a copy at http://rtbook.bestpractical.com
>
>
>We're hiring! Come hack Perl for Best Practical: http://bestpractical.com/about/jobs.html
>


rickr at rice

Mar 20, 2006, 9:55 AM

Post #3 of 10 (3908 views)
Permalink
Re: Self user creation [In reply to]

Ken Crocker wrote:
> NEVER!!

Religious invective aside... :-)

We've set up a web form that sends a specially-crafted e-mail to our RT
instance, which then auto-replies with a new password for that user. It
can be used for new or existing users.

http://is.rice.edu/~rickr/webdocs/RT/passreset.html

Of course, you can only request a password if you have a Rice e-mail
address :-)

Rick R.

--
Rick Russell
For computer help, call xHELP (x4357 or 713-348-4357)
OpenPGP/GnuPG Public Key at ldap://certificate.rice.edu
761D 1C20 6428 580F BD98 F5E5 5C8C 56CA C7CB B669
--
Helpdesk Supervisor, Client Services
IT/Academic & Research Computing
Rice University
Voice: 713.348.5267 Fax: 713.348.6099
_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales[at]bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com


We're hiring! Come hack Perl for Best Practical: http://bestpractical.com/about/jobs.html


KFCrocker at lbl

Mar 20, 2006, 11:34 AM

Post #4 of 10 (3894 views)
Permalink
Re: Self user creation [In reply to]

Rick,

That was merely my tounge-in-cheek response. We try to keep access
and control on a simple basis (go thru the Administrator to get added),
easier to maintain and usually less troupble all-around.

Kenn

Rick Russell wrote:

>Ken Crocker wrote:
>
>
>>NEVER!!
>>
>>
>
>Religious invective aside... :-)
>
>We've set up a web form that sends a specially-crafted e-mail to our RT
>instance, which then auto-replies with a new password for that user. It
>can be used for new or existing users.
>
>http://is.rice.edu/~rickr/webdocs/RT/passreset.html
>
>Of course, you can only request a password if you have a Rice e-mail
>address :-)
>
>Rick R.
>
>
>


ahlincoln at lbl

Mar 21, 2006, 10:51 AM

Post #5 of 10 (3900 views)
Permalink
Re: Self user creation [In reply to]

Rick Russell wrote:
> Ken Crocker wrote:
>
>>NEVER!!
>
>
> Religious invective aside... :-)
>
> We've set up a web form that sends a specially-crafted e-mail to our RT
> instance, which then auto-replies with a new password for that user. It
> can be used for new or existing users.
>
> http://is.rice.edu/~rickr/webdocs/RT/passreset.html
>
> Of course, you can only request a password if you have a Rice e-mail
> address :-)

A couple years ago I hacked RT to allow users to self-create upon login
as long as they have a valid entry in our enterprise LDAP server and it
contains a valid orgcode. I like it because it doesn't require any
action on my part, but still has a nice built-in set of constraints. I
wrote the code for allowing users to self-create via email, but given
the ease of spoofing, I leave it toggled off:

Set($LDAPExternalAuth, 1); # enable LDAP authentication/lookups
Set($LDAPWebExternalAuto, 1); # create user acct from LDAP at login
Set($LDAPMailExternalAuto, 0); # create user acct from LDAP at email

I included a plethora of other options, including LDAP/S connectivity,
attribute selection/mapping (below).

Has anyone used the new LDAP overlay stuff? Does it allow for this
level of granularity?

Thanks,

Tony

Set($LDAPExternalAuth, 1); # enable LDAP authentication/lookups
Set($LDAPWebExternalAuto, 1); # create user acct from LDAP at login
Set($LDAPMailExternalAuto, 0); # create user acct from LDAP at email

Set($LDAPHost, 'myldaphost.foo.bar');
Set($LDAPSSLHost, 'sslldaphost.foo.bar');
Set($LDAPPort, '389');
Set($LDAPSSLPort, '636');
Set($LDAPBase, 'dc=foo,dc=bar');
Set($LDAPSSLAuth, 1); # set to 1 for encrypted connections for auth
Set($LDAPSSLSearch, 0); # set to 1 for encrypted connections for
searches
Set($LDAPCert, '/path/to/ldapcert');

# set these two for non-anonymous lookups
Set($LDAPBind, '');
Set($LDAPPass, '');

# use this to narrow the filter for authentication; any LDAP search filter
# placed here will be concatenated with a (uid=username) filter
# Leaving it 'undef' means default filter of (uid=username) will be used)
Set($LDAPSearchFilter,
'(&(status=active)(|(orgcode=ABC*)(lblpan=DEF)))'
);

# define which attrs we want to pull back
@LDAPSearchAttrs = qw(mail cn division uid displayName telephoneNumber);

Set($LDAPMailAttr, 'mail');
Set($LDAPCnameAttr, 'cn');
Set($LDAPOrgAttr, 'division');
Set($LDAPUidAttr, 'uid');
Set($LDAPFullNameAttr, 'displayName');
Set($LDAPPhoneAttr, 'telephoneNumber');


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

Community help: http://wiki.bestpractical.com
Commercial support: sales[at]bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com


We're hiring! Come hack Perl for Best Practical: http://bestpractical.com/about/jobs.html


purp at acm

Mar 21, 2006, 12:05 PM

Post #6 of 10 (3911 views)
Permalink
Re: Self user creation [In reply to]

Hello!

On Tue, 2006-03-21 at 10:51 -0800, Anthony Lincoln wrote:
> Rick Russell wrote:
> A couple years ago I hacked RT to allow users to self-create upon login
> as long as they have a valid entry in our enterprise LDAP server and it
> contains a valid orgcode. I like it because it doesn't require any
> action on my part, but still has a nice built-in set of constraints. I
> wrote the code for allowing users to self-create via email, but given
> the ease of spoofing, I leave it toggled off:
>
> Set($LDAPExternalAuth, 1); # enable LDAP authentication/lookups
> Set($LDAPWebExternalAuto, 1); # create user acct from LDAP at login
> Set($LDAPMailExternalAuto, 0); # create user acct from LDAP at email
>
> I included a plethora of other options, including LDAP/S connectivity,
> attribute selection/mapping (below).
>
> Has anyone used the new LDAP overlay stuff? Does it allow for this
> level of granularity?

Most of that, yes. It allows you to separate auth from info so you can
choose different LDAP servers for each function if you wish (yes, it was
necessary; no, I'm not proud of that) and allows you to config SSL,
base, filter, and user/password per server. No password is considered to
mean the LDAP server doesn't need authentication.

Rather than provide a static list of attributes, the new overlay uses a
hash ref where you map RT attrs to your LDAP fields. It also does
something similar to your LDAPSearchAttrs. It doesn't currently
autocreate accounts on failed login. You can have a peek at the code and
config twiddles at http://wiki.bestpractical.com/?LDAP (check out the
RT_SiteConfig.pm stuff).

I'm pondering the autocreation thing as an overlay separate from the
LDAP overlay. My approach would be that the front page could provide a
link for "Create New Account" which would require name, email, and
password, then activation by emailing you a link, etc. I would also
include hooks such that if you can successfully auth externally (LDAP,
$REMOTE_USER, etc.) you can skip all of that. All with config twiddles
for inside vs. outside users, etc.

Would there be general interest in this?

Cheers!

--j
--
Jim Meyer, Geek at Large purp[at]acm.org

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

Community help: http://wiki.bestpractical.com
Commercial support: sales[at]bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com


We're hiring! Come hack Perl for Best Practical: http://bestpractical.com/about/jobs.html


hwagener at hamburg

Mar 22, 2006, 12:13 AM

Post #7 of 10 (3892 views)
Permalink
Re: Self user creation [In reply to]

Am 21.03.2006 um 21:05 schrieb Jim Meyer:

[...]

> I'm pondering the autocreation thing as an overlay separate from the
> LDAP overlay. My approach would be that the front page could provide a
> link for "Create New Account" which would require name, email, and
> password, then activation by emailing you a link, etc. I would also
> include hooks such that if you can successfully auth externally (LDAP,
> $REMOTE_USER, etc.) you can skip all of that. All with config twiddles
> for inside vs. outside users, etc.
>
> Would there be general interest in this?

Yes, of course! That would be a great addition.

Regards,
Harald

--
Harald Wagener
Technischer Leiter

Foote Cone & Belding
FCB Wilkens
An der Alster 42
20099 Hamburg
Germany

T: +49 (0)40 2881 1252
F: +49 (0)40 2881 1217
hwagener[at]hamburg.fcb.com
http://www.footeconebelding.de
_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales[at]bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com


We're hiring! Come hack Perl for Best Practical: http://bestpractical.com/about/jobs.html


ahlincoln at lbl

Mar 22, 2006, 8:19 AM

Post #8 of 10 (3873 views)
Permalink
Re: Self user creation [In reply to]

Jim Meyer wrote:
> Hello!
>
> On Tue, 2006-03-21 at 10:51 -0800, Anthony Lincoln wrote:
>
>>Has anyone used the new LDAP overlay stuff? Does it allow for this
>>level of granularity?
>
> Most of that, yes. It allows you to separate auth from info so you can
> choose different LDAP servers for each function if you wish (yes, it was
> necessary; no, I'm not proud of that) and allows you to config SSL,
> base, filter, and user/password per server. No password is considered to
> mean the LDAP server doesn't need authentication.
>
> Rather than provide a static list of attributes, the new overlay uses a
> hash ref where you map RT attrs to your LDAP fields. It also does
> something similar to your LDAPSearchAttrs. It doesn't currently
> autocreate accounts on failed login. You can have a peek at the code and
> config twiddles at http://wiki.bestpractical.com/?LDAP (check out the
> RT_SiteConfig.pm stuff).
>
> I'm pondering the autocreation thing as an overlay separate from the
> LDAP overlay. My approach would be that the front page could provide a
> link for "Create New Account" which would require name, email, and
> password, then activation by emailing you a link, etc. I would also
> include hooks such that if you can successfully auth externally (LDAP,
> $REMOTE_USER, etc.) you can skip all of that. All with config twiddles
> for inside vs. outside users, etc.
>
> Would there be general interest in this?

I might be. It would be great to synch back up with the branch when 3.6
comes out, without having to integrate all my custom code again. The
new functionality you described, plus TLS sessions that required
specific server certs (to prevent man-in-middle exploits), should work
in my environment. A logging option that sends back actual LDAP error
strings (ldap_error_text) would be nice to have for troubleshooting.
I'd be happy to contribute code review/diffs to help make this happen.

Thanks,

Tony

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

Community help: http://wiki.bestpractical.com
Commercial support: sales[at]bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com


We're hiring! Come hack Perl for Best Practical: http://bestpractical.com/about/jobs.html


purp at acm

Mar 23, 2006, 9:37 AM

Post #9 of 10 (3884 views)
Permalink
Re: Self user creation [In reply to]

Hello!

On Wed, 2006-03-22 at 08:19 -0800, Anthony Lincoln wrote:
> I might be. It would be great to synch back up with the branch when 3.6
> comes out, without having to integrate all my custom code again. The
> new functionality you described, plus TLS sessions that required
> specific server certs (to prevent man-in-middle exploits), should work
> in my environment. A logging option that sends back actual LDAP error
> strings (ldap_error_text) would be nice to have for troubleshooting.
> I'd be happy to contribute code review/diffs to help make this happen.

I'm not sure about requiring specific certs; we don't do/need TLS here,
so I've largely just polished the previous implementations of that. I'd
love a more in depth explanation ... or a code contrib. =]

The implementation does, however, uniformly provide ldap_error_name
information; the code looks like this:

$RT::Logger->info((caller(0))[3], "AUTH FAILED", $self->Name,
"(can't bind:", ldap_error_name($msg->code),
$msg->code, ")");

The caller() bit is just "figure out my function name". The code is
available for review at:

http://wiki.bestpractical.com/?LdapUserLocalOverlay

Cheers!

--j
--
Jim Meyer, Geek at Large purp[at]acm.org

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

Community help: http://wiki.bestpractical.com
Commercial support: sales[at]bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com


We're hiring! Come hack Perl for Best Practical: http://bestpractical.com/about/jobs.html


ahlincoln at lbl

Mar 24, 2006, 11:21 AM

Post #10 of 10 (3894 views)
Permalink
Re: Self user creation [In reply to]

Jim Meyer wrote:
> Hello!
>
> On Wed, 2006-03-22 at 08:19 -0800, Anthony Lincoln wrote:
>
>>I might be. It would be great to synch back up with the branch when 3.6
>>comes out, without having to integrate all my custom code again. The
>>new functionality you described, plus TLS sessions that required
>>specific server certs (to prevent man-in-middle exploits), should work
>>in my environment. A logging option that sends back actual LDAP error
>>strings (ldap_error_text) would be nice to have for troubleshooting.
>>I'd be happy to contribute code review/diffs to help make this happen.
>
>
> I'm not sure about requiring specific certs; we don't do/need TLS here,
> so I've largely just polished the previous implementations of that. I'd
> love a more in depth explanation ... or a code contrib. =]

Basically, if you invoke start_tls with no args, you're encrypting a
session between yourself and another host without any verification,
which opens the door to host spoofing and man-in-the-middle attacks.
The following code snippet checks that the certificate you receive from
the destination host is one that you trust. That's where the certfile
from your trusted CA comes in.

$ diff Ldap_Overlay.pm Ldap_Overlay.pm.new
77a78
> $config{'AuthCAFile'} = $RT::LdapCAFile ||
$RT::LdapAuthCAFile;
92a94
> $config{'InfoCAFile'} = $RT::LdapCAFile ||
$RT::LdapInfoCAFile;
126a129
> my $ldap_cafile = $ldap_config{'AuthCAFile'};
138c141,144
< $ldap->start_tls;
---
> $ldap->start_tls(
> verify => 'require',
> cafile => $ldap_cafile
> );
434a441
> my $ldap_cafile = $ldap_config{'InfoCAFile'};
459c466,469
< $ldap->start_tls;
---
> $ldap->start_tls(
> verify => 'require',
> cafile => $ldap_cafile
> );


> The implementation does, however, uniformly provide ldap_error_name
> information; the code looks like this:
>
> $RT::Logger->info((caller(0))[3], "AUTH FAILED", $self->Name,
> "(can't bind:", ldap_error_name($msg->code),
> $msg->code, ")");

I was talking about ldap_error_text, which references the longer and
more intuitive error string associated with a given LDAP errcode. But
this is fine. Great to have this component actively managed by someone!

Let me know if you have any questions/comments on any of the above...

Thanks,

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

Community help: http://wiki.bestpractical.com
Commercial support: sales[at]bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com


We're hiring! Come hack Perl for Best Practical: http://bestpractical.com/about/jobs.html

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


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.