LDAP solution that works

RT Users
1

For our Scandinavian readers I have compiled a short install-note here for
our RT system:

http://folk.uio.no/tomaso/jobb/rt-spec.html

I have also got LDAP to work with Apache 2 (distributed with RHES30 which
hasn’t the experimental mod_auth_ldap module compiled), and OpenLDAP using
(from ssl.conf) the following module:

MOD_AUTH_LDAP by Muhammad A Muquit for Apache 2.x versjon 2.12.

AuthAuthoritative On
AuthName “Request Tracker (RT) Saksbehandlingsystemet ved UiO”
AuthType Basic
AuthOnBind On

Sub_DNou=CIS,ou=People

LDAP_Persistent Off

Bind_Tries 5

LDAP_Debug On
LDAP_Protocol_Version 3 (our server use TLS/certificate)
LDAP_Deref ALWAYS
LDAP_StartTLS On (our server use TLS/certificate)

LDAP_CertDbDir path - only available through Netscape’s SDK and SSL

configuration
LDAP_Server some-ldap-server.sub.domain

LDAP_Server some-ldap-test-server.sub.domain - test LDAP server for UiO

LDAP_Port 389

LDAP_Connect_Timeout 3 - Connect timeout in seconds - only available

using iPlanet SDK

LDAP_Port 636 - If SSL is on, must specify the LDAP SSL port, usually

636
Base_DN “ou=Users,dc=sub,dc=domain”

Base_DN “ou=People,dc=sub,dc=domain”

Base_DN “o=Fox Chase Cancer Center,c=US”

Bind_DN “uid=admin,o=Fox Chase Cancer Center,c=US”

Bind_Pass “secret”

UID_Attr uid

UID_Attr_Alt “mail”

Group_Attr uniqueMember

SupportNestedGroups On
require valid-user

require user muquit foo bar “john doe”

require roomnumber “123 Center Building”

require filter “(&(telephonenumber=1234)(roomnumber=123))”

require group cn=rt-saksbehandler,ou=netgroups,dc=sub,dc=domain

require group cn=rcs,ou=Groups

Our solution is as follows for authentication and authorisation:

  1. LDAP for authentication. New users will be created automatically by RT
    with their username. Of course, new users sending e-mail to RT will be
    created by their e-mail address. That’s not wanted, and we are
    wondering how others deal with that.

  2. In addition, we will not do a ldap dump (export/import) of userinfo
    except password to the RT database (in our case a PostgeSQL database),
    since we have potensially 10.000s of requestors. Instead we want to
    build internally in RT userinfo on the run when we have
    incoming requests. So, we need to create some form of a script that
    searches through the RT database for username equals an e-mail adresss
    or using something that triggers that script when we have incoming
    requests to update the RT database with the correct userinfo. As said
    before an incomming request creates an user with the e-mail address as
    the username. We have our own service called “electronic post office”
    which gives info about an user. So we don’t need a dump from a LDAP
    server or other user administrative system.

Tomas A. P. Olaj, email: tomas.olaj@usit.uio.no, web: folk.uio.no/tomaso
University of Oslo / USIT (Center for Information Technology Services)
System- and Application Management / Applications Management Group

2

Is it possible to run one instance of RT for two separate domains?

IOW, support@foo.com and support@bar.com forward mail to their individual
queues and reply from their respective domains?

Matthew Joseff, Director Technical Operations
(p) 703.519.1066 (f) 703.548.9151 (m) 202.415.6261
YellowBrix - Transforming Content Into Action.

3

Hi Tomas,

Tomas A. P. Olaj wrote:

  1. LDAP for authentication. New users will be created automatically by RT
    with their username. Of course, new users sending e-mail to RT will be
    created by their e-mail address. That’s not wanted, and we are
    wondering how others deal with that.

We use LDAP authentication here, but not through Apache. We use an LDAP
user authentication overlay which handles both logging in and email user
creation. There are links to it in the “Extensions” part of the
Contributions wiki page at

http://wiki.bestpractical.com/index.cgi?Contributions

It works a treat, except for autogenerating accounts for CCs on an
inbound email. We can live with that for the moment.

Carl.

4

I am trying to use that overlay file, but am having some issues. Based on my understanding of that file, it just deals with the password authentication portion, and therefore requires the user to be pre-existing in the RT database.

We use Novell here and want to authenticate against the eDirectory LDAP server(something we do often). Ideally, we would want a user to be able to sign in with the novell name/password, have RT create a user with the given name, leave the password blank, and use the e-mail adress which can be grabbed from LDAP as well. A nice bonus would be the ability to have a user send an e-mail in, and if it is not associated with an account, perform an LDAP lookup for that address, and proceed with the same account creation described above.

This sounds roughly like what you said you have going, so I’d be interested to know what you have done, code or configuration wise aside from just that overlay file. Thanks,

Robert

Carl Makin carl@xena.IPAustralia.gov.au 08/10/04 21:31 PM >>>
Hi Tomas,

Tomas A. P. Olaj wrote:

  1. LDAP for authentication. New users will be created automatically by RT
    with their username. Of course, new users sending e-mail to RT will be
    created by their e-mail address. That’s not wanted, and we are
    wondering how others deal with that.

We use LDAP authentication here, but not through Apache. We use an LDAP
user authentication overlay which handles both logging in and email user
creation. There are links to it in the “Extensions” part of the
Contributions wiki page at

http://wiki.bestpractical.com/index.cgi?Contributions

It works a treat, except for autogenerating accounts for CCs on an
inbound email. We can live with that for the moment.

Carl.

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

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

5

Hi Robert,

Robert Paskowitz wrote:

We use Novell here and want to authenticate against the eDirectory LDAP server(something we do often). Ideally, we would want a user to be able to sign in with the novell name/password, have RT create a user with the given name, leave the password blank, and use the e-mail adress which can be grabbed from LDAP as well. A nice bonus would be the ability to have a user send an e-mail in, and if it is not associated with an account, perform an LDAP lookup for that address, and proceed with the same account creation described above.

The system we have works the other way around. Users are automatically
created with data from the LDAP server by an inbound email. Once they
are created, then they can log in. We use the LDAPMail.pm file
(attached) in the /rt3/lib/RT/Interface/Email/Auth directory to do
the LDAP based auto user creation. I got that off this list, but I
can’t remember who from. :frowning: LDAPMail.pm associated with
/rt3/local/lib/RT/User_Local.pm (attached) and this snippet in the
RT_SiteConfig.pm file do it all for us.

LDAP Authentication

$LDAPExternalAuth = 1;
$LdapServer=“your.directory.server”;
$LdapUser=“”;
$LdapPass=“”;
$LdapBase=“dc=your,dc=directory,dc=serverbase”;
$LdapUidAttr=“uid”;
$LdapFilter=“(objectclass=inetOrgPerson)”;

LDAP entry from mail.

@RT::MailPlugins = (
“Auth::LDAPMail”,
“Auth::MailFrom”
);

At some point I hope to find the time to dive in and make the
“ParseNewMessageForTicketCcs” function use LDAP data as well.

Unfortunately this might all go out the window here as my management are
keen on using a single “Service Desk” based system across the whole
organisation, and the peope in charge of that are only interested in
commercial packages.

Hope this helps.
Carl.

LDAPMail.pm (6.46 KB)

User_Local.pm (3.41 KB)

6

Thanks for the file, I knew there was some sort of a missing link. Unfortunatly our LDAP idea here may not take off because of some complexities. Our users are stored in all levels of the tree, so a fairly bruteforce recursive check is needed, which is time consuming, wasteful, and doesn’t always seem to work. Some of our other software uses IMAP authentication, so I am currentlly looking into modifying the LDAP portions to do IMAP. We save having to do the lookups for the dn, which is a big plus.

Whatever I end up with will be posted back to the list. Even if we stick with LDAP, the recursive search may be useful to some.

Carl Makin carl@xena.IPAustralia.gov.au 08/12/04 00:32 AM >>>
Hi Robert,

Robert Paskowitz wrote:

We use Novell here and want to authenticate against the eDirectory LDAP server(something we do often). Ideally, we would want a user to be able to sign in with the novell name/password, have RT create a user with the given name, leave the password blank, and use the e-mail adress which can be grabbed from LDAP as well. A nice bonus would be the ability to have a user send an e-mail in, and if it is not associated with an account, perform an LDAP lookup for that address, and proceed with the same account creation described above.

The system we have works the other way around. Users are automatically
created with data from the LDAP server by an inbound email. Once they
are created, then they can log in. We use the LDAPMail.pm file
(attached) in the /rt3/lib/RT/Interface/Email/Auth directory to do
the LDAP based auto user creation. I got that off this list, but I
can’t remember who from. :frowning: LDAPMail.pm associated with
/rt3/local/lib/RT/User_Local.pm (attached) and this snippet in the
RT_SiteConfig.pm file do it all for us.

LDAP Authentication

$LDAPExternalAuth = 1;
$LdapServer=“your.directory.server”;
$LdapUser=“”;
$LdapPass=“”;
$LdapBase=“dc=your,dc=directory,dc=serverbase”;
$LdapUidAttr=“uid”;
$LdapFilter=“(objectclass=inetOrgPerson)”;

LDAP entry from mail.

@RT::MailPlugins = (
“Auth::LDAPMail”,
“Auth::MailFrom”
);

At some point I hope to find the time to dive in and make the
“ParseNewMessageForTicketCcs” function use LDAP data as well.

Unfortunately this might all go out the window here as my management are
keen on using a single “Service Desk” based system across the whole
organisation, and the peope in charge of that are only interested in
commercial packages.

Hope this helps.
Carl.

7

Hi Robert,
Sorry for taking so long to reply.

Robert Paskowitz wrote:

take off because of some complexities. Our users are stored in all levels of the tree, so a fairly bruteforce recursive check is needed, which is time consuming, wasteful, and doesn’t always seem to work. Some of our

How about bringing up another LDAP server with a more standard schema
and populating it from the first at regular intervals. Our primary LDAP
server is actually populated from several different sources, some of
them other LDAP servers with weird schemas (The PABX management server
for instance) and NT/Active Directory groups.

You could also then get rid of the IMAP authentication as well.

Carl.

8

The need for a second LDAP server just doesn’t exist within the building. We actually do have multiple LDAP servers running, but each is a mirror, as they are all brought up by eDirectory on NetWare machines.

I managed to implement the IMAP authentication, and it was dirt simple. I used the existing code for the LDAP authentication, and just popped in a few IMAP lines.

Bringing up a second LDAP server would simplify the authentication, (no recursive seraching for the context), which is already perfected (as much as can be) for our other uses. Unfortunatly even if we implemented the second LDAP server, we would still need the IMAP service up to authenticate fully external entities that cannot authenticate against eDirectory.

I plan to clean up my code a bit, and post the IMAP authentication, hopefully some other people may find it useful.

Robert

Carl Makin carl@xena.IPAustralia.gov.au 08/16/04 19:48 PM >>>
Hi Robert,
Sorry for taking so long to reply.

Robert Paskowitz wrote:

take off because of some complexities. Our users are stored in all levels of the tree, so a fairly bruteforce recursive check is needed, which is time consuming, wasteful, and doesn’t always seem to work. Some of our

How about bringing up another LDAP server with a more standard schema
and populating it from the first at regular intervals. Our primary LDAP
server is actually populated from several different sources, some of
them other LDAP servers with weird schemas (The PABX management server
for instance) and NT/Active Directory groups.

You could also then get rid of the IMAP authentication as well.

Carl.