RT 3.8: questions on Kerberos, LDAP, and guest account setup

RT Users
1

I was able to successfully configure RT and Apache to use
Kerberos for authentication, roughly as shown below. However,
now I’m somewhat concerned about the lack of authentication in
rt-mailgate(1) (Debian Bug#615890 [1].) Somehow, I feel that
this issue could be resolved easily, and wonder if anyone’s
interested?

[1] http://bugs.debian.org/615890

Also, I wonder, is it possible to make RT refer to LDAP for
certain information (like: login name, real name, e-mail, etc.)
about its users?  It could easily become a painful experience to
either synchronize the RT user database with LDAP, or to
maintain the informations in both of the places simultaneously.

Additionally, I have set up an Unprivileged “guest” account.
However, this configuration results in the user being presented
with a somewhat “limited” Web interface (in particular, it lacks
the Search facility.)  Should I make this account Privileged
instead, or is there another easy way of setting up a
“read-only” account with the Search facility being active?

I'm using RT as of version 3.8.8 debian 7.

TIA.

The RT and Apache configuration files for using HTTP
authentication with a Kerberos database were roughly as follows.

$ cat < /etc/request-tracker3.8/RT_SiteConfig.d/99-trust-webauth

99-trust-webauth -- Default-Generic --

use the REMOTE_USER provided by the web server

Set ($WebExternalAuth, 1);

display normal login screen if REMOTE_USER fails

Set ($WebFallbackToInternalAuth, 1);

create users automatically if no user matching REMOTE_USER is found

Set ($WebExternalAuto, 1);

99-trust-webauth ends here

$ cat < /etc/apache2/sites-enabled/gray-ssl
…
## /rt/ (for http://rt.am-1.org/)

## We use this to prevent requests for images being sent through to
## the RT::Mason handler
Alias /rt/NoAuth/images /usr/share/request-tracker3.8/html/NoAuth/images

## Handle everything else with this
ScriptAlias /rt /usr/share/request-tracker3.8/libexec/mason_handler.scgi

<Directory "/usr/share/request-tracker3.8/libexec">
    AllowOverride None
    Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
    Order allow,deny
    Allow from all
</Directory>

<Location /rt/>
    DirectoryIndex index.html
    Order allow,deny
    Allow from all
    AuthType Kerberos
    ## FIXME: README.gz tells that the following is insecure
    # KrbVerifyKDC off
    Require valid-user
</Location>

## Limit mail gateway access to localhost by default
<Location /rt/REST/1.0/NoAuth>
    Order allow,deny
    Allow from ::1
    Allow from 127.0.0.0/8
    Satisfy any
</Location>

<IfModule mod_rewrite.c>
    RewriteCond %{HTTP_HOST} =rt.am-1.org
    RewriteRule ^/$ /rt/ [R=302]
</IfModule>

…
$

FSF associate member #7257

2

I was able to successfully configure RT and Apache to use
Kerberos for authentication, roughly as shown below. However,
now I’m somewhat concerned about the lack of authentication in
rt-mailgate(1) (Debian Bug#615890 [1].) Somehow, I feel that
this issue could be resolved easily, and wonder if anyone’s
interested?

We’d certainly consider patches

Also, I wonder, is it possible to make RT refer to LDAP for
certain information (like: login name, real name, e-mail, etc.)
about its users? It could easily become a painful experience to
either synchronize the RT user database with LDAP, or to
maintain the informations in both of the places simultaneously.

Sounds like you want RT-Extension-LDAPImport

Additionally, I have set up an Unprivileged “guest” account.
However, this configuration results in the user being presented
with a somewhat “limited” Web interface (in particular, it lacks
the Search facility.) Should I make this account Privileged
instead, or is there another easy way of setting up a
“read-only” account with the Search facility being active?

If you want the advanced search, you want a Privileged user.
Unprivileged users are only going to see tickets that they’re the
Requestor of.

-kevin

3

Kevin Falcone falcone@bestpractical.com writes:

[…]

Also, I wonder, is it possible to make RT refer to LDAP for
certain information (like: login name, real name, e-mail, etc.)
about its users? It could easily become a painful experience to
either synchronize the RT user database with LDAP, or to
maintain the informations in both of the places simultaneously.

Sounds like you want RT-Extension-LDAPImport

    I'll check it, thanks.

Additionally, I have set up an Unprivileged “guest” account.
However, this configuration results in the user being presented with
a somewhat “limited” Web interface (in particular, it lacks the
Search facility.) Should I make this account Privileged instead, or
is there another easy way of setting up a “read-only” account with
the Search facility being active?

If you want the advanced search, you want a Privileged user.

Is it merely a limitation of the implementation, or something
deeper?

The inconvenience of setting up a Privileged guest account is
that it will be necessary to maintain a separate group, whose
members (which are all the Privileged users except the guest
account) are actually granted “write access” to the tickets.
With guest account now being Unprivileged, the Privileged group
fulfills this role.

Unprivileged users are only going to see tickets that they’re the
Requestor of.

Apparently, it's not the case: I was able to see all the tickets
belonging to the queues for which Everyone is granted SeeQueue
and ShowTicket permissions.  (RT 3.8.8 debian 7.)

FSF associate member #7257

4

Kevin Falcone falcone@bestpractical.com writes:
If you want the advanced search, you want a Privileged user.

Is it merely a limitation of the implementation, or something
deeper?

I’m afraid I don’t understand your question. Unprivileged users have
no access to the Query Builder interface, and I’m not sure what level
of effort would be required to make it so.

The inconvenience of setting up a Privileged guest account is
that it will be necessary to maintain a separate group, whose
members (which are all the Privileged users except the guest
account) are actually granted “write access” to the tickets.
With guest account now being Unprivileged, the Privileged group
fulfills this role.

Unprivileged users are only going to see tickets that they’re the
Requestor of.

Apparently, it’s not the case: I was able to see all the tickets
belonging to the queues for which Everyone is granted SeeQueue
and ShowTicket permissions. (RT 3.8.8 debian 7.)

If you grant them ShowTicket globally, then anyone can see any ticket
if they can log into the system.

Unprivileged user dashboards only search for tickets where they are
watchers.

Granting Everyone ShowTicket is almost never the rights configuration
you want.

-kevin