Self user creation

Michael_Shanks · March 19, 2006, 4:55pm

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

Kenn_Crocker · March 20, 2006, 5:15pm

NEVER!!

Michael Shanks wrote:

Tomasz_Wlodek · March 20, 2006, 5:29pm

Hi,

I have installed RT and it works.

Now I wanted to use external authentication in RT.

I decided to create a virtual host which would be on port 443, so that it
can be accessed via https. Then I have added the following changes to RY
configuration file:

Set($WebExternalAuth , 1); (to set external authentication)
Set($WebFallbackToInternalAuth , 1); (to use internal authentication when
extrrnal fails)
Set($WebExternalAuto , 1); (to automatically create users when external
authentication is OK).

Then I have defined virtual host on port 443 with the same options as the
virtual host on port 80.

Now I logon to RT via https… I get the following error:

“You’re almost there!
You haven’t yet configured your webserver to run RT. You appear to have
installed RT’s web interface correctly, but haven’t yet configured your
web server to “run” the RT server which powers the web interface. The next
step is to edit your webserver’s configuration file to instruct it to use
RT’s mod_perl, fastcgi or speedycgi handler. If you need commercial
support, please contact us at sales@bestpractical.com.”

Fine, but I have already configured my www server to run mod_perl,fastcgi.
It works when I connect to RT using http, not https. I do have the
LoadModule fastcgi_module modules/mod_fastcgi.so in apache configuration.

So what is missing? Why Rt works when called by http but not when I call
it by https?

Tomasz Wlodek | tel 631-344-7448
Brookhaven Laboratory, Building 510M | fax 631-344-7616
Upton NY 11973-5000 |

Rick_Russell · March 20, 2006, 5:55pm

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

Michael_Erana · March 20, 2006, 7:08pm

Sounds like your running into a Virtual Hosts discrimination problem. Are you running any other VHOSTS on that box?

I’m running that exact config with external auth and https and I learned the hardway about SSL sessions and their dependancy to an Identifier like a port or IP Address.

One other comment: I run both the SSL and the Standard config in the same .conf file for ease of use. I’ve included a sanitized version below:

rt3prod.conf

Request Tracker 3.4 Production Server

Apache Configuration File

$Author: merana $

$Revision: 16 $

$HeadURL: file:///var/svn/anon-prod/trunk/etc/rt3prod.conf $

$Id: rt3prod.conf 16 2006-03-15 12:09:44Z merana $

FastCgiServer /usr/share/request-tracker3.4/libexec/mason_handler.fcgi

NameVirtualHost 192.168.1.49:80
<VirtualHost 192.168.1.49:80>
ServerName rt.mydomain.com
ServerAlias rt2.mydomain.com
DocumentRoot /usr/share/request-tracker3.4/html
AddDefaultCharset UTF-8
ScriptAlias / /usr/share/request-tracker3.4/libexec/mason_handler.fcgi/
AddHandler fastcgi-script fcgi
CustomLog /var/log/apache2/rt.access.log combined env=!dontlog
ErrorLog /var/log/apache2/rt.error.log

RewriteEngine on

#RewriteRule ^/rt$ /
#RewriteRule ^/rt/(.)$ /$1
#RewriteRule ^/rt$ /rt/
#RewriteCond %{REQUEST_FILENAME} -d
#RewriteRule ^(/usr/share/request-tracker3.4/html.)/$ $1/index.html

SetHandler fastcgi-script

<Directory /usr/share/request-tracker3.4/html>
SetHandler fastcgi-script

<Directory /usr/share/request-tracker3.4/html/NoAuth>
SetHandler default-handler

NameVirtualHost 192.168.1.49:443
<VirtualHost 192.168.1.49:443>
ServerName rt.mydomain.com
ServerAlias rt2.mydomain.com
DocumentRoot /usr/share/request-tracker3.4/html
AddDefaultCharset UTF-8
ScriptAlias / /usr/share/request-tracker3.4/libexec/mason_handler.fcgi/
AddHandler fastcgi-script fcgi
CustomLog /var/log/apache2/rt.access.log combined env=!dontlog
ErrorLog /var/log/apache2/rt.error.log

SSL Engine Switch:

Enable/Disable SSL for this virtual host.

SSLEngine on

SSL Cipher Suite:

List the ciphers that the client is permitted to negotiate.

See the mod_ssl documentation for a complete list.

SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

Server Certificate & Key Files

SSLCertificateFile /etc/apache2/ssl/rt-cert.cer
SSLCertificateKeyFile /etc/apache2/ssl/rt-cert.key

SSL Protocol Adjustments:

The safe and default but still SSL/TLS standard compliant shutdown

approach is that mod_ssl sends the close notify alert but doesn’t wait for

the close notify alert from client. When you need a different shutdown

approach you can use one of the following variables:

SetEnvIf User-Agent “.MSIE.”
nokeepalive ssl-unclean-shutdown
downgrade-1.0 force-response-1.0
RewriteEngine on

#RewriteRule ^/rt$ /
#RewriteRule ^/rt/(.)$ /$1
#RewriteRule ^/rt$ /rt/
#RewriteCond %{REQUEST_FILENAME} -d
#RewriteRule ^(/usr/share/request-tracker3.4/html.)/$ $1/index.html

SetHandler fastcgi-script

<Directory /usr/share/request-tracker3.4/html>
SetHandler fastcgi-script

<Directory /usr/share/request-tracker3.4/html/NoAuth>
SetHandler default-handler

Michael Eraña, CISSP
CTO
PC Network, Inc.
eranam@lanusa.com

Kenn_Crocker · March 20, 2006, 7:34pm

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:

Andrew_Elwell · March 20, 2006, 7:35pm

One other comment: I run both the SSL and the Standard config in the same .conf file for ease of use. I’ve included a sanitized version below:

We do something similar, but redirect all non-ssl traffic to 443 with mod_rewrite

ie:

RewriteEngine on
RewriteCond %{SERVER_PORT} !443
RewriteRule ^/(.*) https://your.server.fqdn/$1 [R]

... include all the SSL, external auth (cosign) and rt gubbins here

We’re using cosign (web10 | weblogin.org) as the external auth, and I have an access list for those users who can access RT on the webserver.

Andrew

Andrew Elwell, System Administrator EPCC
Tel 0131 445 7833 (ACF Building)
Tel 0131 650 5023 (Rm 3309, JCMB)

Tomasz_Wlodek · March 20, 2006, 9:59pm

Many thanks to all of you who replied! I have figured out that one of the
configuration files had been modified by another administrator and this
cased the mod_perl stop working for one of the virtual hosts.

Tomasz Wlodek | tel 631-344-7448
Brookhaven Laboratory, Building 510M | fax 631-344-7616
Upton NY 11973-5000 |

Anthony_Lincoln · March 21, 2006, 6:51pm

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’);

Jim_Meyer1 · March 21, 2006, 8:05pm

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 Request Tracker Wiki (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@acm.org

Harald_Wagener · March 22, 2006, 8:13am

[…]

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@hamburg.fcb.com
http://www.footeconebelding.de

Anthony_Lincoln · March 22, 2006, 4:19pm

Jim Meyer wrote:

Hello!

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 Request Tracker Wiki (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

Jim_Meyer1 · March 23, 2006, 5:37pm

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@acm.org

Anthony_Lincoln · March 24, 2006, 7:21pm

Jim Meyer wrote:

Hello!

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